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

...

Product Committee please review the following three solutions and let us know which you have questions on, which you prefer and why.

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 (60) and that initial SOH summary must equal with Drug A current SOH (80). 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. This would not allow an allocation of the 20 that was donated since it would not have an approved lot amount. The user would need to make an adjustment to remove the 20 from the SOH.

...

Solution 2: Freely record lot & hide original stock card

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 lot2 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 a decision is made on how to deal with those stock amounts. A user would not need to make an adjustment to remove the 20 since it would be ignored

...

The original 100 for Drug A is now invisible.

Solution 3: Keep both lot and original stock cards

There is no mandatory balance validation check between Drug A SOH and its lot SOH summary. Storeroom manager can create stock event on either Drug’s original stock card or the lot’s stock card but the original stock card is independent from lots’ stock card. In the case, there will be three stock cards for Drug A in the system: Drug A' No Lot defined' stock card, Lot2 stock card, Lot3 stock card. Essentially we do not assume the stock on hand belongs to Lot2 and Lot3. IF it does, then the end user must make adjustments to the DrugA No Lot defined SOH reduces to the appropriate level.

...

1. Josh, are there any other GS1 fields or naming changes needed?

2. If a TradeItem has no Lots, then has StockCards with inventory and adjustments with no Lots, then later on the TradeItem has lots, how does that impact the Stock service?

   1. Proposed solution A: For any TradeItem, allow the simultaneous existence of stock cards that have Lots along with stock cards that do not have Lots. We simply need our software to be flexible since Lots might get introduced into the supply chain at different times or in different locations, even after some stock cards and physical inventories exist in the software.

   2. Proposed solution B: For any TradeItem, it has a configuration to specify whether it is managed using Lots or not. To change a TradeItem to begin using Lots, that configuration change would modify the Orderables and Stock Cards in order to begin tracking stock in Lots. The pre-existing stock balances might be transferred to a "dummy lot".

3. If a TradeItem has Lots and Stock service has inventories and adjustments associated with it, and then the TradeItem stops using Lots (or stops tracking Lots) and the system needs to transition to tracking the TradeItem without Lots data, how do users do that in Stock Management 3.1?

   1. Proposed solution A: (same as A above).

   2. Proposed Solution B: (similar to B above—an administrator would change the configuration and that would move all of the current quantities from Lots back into a stock card for the overall TradeItem with no Lot information).

4. Inactive Flag on Lots: For future functionality (likely not for 3.1 release), we may need to discuss the Inactive flag and any business or process rules around who sets that flag, when, and why. EG, in a scenario where a TradeItem has Lots and Stock service has inventories and adjustments associated with it, and then the Administrator marks all those Lots as inactive (because they have expired or because they are out of circulation), if the Administrator does not enter any new Lots information for the new lots in circulation, and users of Stock Management are conducting inventories and adjustments with those new Lots that are not yet in the system, how does the system handle that?

   1. Proposed Solution A: Do not have an inactive flag in Stock for 3.1 release.

   2. Proposed Solution B: Do not allow administrators to mark Lots as inactive if there is any stock SOH quantity at any facility for a given Lot.

5. Does Stock Management need an "adjustment" reason to move stock from one lot to another, in cases where it was inaccurately reported? Or in cases where it was previously inventoried with no Lot information but now we want to start tracking it by Lots?

   1. Proposed solution: For now we assume users might need to do this manually (pick some existing adjustment reason to reduce Lot A by 100 and increase Lot B by 100; or reduce count without a Lot by 100 and increase count in Lot C by 100). System administrators might choose to add a Reason to their system that is more descriptive for this case.

User Stories

(This wiki page was originally created in response to ticket

...