Page Comparison

...

• String lotCode (required—if the shipment really does not have a code, and only has an expiration date, then users could paste that date into this code field)
• Date expirationDate (optional)
  
• Date manufactureDate (optional)
• reference to a TradeItem (required) — this object gives us access to the Manufacturer name, etc, which will be helpful for display. (in V2 this was a reference to a product)
  
• boolean active flag — potentially a future feature to be able to set a Lot as inactive after it has gone out of circulation; or maybe this is connected to how you archive the lot instead of a DELETE endpoint
• UUID will get assigned to the Lot in ReferenceData, but it won't be visible to the user

...

How do we balance the usability and implementation custom?Implementation custom might require all tradeitems must be tracked by lot. Meaning, tradeitem is only the summary of lots belong to it. No trade item has its own stock card instead only lot has its own stock cardtechnical implementation of turning on and off lots?

Would an implementor want to restrict all stock information to ONLY be tracked within lots? This means a TradeItem by itself couldn't have a SOH amount, but rather it would summarize all the stock amounts across the associated lots. This means all storerooms must associate all stock to a lot.

Would an implementor want to track stock both within and without lots? This means a TradeItem could have a SOH amount plus the stock amounts across lots. This means storerooms could make movements against a tradeItem without an associated lot.  

Usability requires our system provide the flexibility for end users to track products at tradeitem level or the lot level or both. Meaning, a tradeitem can has its own stock card while lots under this tradeitem can have its stock card as well. It is up for end users to create stock events on which stock card. 

Since we do not have a real user yet, it is very hard to make that decision. Instead, we come up with three options which can be discussed broadly with more stakeholders. 

...

Let us consider below user case of turning on lots after stock management tracking has been in place without lots:

When a country implement the OpenLMIS version 3.x, MOH decides not to use lot feature so all products are tracked by trade item or commodity type. Below is an example of the SOH summary in one facility.

Facility HC - HIV program

Let us take Drug A as an example. There are two lots belong to Drug A existing in Facility HC, their lot number are lot2 and lot3 and their SOH are 20 and 80 respectively. However, the storeroom can not record 20 and 80 separately because the system does not have lot information yet. In order to track Drug A, the storeroom manager creates a stock card for Drug itself and the SOH is the summary of lot2 and lot3. 

Later, the MOH decides to track stock at the lot level and system admin adds three lots (lot1, lot2, lot3) for Drug A. After sync with the server, store room manager in facility HC is able to choose three lots under Drug A for HIV program for creating stock events. 

If so,  how will the system deal with the stock card of Drug A?

Open Question : Is it reasonable to assume that when the MOH decides to track lots that they load up lots that have already been distributed? Do we have any information on how an implementer would want to start rolling out lot management?

Solution 1: Mandatory SOH balance check & deactivate original stock card

Before creating stock cards for lot2 and lot3, store room manager must balance the Drug A’s SOH correctly to lot2 and lot3 SOH summary. In this case, the system will provide a UI for storeroom manager to input the initial SOH of lot2 (20) and lot3 (80) and that initial SOH summary must equal with Drug A current SOH (100). This validation is mandatory and storeroom manager is not allowed to create new stock events until he records all the lot information and pass the validation check. After he passes the validation check, then the system will deactivate the stock card of Drug A and storeroom manager will not record stock event for Drug A’s stock card. 
The SOH summary page will change to:

Facility HC - HIV program

...

There is no balance validation check between Drug A SOH and its lot SOH summary but when a lot stock card is created under an existing Drug then the existing stock card of that Drug become invisible for end user. In this case, storeroom manager can choose lo2 or lot3 to create stock event and the initial SOH quantity can be any positive integer and there is no validation check whether the SOH summary of lot2 and lot3 matches Drug A SOH (100). However, after the stock card of lot2 or lot3 is created then Drug A’ s stock card become invisible for storeroom manager and its SOH remains 100 until later custom implementation solution.
The SOH summary page will change to:

Facility HC - HIV program

...

Facility HC - HIV program

...