2017-12-20 Risk assesment - Product Model 3.3

Date

20 Dec 2017

Attendees

• Josh Zamor

• Chongsun Ahn (Unlicensed)
• Brandon Bowersox-Johnson

Goals

In OpenLMIS v3.3 we'll finally have enough features to show the requisition process through to the fulfillment process and receipt of the shipment. We want to do a quick assessment of everything related to the Product Model to determine if we'll be successful on delivering for the promises of that model (GTIN, classifications, enterprise ordering, reporting by classification system, packaging, shipping). This is not an assessment just for Reporting, but rather overall maturity of 3.3's implementation.

Including:

- demo data

- APIs (Reference data and Stock Mgmt most seriously)

- Screens, workflows etc in services: Stock Mgmt, Requisition, Fulfillment

Output:

- tasks, bugs, features, etc in JIRA - 1 or more epics or a label

- initial prioritization for 3.3

- readout to larger group on how we're doing and any work proposed.

Discussion items

Notes

Workflows

Update on product master

• UNSPSC and GPC
• however GPC is not specific enough, and UNSPSC is better but they still feel not specific enough
  • Medical → pharma → Malaria phroplaxis
  • UNSPSC is 4 levels, they (pharmacists?) are creating a product master that is based on UNSPSC, and adding a 5th level
    • Ex: face masks, UNSPSC goes to personal protection; firefighter facemask different from doctor's facemask
• Modified version of UNSPSC
• Solutioning:
  • Decode UNSPSC meaning and encode into Orderable (uses source material, but leave it flexible)
    • OpenLMIS RefData "program orderable" concept includes DispensingUnit (string), NetContent (int), DosesPerPatient, and more.
  • Ship OpenLMIS with UNSPSC today
• Open Questions/Future Topics:
  • Is OpenLMIS 'Commodity Type' feature compatible with a more specific product master like the one mSupply is using?
  • Will we need to upgrade our model if we use OpenLMIS as a Product Registry tool?
• Risk?
  • Ideal state of globally-adopted product masters is many years away (5 years?)

Requisition, using SoH (SoH for trade item, ordering commodity type)

• Question: Have we already achieved this?
  • Unlikely: In Requisition workflow, if system is configured with SoH with trade item orderables and Requisition happens with Commodity Type orderables, we think the Requisition form might not work right.
    • When Requisition form goes to pull the Beginning Balance from stock cards, it probably won't pull it right. (not yet implemented, but coming soon with 'simple requisition')
    • When Requisition pushes to Stock Management, is it pushing the correct data to stock cards? Is it pushing to Commodity Type stock cards or Trade Item stock cards? 
      • Desired Behavior is to push to whichever type is configured on the Requisition form. If you are requisitioning in Commodity Types, then your stock cards that it updates will be for the Commodity Types. A potential future feature would be that you are conducting your physical inventories and updating your stock cards based on Trade Items.
      • Current common case, requisitioning and stock management by commodity types
• Future Feature: "roll-up" stock card feature, where you get a "virtual roll-up" stock card showing the total counts for a commodity type by adding up all the Trade Item stock cards.
• Risks? 

FTAP in use

• We currently have no way to get the trade item orderables given a commodity type orderable
• We need a way to describe in FTAP what SM should show (presuming today it's really for Requisitions)
  • When FTAP is configured, ideally they just approve commodity type orderables (e.g. BCG 20 dose vials)
  • When they do, in Stock Mgmt it understands that all trade items for the commodity type BCG, are allowed to be counted (received, issued, phys inventory)
  • They may in the non-ideal case approve a Trade Item Orderable, if they do, in Stock Mgmt you may only count SoH by that Trade Item orderable - meaning you can't receive / inventory / issue anything but that trade item orderable (i.e. GTIN)
  • This needs a refreshed design - haven't pulled this back together since oct 2016.  Josh Zamor to focus on this.

Stock Mgmt (SoH is for trade item, report in a roll up when asked for it by commodity type)

notes

Local fill (SoH for trade item, ordered items are commodity type)

notes

POD (SoH for trade item, PoD is trade item)

notes

Demo data

OLMIS-3819 - Getting issue details... STATUS (might cause a regression - this is OK.  Need to tell folks that demos might regress in requisition and local fill)

• Brandon Bowersox-Johnson to communicate out impacts of 3819

• Ideal state?
  • We want vaccine demo data to be ideal product model (Commodity types and trade items)
  • We want non-vaccine demo data to be the simplistic model (just orderables - no CT no TI no lots)
  • We want Commodity Type's from UNSPSC
  • We need Orderables from Trade Item
  • We need Orderables from Commodity type
  • When we use these Orderables in workflows we want:
    • Commodity types in Requisitions
    • Trade Items in Stock Mgmt
    • Fulfillment (no order demo data for vaccines at present)
      • want Commodity Type's in what's ordered (Orders)
      • want Trade Item in what's fulfilled (Shipments domain ^(new))
• does java code need a validation to prevent orderable having both trade item and commodity type at same time?

Implementation guide / docs

• Update product model docs to show there is a simple way - a simplistic product list.
  • currently it makes it sound like it has to be trade item or commodity type

APIs

Ref data: is this trade item IS A commodity type?

Stck Mgmt: rolling up?

Action items

• Josh Zamor to send meeting invite for pre-Jan 3 work
• Josh Zamor to send another invite for post-jan 3 work