Promo items

[Ean Schuessler]

The OFBiz promo code processes product quantities as singletons. If a
large quantity of an item is added to the cart (ie. 2,000) and there is
a promo for that product then the result is both a large quantity of
promo adjustments as well as a long processing time for the cart. For
some industries large order quantities are perfectly reasonable but the
current OFBiz design will fail.

Does anyone have any perspective on this issue? One possible solution
would be to remove the part of the promo design that reduces promo items
to singletons. I realize that introduces other challenges but they seem
to be deterministic. The singleton processing approach seems like an
effort to keep the implementation simple.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Bob Morley]

We have not implemented promos to date, but can you comment on how the  
promo adjustments would be created for a quantity like 1.542?  I would  
agree rhat having a single adjustment for the order item line (per  
promo) would make the most sense.

Bob

On 2010-04-28, at 1:16 PM, Ean Schuessler <[hidden email]> wrote:

> The OFBiz promo code processes product quantities as singletons. If a
> large quantity of an item is added to the cart (ie. 2,000) and there  
> is
> a promo for that product then the result is both a large quantity of
> promo adjustments as well as a long processing time for the cart. For
> some industries large order quantities are perfectly reasonable but  
> the
> current OFBiz design will fail.
>
> Does anyone have any perspective on this issue? One possible solution
> would be to remove the part of the promo design that reduces promo  
> items
> to singletons. I realize that introduces other challenges but they  
> seem
> to be deterministic. The singleton processing approach seems like an
> effort to keep the implementation simple.
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

[Adam Heath-2]

Robert Morley wrote:
> We have not implemented promos to date, but can you comment on how the
> promo adjustments would be created for a quantity like 1.542?  I would
> agree rhat having a single adjustment for the order item line (per
> promo) would make the most sense.

You misunderstand.  Add stock for 5000 items for a PROMO_GWP.  Add
enough stock for the parent item too.  Then add a quantity of 'two
thousand' on the original product.  Watch ofbiz fall over.

I think you are interpetting the ',' as a '.'.

>
> Bob
>
> On 2010-04-28, at 1:16 PM, Ean Schuessler <[hidden email]> wrote:
>
>> The OFBiz promo code processes product quantities as singletons. If a
>> large quantity of an item is added to the cart (ie. 2,000) and there is
>> a promo for that product then the result is both a large quantity of
>> promo adjustments as well as a long processing time for the cart. For
>> some industries large order quantities are perfectly reasonable but the
>> current OFBiz design will fail.
>>
>> Does anyone have any perspective on this issue? One possible solution
>> would be to remove the part of the promo design that reduces promo items
>> to singletons. I realize that introduces other challenges but they seem
>> to be deterministic. The singleton processing approach seems like an
>> effort to keep the implementation simple.
>>
>> --
>> Ean Schuessler, CTO
>> [hidden email]
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>

[Bob Morley]

On Apr 29, 2010, at 2:31 PM, Adam Heath wrote:

> Robert Morley wrote:
>> We have not implemented promos to date, but can you comment on how  
>> the
>> promo adjustments would be created for a quantity like 1.542?  I  
>> would
>> agree rhat having a single adjustment for the order item line (per
>> promo) would make the most sense.
>
> You misunderstand.  Add stock for 5000 items for a PROMO_GWP.  Add
> enough stock for the parent item too.  Then add a quantity of 'two
> thousand' on the original product.  Watch ofbiz fall over.
>
> I think you are interpetting the ',' as a '.'.
>

I got the impression when Ean said "then the result is both a large  
quantity of promo adjustments" that Ofbiz was creating an adjustment  
for each of the product quantities.  That is to say if you had an item  
with a quantity of 10 with promo it would add 10 individual  
adjustments ... and when you went up really high it caused issues.  Is  
that not the case?  My question was actually, if that is the case what  
would ofbiz due with quantities that were not evenly divisible by 1  
(i.e. 1.542).

[Adam Heath-2]

Robert Morley wrote:

> On Apr 29, 2010, at 2:31 PM, Adam Heath wrote:
>
>> Robert Morley wrote:
>>> We have not implemented promos to date, but can you comment on how the
>>> promo adjustments would be created for a quantity like 1.542?  I would
>>> agree rhat having a single adjustment for the order item line (per
>>> promo) would make the most sense.
>>
>> You misunderstand.  Add stock for 5000 items for a PROMO_GWP.  Add
>> enough stock for the parent item too.  Then add a quantity of 'two
>> thousand' on the original product.  Watch ofbiz fall over.
>>
>> I think you are interpetting the ',' as a '.'.
>>
>
> I got the impression when Ean said "then the result is both a large
> quantity of promo adjustments" that Ofbiz was creating an adjustment for
> each of the product quantities.  That is to say if you had an item with
> a quantity of 10 with promo it would add 10 individual adjustments ...
> and when you went up really high it caused issues.  Is that not the
> case?  My question was actually, if that is the case what would ofbiz
> due with quantities that were not evenly divisible by 1 (i.e. 1.542).

Well, I don't know about your question, it really should be a separate
thread(or change the subject).

What we are seeing, is that getSurvey is being called on the product,
2000+ times.  It's also hitting the database quite a bit, because of
one missing findByAndCache call on ProductCategoryMember(I'll send a
patch for this one eventually).

There's no reason to call getSurvey over and over with the same
parameters.  However, there's also no way for it to cache that call.
The real fix here is to allow each promo action to 'swallow' as much
quantity as is allowed, instead of the higher code looping once for
each whole number of quantity.

>

[Bob Morley]

On Apr 29, 2010, at 5:54 PM, Adam Heath wrote:

> Well, I don't know about your question, it really should be a separate
> thread(or change the subject).
>
> What we are seeing, is that getSurvey is being called on the product,
> 2000+ times.  It's also hitting the database quite a bit, because of
> one missing findByAndCache call on ProductCategoryMember(I'll send a
> patch for this one eventually).
>
> There's no reason to call getSurvey over and over with the same
> parameters.  However, there's also no way for it to cache that call.
> The real fix here is to allow each promo action to 'swallow' as much
> quantity as is allowed, instead of the higher code looping once for
> each whole number of quantity.
>

Yes, I think it should do exactly what you are saying -- all I was  
saying was that you are in the code right now and it would be  
interesting (on a related matter) to know how it would handle quantity  
fractions.  If you are going to rework it one of the requirements  
should be that it handles these properly.  Being un-familiar with  
promotions I can only speculate that I should be able to create a  
promotion where if I buy a 1/2 oz of a product I should be able to get  
a 1/4 oz free.  And based on the original post I don't think that  
would work either.

[rajsaini]

Hello Ean,

I am having similar issue regarding promo. Have you solved this issue? It would be great if you can share your thoughts.

Thanks,

Raj