availableToPromiseTotal

["skip@theDevers" <sk...@thedevers.org>]

In my wonderings through the ofbiz code, I have noted that
availableToPromiseTotal for items on an order is not reduced until
createOrder is called.  I expected availableToPromiseTotal to be reduced
(assuming there was any) when the "Add To Order" button was pressed.

This means that if there are 10 people using your system and 5 want the same
product which has 3 in stock, all 5 will show AOH=3 when they press Add to
Order, but two will get their order rejected when the order is processed.

This is easy enough to change, but I wondered why it was done this way in
case I am missing something.

Skip

Re: availableToPromiseTotal

[Jonathon -- Improov <jo...@improov.com>]

Agreed. The field availableToPromise should only be updated when an actual commitment is made.

Same for inventory reservations.

Question is, will the availableToPromise field, if value is 1, be put into negative value when a 
few customers do an "add-to-cart" at the same time, and then check out at the same time? I think 
not. A simple race should settle it, and decide which customer gets the single available item.

For inventory reservations, I think an exception is thrown during order creation if the inventory 
is no longer available to be reserved. That is, if it is somehow taken away between "add-to-cart" 
and "order creation".

Jonathon

David E Jones wrote:
> 
> Most retailers don't consider an add to cart to be sufficient commitment 
> on the customer's part to even try to guarantee that they will get it. I 
> have actually done stuff like that before, but I really wouldn't 
> recommend it because you end up with lots of funny exceptions and it is 
> too easy for data to get in bad states, or for reservations to never get 
> cleaned up and such. This also puts a lot of traffic on certain entities 
> too and can increase chances of locking and other concurrency problems.
> 
> If you DO want to do this, I would recommend NOT using the current 
> availableToPromise counts and the OrderItemShipGrpInvRes records as 
> those are meant for something a little different, and a little more 
> important to get write (ie reduce chances of interfering with it and 
> what what).
> 
> -David
> 
> 
> On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:
> 
>> In my wonderings through the ofbiz code, I have noted that
>> availableToPromiseTotal for items on an order is not reduced until
>> createOrder is called.  I expected availableToPromiseTotal to be reduced
>> (assuming there was any) when the "Add To Order" button was pressed.
>>
>> This means that if there are 10 people using your system and 5 want 
>> the same
>> product which has 3 in stock, all 5 will show AOH=3 when they press 
>> Add to
>> Order, but two will get their order rejected when the order is processed.
>>
>> This is easy enough to change, but I wondered why it was done this way in
>> case I am missing something.
>>
>> Skip
>>
> 

Re: availableToPromiseTotal

[David E Jones <jo...@hotwaxmedia.com>]

Abandoned carts are something we already detect, and save the  
contents of to the database for analysis. It is possible to do  
something similar to cancel reservations, but this is one of many  
things that you'll run into that just isn't totally reliable and over  
thousands of operations eventually adds up to lots of work to monitor  
and clean up.

-David


On Oct 4, 2007, at 7:35 PM, skip@theDevers wrote:

> Thanks David, I'll use the code as is and see if anyone bitches.  I  
> agree
> that the logic is complicated, especially considering that a person  
> can just
> exit their browser and leave things hanging.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: Thursday, October 04, 2007 6:21 PM
> To: user@ofbiz.apache.org
> Subject: Re: availableToPromiseTotal
>
>
>
> Most retailers don't consider an add to cart to be sufficient
> commitment on the customer's part to even try to guarantee that they
> will get it. I have actually done stuff like that before, but I
> really wouldn't recommend it because you end up with lots of funny
> exceptions and it is too easy for data to get in bad states, or for
> reservations to never get cleaned up and such. This also puts a lot
> of traffic on certain entities too and can increase chances of
> locking and other concurrency problems.
>
> If you DO want to do this, I would recommend NOT using the current
> availableToPromise counts and the OrderItemShipGrpInvRes records as
> those are meant for something a little different, and a little more
> important to get write (ie reduce chances of interfering with it and
> what what).
>
> -David
>
>
> On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:
>
>> In my wonderings through the ofbiz code, I have noted that
>> availableToPromiseTotal for items on an order is not reduced until
>> createOrder is called.  I expected availableToPromiseTotal to be
>> reduced
>> (assuming there was any) when the "Add To Order" button was pressed.
>>
>> This means that if there are 10 people using your system and 5 want
>> the same
>> product which has 3 in stock, all 5 will show AOH=3 when they press
>> Add to
>> Order, but two will get their order rejected when the order is
>> processed.
>>
>> This is easy enough to change, but I wondered why it was done this
>> way in
>> case I am missing something.
>>
>> Skip
>>
>
>

RE: availableToPromiseTotal

["skip@theDevers" <sk...@thedevers.org>]

Thanks David, I'll use the code as is and see if anyone bitches.  I agree
that the logic is complicated, especially considering that a person can just
exit their browser and leave things hanging.

Skip

-----Original Message-----
From: David E Jones [mailto:jonesde@hotwaxmedia.com]
Sent: Thursday, October 04, 2007 6:21 PM
To: user@ofbiz.apache.org
Subject: Re: availableToPromiseTotal



Most retailers don't consider an add to cart to be sufficient
commitment on the customer's part to even try to guarantee that they
will get it. I have actually done stuff like that before, but I
really wouldn't recommend it because you end up with lots of funny
exceptions and it is too easy for data to get in bad states, or for
reservations to never get cleaned up and such. This also puts a lot
of traffic on certain entities too and can increase chances of
locking and other concurrency problems.

If you DO want to do this, I would recommend NOT using the current
availableToPromise counts and the OrderItemShipGrpInvRes records as
those are meant for something a little different, and a little more
important to get write (ie reduce chances of interfering with it and
what what).

-David


On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:

> In my wonderings through the ofbiz code, I have noted that
> availableToPromiseTotal for items on an order is not reduced until
> createOrder is called.  I expected availableToPromiseTotal to be
> reduced
> (assuming there was any) when the "Add To Order" button was pressed.
>
> This means that if there are 10 people using your system and 5 want
> the same
> product which has 3 in stock, all 5 will show AOH=3 when they press
> Add to
> Order, but two will get their order rejected when the order is
> processed.
>
> This is easy enough to change, but I wondered why it was done this
> way in
> case I am missing something.
>
> Skip
>

Re: availableToPromiseTotal

[David E Jones <jo...@hotwaxmedia.com>]

Most retailers don't consider an add to cart to be sufficient  
commitment on the customer's part to even try to guarantee that they  
will get it. I have actually done stuff like that before, but I  
really wouldn't recommend it because you end up with lots of funny  
exceptions and it is too easy for data to get in bad states, or for  
reservations to never get cleaned up and such. This also puts a lot  
of traffic on certain entities too and can increase chances of  
locking and other concurrency problems.

If you DO want to do this, I would recommend NOT using the current  
availableToPromise counts and the OrderItemShipGrpInvRes records as  
those are meant for something a little different, and a little more  
important to get write (ie reduce chances of interfering with it and  
what what).

-David


On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:

> In my wonderings through the ofbiz code, I have noted that
> availableToPromiseTotal for items on an order is not reduced until
> createOrder is called.  I expected availableToPromiseTotal to be  
> reduced
> (assuming there was any) when the "Add To Order" button was pressed.
>
> This means that if there are 10 people using your system and 5 want  
> the same
> product which has 3 in stock, all 5 will show AOH=3 when they press  
> Add to
> Order, but two will get their order rejected when the order is  
> processed.
>
> This is easy enough to change, but I wondered why it was done this  
> way in
> case I am missing something.
>
> Skip
>