There is a balance inventory items service that executes and keeps the details and materialized QOH/ATP in-line. And this service does it for both types of inventory items -- the trouble is that there is another service that executes specifically for serialized inventory items and it hardcodes the values based on the status. Something like if "AVAILABLE" set 1/1, if "DELIVERED" set 0/0, else set it to 1/0. When you stop doing this I think you notice that the InventoryItemDetail is not created for serialized inventory when products are received.
Your comment about holds is interesting -- I wonder, however, where the use case is to hold individual item pieces. For example, I would have thought if you are doing an order and want to put it on hold it effectively has the items on hold. Same with a transfer, etc. I would have thought that doing these things would do a reservation against the inventory items and reduce the ATP. To do otherwise would require breaking non-serialized inventory items into buckets each time you want to "hold" a few. But I could certainly be wrong here ... ----- Original Message ----- From: "Jacopo Cappellato" <[email protected]> To: [email protected] Sent: Saturday, March 27, 2010 5:15:24 AM Subject: Re: Resolving inconsistency between serialized and non-serialized inventory On Mar 26, 2010, at 8:46 PM, Bob Morley wrote: > - 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. Isn't this already done in this way? Jacopo
