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
Time
Item
Who
Notes
5min
Agenda item
Name
Notes for this agenda item
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
(might cause a regression - this is OK. Need to tell folks that demos might regress in requisition and local fill)