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 2012/05/02 22:34:11 UTC

Promotions, mutually exclusive

For example:

We have 3 promotions setup. One for 10% off, one for 20% off, one for 
Free Shipping.

Each have a couple of promo-codes. So it looks something like this:

Promotion: TENPCTOFF, promo-codes TENOFF, TENPCT
Promotion: TWENTYOFF, promo-codes TWENTYOFF, TWENTYPCT
Promotion: FREESHIPPING, promo-code FREESHIP

Assuming all are active, there does not seem to be any way to make these 
mutually exclusive. So, a customer can apply TENPCT + TWENTYOFF + 
FREESHIP. Is that correct? No configurations to make them mutually 
exclusive? Or take the biggest savings as the one to use?

-- 
Best Regards,

Nick Rosser
nrosser@salmonllc.com
O: 516.742.7888 x221
C: 516.901.1720


Re: Promotions, mutually exclusive

Posted by Rishi Solanki <ri...@gmail.com>.
In line.

--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Media Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxmedia.com


On Tue, May 8, 2012 at 12:15 PM, Rishi Solanki <ri...@gmail.com>wrote:

> Here are my two cents on this thread;
> There are two kind of promotions exists in OFBiz, 1) sale promotion and 2)
> non sale promotion.
> For the sale promotion isSale flag set to Y else N. Both promotion in turn
> have their own capabilities that whether they are applicable using promo
> code or not.
>


Sorry the isSale flag is applicable to PriceRules not Promotion. So please
ignore the above point. The below is perfectly right. Thanks!


>
> Now, in this case if sales manager provide all the multiple promo codes to
> single customer then it is totally depended on the business requirement
> they have, so would be good if we go thru the following options;
>
> - Add additional field on the ProductPromo entity that whether user wants
> to apply it if other promotions are already set into the cart or not. It
> will work as once the promotion applies then it will remove all the other
> promotion from the cart.
> - Or add a promotion conflict screen which shows all the promotion
> conflicts within the date range, and sales manager then resolve manually
> one by one.
>
> Sending additional parameter will tightly coupled the things from front
> store and it will always apply the single promotion at a time. If you want
> to go thru this option only, then better to add capability on product store
> level so that the parameter will be configurable.
>
> The reason behind this suggestion is, if any customer receives more than
> one promo code from any website within same date range and if it is not
> mention that the last  code won't work if newer applies in that case
> customer always expect that the both code gives him discount mentioned.
>
> Thanks for raising this, enjoy to think on it.
>
> --
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Media Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxmedia.com
>
>
>
> On Mon, May 7, 2012 at 8:28 PM, <de...@tcs.com> wrote:
>
>> Agreed!!! But just to gauge the promotions that is available in Ofbiz, to
>> the possible / "popular" promotions, I reckon we need a checklist.
>> I am not sure if this is available yet...
>>
>> Deb
>>
>>
>>
>> From:
>> Sanjeev Gupta <su...@sanjeevg.com>
>> To:
>> user@ofbiz.apache.org
>> Date:
>> 05/07/2012 08:15 PM
>> Subject:
>> Re: Promotions, mutually exclusive
>>
>>
>>
>> I Agree Nick, this can't be implemented as a simple "and" "or". With large
>> deployment, there will be several permutation and combinations. It will
>> have
>> to be promotions extension as well as DB entity.
>>
>> The way I look at it, there will be three kind of promotions
>> 1) Promo's that can't be combined with any other promotions - typically
>> the
>> ones that are x% on your shopping carts.
>> 2) Promo's that can clubbed with any other promotions - lets say get
>> sunglasses free with shoes.
>> 3) Finally the ones that can be only clubbed with specific promotions -
>> this
>> is were it'll get complex and will need the matrix or associations.
>>
>> For the first two, you can work with just having another field to flag the
>> promotions. For the third kind may need a new table itself to manage
>> association..
>>
>>
>>
>> -----
>> Rgds
>> Sanjeev
>> www.sanjeevg.com
>> @sanjeevgcom
>> --
>> View this message in context:
>>
>> http://ofbiz.135035.n4.nabble.com/Promotions-mutually-exclusive-tp4604393p4614994.html
>>
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>>
>> =====-----=====-----=====
>> Notice: The information contained in this e-mail
>> message and/or attachments to it may contain
>> confidential or privileged information. If you are
>> not the intended recipient, any dissemination, use,
>> review, distribution, printing or copying of the
>> information contained in this e-mail message
>> and/or attachments to it are strictly prohibited. If
>> you have received this communication in error,
>> please notify us by reply e-mail or telephone and
>> immediately and permanently delete the message
>> and any attachments. Thank you
>>
>>
>>
>

Re: Promotions, mutually exclusive

Posted by Rishi Solanki <ri...@gmail.com>.
Here are my two cents on this thread;
There are two kind of promotions exists in OFBiz, 1) sale promotion and 2)
non sale promotion.
For the sale promotion isSale flag set to Y else N. Both promotion in turn
have their own capabilities that whether they are applicable using promo
code or not.

Now, in this case if sales manager provide all the multiple promo codes to
single customer then it is totally depended on the business requirement
they have, so would be good if we go thru the following options;

- Add additional field on the ProductPromo entity that whether user wants
to apply it if other promotions are already set into the cart or not. It
will work as once the promotion applies then it will remove all the other
promotion from the cart.
- Or add a promotion conflict screen which shows all the promotion
conflicts within the date range, and sales manager then resolve manually
one by one.

Sending additional parameter will tightly coupled the things from front
store and it will always apply the single promotion at a time. If you want
to go thru this option only, then better to add capability on product store
level so that the parameter will be configurable.

The reason behind this suggestion is, if any customer receives more than
one promo code from any website within same date range and if it is not
mention that the last  code won't work if newer applies in that case
customer always expect that the both code gives him discount mentioned.

Thanks for raising this, enjoy to think on it.

--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Media Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxmedia.com


On Mon, May 7, 2012 at 8:28 PM, <de...@tcs.com> wrote:

> Agreed!!! But just to gauge the promotions that is available in Ofbiz, to
> the possible / "popular" promotions, I reckon we need a checklist.
> I am not sure if this is available yet...
>
> Deb
>
>
>
> From:
> Sanjeev Gupta <su...@sanjeevg.com>
> To:
> user@ofbiz.apache.org
> Date:
> 05/07/2012 08:15 PM
> Subject:
> Re: Promotions, mutually exclusive
>
>
>
> I Agree Nick, this can't be implemented as a simple "and" "or". With large
> deployment, there will be several permutation and combinations. It will
> have
> to be promotions extension as well as DB entity.
>
> The way I look at it, there will be three kind of promotions
> 1) Promo's that can't be combined with any other promotions - typically
> the
> ones that are x% on your shopping carts.
> 2) Promo's that can clubbed with any other promotions - lets say get
> sunglasses free with shoes.
> 3) Finally the ones that can be only clubbed with specific promotions -
> this
> is were it'll get complex and will need the matrix or associations.
>
> For the first two, you can work with just having another field to flag the
> promotions. For the third kind may need a new table itself to manage
> association..
>
>
>
> -----
> Rgds
> Sanjeev
> www.sanjeevg.com
> @sanjeevgcom
> --
> View this message in context:
>
> http://ofbiz.135035.n4.nabble.com/Promotions-mutually-exclusive-tp4604393p4614994.html
>
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>

Re: Promotions, mutually exclusive

Posted by de...@tcs.com.
Agreed!!! But just to gauge the promotions that is available in Ofbiz, to 
the possible / "popular" promotions, I reckon we need a checklist.
I am not sure if this is available yet... 

Deb



From:
Sanjeev Gupta <su...@sanjeevg.com>
To:
user@ofbiz.apache.org
Date:
05/07/2012 08:15 PM
Subject:
Re: Promotions, mutually exclusive



I Agree Nick, this can't be implemented as a simple "and" "or". With large
deployment, there will be several permutation and combinations. It will 
have
to be promotions extension as well as DB entity. 

The way I look at it, there will be three kind of promotions
1) Promo's that can't be combined with any other promotions - typically 
the
ones that are x% on your shopping carts.
2) Promo's that can clubbed with any other promotions - lets say get
sunglasses free with shoes. 
3) Finally the ones that can be only clubbed with specific promotions - 
this
is were it'll get complex and will need the matrix or associations. 

For the first two, you can work with just having another field to flag the
promotions. For the third kind may need a new table itself to manage
association.. 



-----
Rgds
Sanjeev
www.sanjeevg.com
@sanjeevgcom
--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Promotions-mutually-exclusive-tp4604393p4614994.html

Sent from the OFBiz - User mailing list archive at Nabble.com.


=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



Re: Promotions, mutually exclusive

Posted by Sanjeev Gupta <su...@sanjeevg.com>.
I Agree Nick, this can't be implemented as a simple "and" "or". With large
deployment, there will be several permutation and combinations. It will have
to be promotions extension as well as DB entity. 

The way I look at it, there will be three kind of promotions
1) Promo's that can't be combined with any other promotions - typically the
ones that are x% on your shopping carts.
2) Promo's that can clubbed with any other promotions - lets say get
sunglasses free with shoes. 
3) Finally the ones that can be only clubbed with specific promotions - this
is were it'll get complex and will need the matrix or associations. 

For the first two, you can work with just having another field to flag the
promotions. For the third kind may need a new table itself to manage
association.. 



-----
Rgds
Sanjeev
www.sanjeevg.com
@sanjeevgcom
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Promotions-mutually-exclusive-tp4604393p4614994.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Promotions, mutually exclusive

Posted by Nick Rosser <nr...@salmonllc.com>.
Sanjeev,

Yep, I agree. Also read some older threads that indicated this was not 
currently available. The suggestions in previous threads was to use the 
conditions to control this. So, if you had two promos ("a" and "B") and 
you didn't want to allow "A" to be combined with "B" then the conditions 
for "B" would need to be defined in a "not condition" for "A".

This could work for simply combinations but when there are several 
promos active at one time then it will be impossible to control. We will 
implement a simple parameter to control this in BigFish -- happy to 
contribute if folks think this is useful. We're also thinking about 
having a matrix of possible combinations for the next version of 
BigFish, again happy to contribute back to the project.

Best Regards,

Nick Rosser
nrosser@salmonllc.com
O: 516.742.7888 x221
C: 516.901.1720


On 5/7/2012 7:19 AM, Sanjeev Gupta wrote:
> I haven't seen anything on these lines either. Will probably need custom
> development to implements this feature.
>
>
>
>
> -----
> Rgds
> Sanjeev
> www.sanjeevg.com
> @sanjeevgcom
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Promotions-mutually-exclusive-tp4604393p4614537.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Promotions, mutually exclusive

Posted by Sanjeev Gupta <su...@sanjeevg.com>.
I haven't seen anything on these lines either. Will probably need custom
development to implements this feature. 




-----
Rgds
Sanjeev
www.sanjeevg.com
@sanjeevgcom
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Promotions-mutually-exclusive-tp4604393p4614537.html
Sent from the OFBiz - User mailing list archive at Nabble.com.