Thanks all for your valuable comments, Here is the ticket for the above discussion OFBIZ-9475 <https://issues.apache.org/jira/browse/OFBIZ-9475>
Thanks & Regards Deepak Dixit On Sun, Mar 28, 2010 at 7:20 PM, Jacques Le Roux < [email protected]> wrote: > From: "Jacopo Cappellato" <[email protected]> > >> On Mar 27, 2010, at 6:51 PM, Robert Morley wrote: >> >> Yep; when I attempted to do variance on inventory items for serialized >>> inventory I traveled down that path to the ECA you are referring to. The >>> trouble is that there is another ECA defined a couple of lines up ... >>> >>> <eca entity="InventoryItem" operation="create-store" event="return"> >>> <action service="updateSerializedInventoryTotals" mode="sync"/> >>> </eca> >>> >>> And this one does the set the QOH/ATP based on the status (for >>> serialized only). So after the ECA is fired and updates the InventoryItem >>> to put them in line based on the detail, this one turns around and updates >>> them again and potentially puts them back out of wack. >>> >> >> Yes, I know that serialized items are based on statusId rather than >> inventoryitemdetails and I agree that it would be good to reconcile them to >> the non-serialized logic. >> >> >>> As for the use case for "held" inventory items. If that is a reasonable >>> use case then I agree 100%. What we do is use location for these >>> situations -- for example, when a PO is received we allow the user to >>> receive the inventory into a specific location. So if there is a "review" >>> location that is not pickable then it may move there. Otherwise, it may >>> move into a stockroom location that would be pickable. >>> >>> Putting inventory items on "hold" is perfectly reasonable. I would have >>> to look at the code again, but I wonder how this is done for non-serialized >>> items. >>> >> >> I don't know about serialized inventory, I know there are some OFBiz >> instances in production that are using on-hold status for non-serialized >> inventory. >> >> Does it break the "bundle" of items (InventoryItem) into two so that one >>> can be on "hold" while the other one can have no status? Currently, the >>> "INV_ON_HOLD" is defined under a "SERIALIZED_INV_ITEM" parent so it is >>> actually somewhat invalid to even set this on non-serialized items. >>> >> >> The one I am talking about is INV_NS_ON_HOLD >> >> >>> Jacopo, if I start to make some changes based on our discussions would >>> you be willing to to review the changes? >>> >> >> Sure. >> To all committers: do you agree with the plan to reimplement serialized >> inventory QOH/ATP to be based on InventoryItemDetail rather than >> InventoryItem.statusId? >> > > Just to be sure to completly understand: does anybody knows why it's done > with InventoryItem.statusId for the moment? > > Thanks > > Jacques > > > Kind regards, >> >> Jacopo >> >> >> >>> ----- Original Message ----- >>> From: "Jacopo Cappellato" <[email protected]> >>> To: [email protected] >>> Sent: Saturday, March 27, 2010 12:22:47 PM >>> Subject: Re: Resolving inconsistency between serialized and >>> non-serialized inventory >>> >>> On Mar 27, 2010, at 3:03 PM, Robert Morley wrote: >>> >>> 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. >>>> >>>> >>> I was referring to the following eca: >>> >>> <!-- The InventoryItemDetail entity should never be updated/stored or >>> deleted/removed, but we'll catch those too anyway... --> >>> <eca entity="InventoryItemDetail" operation="create-store-remove" >>> event="return"> >>> <action service="updateInventoryItemFromDetail" mode="sync"/> >>> </eca> >>> >>> Your comment about holds is interesting -- I wonder, however, where the >>>> use case is to hold individual item pieces. >>>> >>> >>> For example you receive some items into the warehouse, and you want to >>> "hold" them before quality control etc.. >>> >>> Jacopo >>> >>> 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 >>>> >>>> >>> >> >> > >
