Status in eLMIS: In the eLMIS

Status in OpenLMIS: Not implemented

Priority: High

Goal/scope

The goal is to enable system to split products to defined supply partners so that supply partners do not supply products that have been supplied by another partner.

Background

Requisition Splitting - Extension Scenario Analysis is the background of the OpenLMIS team's assement of how to achieve this by extensible means.

Currently, the Zambia eLMIS team have built an enhancement which is able to split the products defined by a facility to different defined suppliers. The  Ministry of health relies on MSL for its supplies of products. However,  some other Organisations can also supplement with the supplies and that case referred to as a supply partner. Currently, CHAZ (churches Association of Zambia) has a number of facilities which they supply certain products. In this case, the facilities do the normal requisition process except the system splits out the products so that the intended supply partners are able to view and supply the product.  In that way the, two supply partners cannot supply the same product to the same facility. The supply partners will have to be defined in the system.

In zambia, Chaz has been defined and apparently serves 59 facilities and 36 products under the ARV program. See picture below.
So when an R&R is sent from one of the defined facilities, the requisition goes through the normal process except it will be viewed by CHAZ if the products being requested are within the products that CHAZ supplies. If some products cannot be supplied by CHAZ, then part of the requisition goes to MSL for supply. In this case, CHAZ will only view what it can supply and MSL can only view what it can supply.  

Assumptions

• Requisition is split after first approval
• Once requisitions are split, they cannot be merged back together

User Stories

Diagrams

Accessing 


See process on adding supply partner


Defining a supply partner. Note the fields involved i.e Source program, Destination program, Supervisory node, Requisition group, Facilities, products and action.



Clicking on facility eg. '59  facilities' will bring the below screen. 

   

Clicking on product e.g '36 products' will bring screen below

Gap Estimation Notes

• Attendees: Josh, Mary Jo, Brandon
• We would build this in core product, not as extension mechanism.
• We would build admin screen to configure which products are supplied by an outside partners.
• This also might be partly supported by product registry.

Edge case questions:

• Should we support a split requisition with zero requested qty? The approver might want to enter an approved qty.
• What do approvers need to view? Supplying partners can view requisitions related to their configuration. Approvers or MOH may want to see all requisitions. (See Requisition Splitting - Extension Scenario Analysis)
• May need another right for "manage supplying partners"

Notes from 8/30/18 meeting

Attendees: Chris Opit (Unlicensed), Chongsun Ahn (Unlicensed), Joanna Szymańska (Deactivated), Łukasz Lewczyński (Deactivated), Nikodem Graczewski (Unlicensed), Sam Im (Deactivated)

Workflow in eLMIS (screenshots from Chris in the comments below):

• The requisition split happens when the requisition has been approved by the district. This is the workflow:
  • Step 1: Requisition is submitted and authorized with requested quantities for products (typically the calculated order qty = the requested quantity but it can be different)
  • Step 2: District supervisor reviews quantities and can edit the approved quantity. If approved quantity is edited (different than requested quantity) then approved quantity is used to calculate packs to ship and total cost.
  • Step 3: District supervisor approves requisition. Requisition status is In_Approval. (Can the approved quantity be edited?)
  • Step 4: Requisition is split (One for standard program, and one for CHAZ)
    • Standard program requisition shows requested qty amounts as zero, approved qty as zero, and packs to ship as zero for the amounts supplied by CHAZ 
    • CHAZ requisition shows requested qty amounts as zero, but packs to ship displays so that CHAZ knows how much to supply (Is requested qty only hidden from CHAZ? Is there any trace back to what was originally requested?)
  • Step 5: Customer service center reviews CHAZ requisition and is allowed to edit approved qty, they complete final approval. Standard program requisition goes through normal approval workflow.
  • Step 6: CHAZ can log in to see status of requisition (what else happens here? if requisition is not approved they can contact whoever is necessary to move the approval along)
  • Step 7: Warehouse converts the requisition to an order, the CHAZ requisition is converted to a csv file and then sent to dropbox. Then uploaded into their system automatically.
  • Step 8: CHAZ can log in to see the approved requisition and packs to ship (compare what is uploaded in their system to eLMIS?)
  • Step 9: CHAZ determines how much they will fulfill and fulfills the order
  • Step 10: Released Requisition can be viewed and shows the standard program and CHAZ requisition as one requisition, with comments on products that were supplied by CHAZ.

Discussed changes to the workflow based on this feature:

Step 6: CHAZ logs in when requisition is approved and has been split to see the packs to ship. They have ability to change packs to ship to match what they will actually fulfill. (This is a want vs need because we don't know if CHAZ would actually use this capability, but it would increase accuracy for OpenLMIS.)

Potential problems:

• After Chaz has supplied the facility, we don't know how much was really supplied by the facility (Chris Opit (Unlicensed) is this actually a true statement? If the Proof of Delivery has the actual fullfilled quantity, is that input into eLMIS?)
• What is the benefit or purpose of zeroing out the requested quantity? Are there any concerns with doing this in OpenLMIS (reporting impact or other problems?) Does understanding what has been requested vs what was actually fulfilled help determine whether the facility is overstocked, stocked out, stocked according to plan, etc?
• What happens if a requisition is rejected? 

Potential development tasks/tickets: (Chongsun Ahn (Unlicensed) & Nikodem Graczewski (Unlicensed) this is not a complete list, so please add any other ideas)

• Split requisition after first approval ( OLMIS-5142 - Getting issue details... STATUS )
• Determine if there are edge case scenarios that must be supported (for deleting, rejecting, editing approved quantities at each approval step)
• Zeroing out requested quantities
• CHAZ logging in to edit requisition? edit order? (and authorization to do so)
• Administrator configuration screens to configure product lists and supply partners ( OLMIS-5353 - Getting issue details... STATUS  and related tickets)

Other important notes:

• Supply partners do not have duplicate product lists, each supply partner has their own discrete list of products they supply to designated health facilities. There aren't scenarios where a product is supplied by more than one partner for the same facility.