Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

What is a Lot in v3

A Lot object has the following:

  • 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

This definition of Lot is similar to v2, with some modifications. See https://github.com/OpenLMIS/open-lmis/blob/master/modules/stock-management/src/main/java/org/openlmis/stockmanagement/domain/Lot.java for V2 domain object.

New Endpoints in ReferenceData

  • GET /api/lots?... - search and return all matching Lots; optionally query by any TradeItemID, expirationDate, and/or lotCode*
  • GET /api/lots/{id} - get a single Lot by its UUID, not searching by TradeItem
  • POST /api/lots - create a new Lot with a TradeItemID, lotCode, and optional fields (listed above)
  • PUT / api/lots/{id} - update or replace a Lot by UUID


*If the TradeItem has no Lots (meaning Stock Service should create stock cards by the trade item, not by Lots), there will be zero lots coming back from this endpoint. The endpoint GET /api/lots?tradeItemID=1234&active=true would return a 200 with empty response object {}. We don't return a 404 NOT FOUND for these situations.

Permissions

For now, the ability to GET lots is based on the same permissions as ability to get the trade items, namely ORDERABLES_MANAGE permission. And the ability to POST and PUT lots is based on ORDERABLES_MANAGE permission. This is a global, sysadmin permission—it applies to all programs and facilities with no granular rights at this time.

The Stock Management service will use a service-level token that will allow that service to hit any of the Lot endpoints.

For now, we expect the Stock Management UI will not need to hit the Lot endpoints directly. We expect the UI would query the Stock service, and the Stock service would provide the data including LotCode and ExpirationDate which it gets from the ReferenceData service. This is the pattern already used for the Requisition UI to query the Requisition Service to get Orderables data. The Orderables and Lots endpoints require administrative permissions that most end-users filling out a requisition or a stock inventory would not have.

Impact to Existing Endpoints

None. This work involves adding new endpoints into ReferenceData (referencedata-3.1.0), but does not change or break any existing endpoints. In particular, TradeItems endpoints already in ReferenceData would not return and Lot information inside them.

Process to Manage Lots

  1. Lot Management UI screens (view, create, update) - within the Products admin area, in the TradeItem record, some section or modal to see the current Lots and to update any one of them, or add a new Lot
  2. CSV uploads (desired)

Roles and Responsibilities

  • Reference Data API Endpoints
    • Teams TOP/AYIC to implement Lot Management endpoints in Reference Data 3.1.0
  • Lot Management UI screens (in ReferenceData UI)
    • Team ILL to design Lot Management UI screens
    • Teams TOP/AYIC to implement UI screens (maybe, pending budget/time priorities)
  • Stock Management Service and UI
    • Team Panda is designing and implementing UI and stock endpoints (based on stock workshop scope for ref-distro 3.1 release)

Future Functionality (not in 3.1 scope)

  • Audit Log: ability to see the history of when a Lot was created, edited (when and by whom), de-activated. The would show us the life-cycle of each Lot. To our knowledge, this feature is not captured in the current Roadmap; it's just an idea.
  • CSV uploads (we have other tickets in Roadmap for CSV uploads, but uploading Lots are not yet their own ticket)
  • Potentially look into allowing allowing end users to add in lots/tradeItems. 3.1 aims to achieve lot management centrally.

Open Questions

  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: ___ 
  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: _____
    2. Proposed Solution A: Do not have an inactive flag in Stock for 3.1 release.
    3. 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.


(This wiki page was originally created in response to ticket OLMIS-2108 - Getting issue details... STATUS ).

  • No labels

OpenLMIS: the global initiative for powerful LMIS software