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.
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.
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.
Jacopo, if I start to make some changes based on our discussions would you be
willing to to review the changes?
----- Original Message -----
From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com>
To: dev@ofbiz.apache.org
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" <jacopo.cappell...@hotwaxmedia.com>
> To: dev@ofbiz.apache.org
> 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
>
