One of the issues that has cropped up from time to time for us is the inconsistency with how serialized and non-serialized inventory are handled. Serialized inventory availability to based primarily on the statusId on the InventoryItem entity while non-serialized inventory is based the materialized quantityOnHandTotal and availableToPromiseTotal on the InventoryItem entity (with actual details on the InventoryItemDetail entity).
>From my understanding it is common knowledge that there are a number of problems around support for serialized inventory. The two things that have brought this into focus for us are (1) inventory item variance support and (2) inventory level reporting requirements. In the first case, it appears serialized inventory is not supported at all (likely partially due to not making business sense for a positive variance). In the second case, we wanted to report on historic inventory levels which would be best done by calculating levels from the InventoryItemDetail entity. The trouble with this is that serialized inventory are not properly reflected in this entity (sales appear to be reflected by not receiving via a PO). What we would like to do is talk about removing statusId completely from the inventoryItem entity and using a consistent approach regardless of the type of inventory. This implies that the QOH/ATP would be materialized on the inventoryItem (in practice it would only be 0 or 1 for serialized pieces) and the accumulation would be proper based on the InventoryItemDetail. Business logic that makes decisions based on serialized vs. non-serialized would be brought together. Current state exposes 13 inventory status items. Six of these are not in use at all including both status items that are of type "non-serialized). Of the six statuses that are currently reference in business logic and/or presentment they are in a small number of areas of the application: reservation, issuance, transfer, returns, and Oagis integration. In all of these situations current business logic exists for handling non-serialized inventory so it should be reasonable to handle serialized in the same manner. For example, availability for serialized inventory items would be achieved using the QOH / ATP numbers that are used in the logic for the non-serialized equivalents. >From the data model resource book, there was a Inventory Item Status Type modeled with the intent of storing the current condition of the items (examples, good, being repaired, defective, scrap, etc) - page 85. The recommendation I would like to make is : - the set of statusItems to reflect the status that seemed to be intended in the book; that is the current state of that bucket of inventory. Understanding that if non-serialized inventory is going to take on a state that only reflects some of the items, the inventory item would be broken into two buckets. - inventory item variance would be applicable to all kinds of inventory (as per page 86). Business logic would exist to ensure that the result of a variance would not change the QOH/ATP totals for a serialized inventory item to be anything other than 0 or 1. - business logic where the current statusId is used would be collapsed to work as non-serialized inventory works now (obviously with an eye to ensuring that the business result is the same for serialized items). What I mean here is that in Oagis suggests that a serialized piece is "ON_HOLD" it would be created such that the QOH = 1 while the ATP = 0. - reasonable migration put into place to ensure backwards compatibility; not sure what this means but it likely means ensuring the materialized QOH/ATP are accurate for serialized goods based on the current statusId. It also likely means that the InventoryItemDetail records result in the same total as what is materialized on the InventoryItem table. - consider an enhancement to existing presentment based services that prevents the QOH/ATP values from being set directly. The line of thinking is that they should be materialized via ECA based on operations to the InventoryItemDetail entity. We would like to get working on this as soon as possible; if the community thinks that this makes sense for the product and we can get a contributor that would be willing to code review then we can get started. My hope is that we would end up with more consistent operation and properly working serialized inventory management. -- View this message in context: http://n4.nabble.com/Resolving-inconsistency-between-serialized-and-non-serialized-inventory-tp1692758p1692758.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
