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?

Kind regards,

Jacopo


> 
> ----- 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
>> 
> 

Reply via email to