BalanceInventoryItems // Returns vs Inventory-Receipt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

BalanceInventoryItems // Returns vs Inventory-Receipt

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

Reply | Threaded
Open this post in threaded view
|

Re: BalanceInventoryItems // Returns vs Inventory-Receipt

Adrian Crum-2
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 <[hidden email]> wrote:

> From: Nick Rosser <[hidden email]>
> Subject: BalanceInventoryItems // Returns vs Inventory-Receipt
> To: [hidden email]
> 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