You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Nick Rosser <nr...@salmonllc.com> on 2008/11/14 14:43:21 UTC

BalanceInventoryItems // Returns vs Inventory-Receipt

All,

 

Could someone review our understanding, suggestions for modifications:

 

BalanceInventoryItems, overview

--------------------------------

Essentially checks for back-orders and based on newly available inventory
will try and complete back-orders

- will look at all back-orders for a product (negative atp)

- will check reservations

- will cancel reservations

- will re-establish reservation and complete orders

 

Our Situation

-------------

- our client can be in a position of generating a large number of
back-orders 

- 2500 is not unusual for one day for one product

- if a single qty, of the same product, is "returned" then
BalanceInventoryItems is executed

- due to the large volume, this can take several minutes

 

What we would like

------------------

- if a single qty is returned, we would like to restrict the processing to a
smaller iteration

- at the moment ALL back-orders are considered, leading to minutes of
processing in our situation

 

OR, as an alternative, is this appropriate?

---------------------------------------

- do NOT execute the service BalanceInventoryItems when "returning" products

- later that day, or tomorrow, or whenever, a larger inventory-receipt will
occur 

- for example, receipt of 10,000 items of that product

- inventory "receipt" also calls BalanceInventoryItems, so we'll clear ALL
back-orders at that time

- the fact that this will take several minutes is fine, we can control
receipt to after hours

 

Apologies to long winded thread but hopefully someone can confirm our
understanding / assumptions / approach.

 

Thanks

Nick


Re: BalanceInventoryItems // Returns vs Inventory-Receipt

Posted by Adrian Crum <ad...@yahoo.com>.
Nick,

There is a message thread on the dev mailing list about improving the performance of the BalanceInventoryItems method.

-Adrian


--- On Fri, 11/14/08, Nick Rosser <nr...@salmonllc.com> wrote:

> From: Nick Rosser <nr...@salmonllc.com>
> Subject: BalanceInventoryItems // Returns vs Inventory-Receipt
> To: user@ofbiz.apache.org
> Date: Friday, November 14, 2008, 5:43 AM
> All,
> 
>  
> 
> Could someone review our understanding, suggestions for
> modifications:
> 
>  
> 
> BalanceInventoryItems, overview
> 
> --------------------------------
> 
> Essentially checks for back-orders and based on newly
> available inventory
> will try and complete back-orders
> 
> - will look at all back-orders for a product (negative atp)
> 
> - will check reservations
> 
> - will cancel reservations
> 
> - will re-establish reservation and complete orders
> 
>  
> 
> Our Situation
> 
> -------------
> 
> - our client can be in a position of generating a large
> number of
> back-orders 
> 
> - 2500 is not unusual for one day for one product
> 
> - if a single qty, of the same product, is
> "returned" then
> BalanceInventoryItems is executed
> 
> - due to the large volume, this can take several minutes
> 
>  
> 
> What we would like
> 
> ------------------
> 
> - if a single qty is returned, we would like to restrict
> the processing to a
> smaller iteration
> 
> - at the moment ALL back-orders are considered, leading to
> minutes of
> processing in our situation
> 
>  
> 
> OR, as an alternative, is this appropriate?
> 
> ---------------------------------------
> 
> - do NOT execute the service BalanceInventoryItems when
> "returning" products
> 
> - later that day, or tomorrow, or whenever, a larger
> inventory-receipt will
> occur 
> 
> - for example, receipt of 10,000 items of that product
> 
> - inventory "receipt" also calls
> BalanceInventoryItems, so we'll clear ALL
> back-orders at that time
> 
> - the fact that this will take several minutes is fine, we
> can control
> receipt to after hours
> 
>  
> 
> Apologies to long winded thread but hopefully someone can
> confirm our
> understanding / assumptions / approach.
> 
>  
> 
> Thanks
> 
> Nick