You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ean Schuessler <ea...@brainfood.com> on 2010/04/28 19:15:54 UTC
Promo items
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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Promo items
Posted by rajsaini <ra...@gmail.com>.
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
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Promo-items-tp2073637p3318906.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Promo items
Posted by Robert Morley <rm...@emforium.com>.
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.
Re: Promo items
Posted by Adam Heath <do...@brainfood.com>.
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.
>
Re: Promo items
Posted by Robert Morley <rm...@emforium.com>.
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).
Re: Promo items
Posted by Adam Heath <do...@brainfood.com>.
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 <ea...@brainfood.com> 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
>> ean@brainfood.com
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>
Re: Promo items
Posted by Robert Morley <rm...@emforium.com>.
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 <ea...@brainfood.com> 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
> ean@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>