Use of module 'Sale Promotion'

[Christophe (.net)]

Hi

A note or 2 on the use of this module (v4.4).
1) I recognize that the terms promotion means a decrease in price but if
the rule generates a price higher than the unit price the promotion is
not applied. I think it's a shame, it might be necessary to change the
name of the module :-)
2) Another point that stems from the first one, it is necessary that ALL
the lines having an applicable promotion causes a reduction of the price
otherwise nothing is applied even if certain lines could have a
promotion, it's very restrictive in real life, no ?

My 2 cents

regards.
--
Christophe CRIER
Adiczion - http://adiczion.com

[Cédric Krier]

On 2017-11-10 15:36, Christophe (.net) wrote:
> A note or 2 on the use of this module (v4.4).
> 1) I recognize that the terms promotion means a decrease in price but if
> the rule generates a price higher than the unit price the promotion is
> not applied. I think it's a shame, it might be necessary to change the
> name of the module :-)

I do not understand.

> 2) Another point that stems from the first one, it is necessary that ALL
> the lines having an applicable promotion causes a reduction of the price
> otherwise nothing is applied even if certain lines could have a
> promotion, it's very restrictive in real life, no ?

What are you proposing to decide if a promotion applies or not?
How would you choose between two promotions?

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Christophe (.net)]

Le 10/11/2017 à 16:51, Cédric Krier a écrit :
> On 2017-11-10 15:36, Christophe (.net) wrote:
>> A note or 2 on the use of this module (v4.4).
>> 1) I recognize that the terms promotion means a decrease in price but if
>> the rule generates a price higher than the unit price the promotion is
>> not applied. I think it's a shame, it might be necessary to change the
>> name of the module :-)
>
> I do not understand.

To not limit the operation to a single price decrease but also allow an
increase ...

>
>> 2) Another point that stems from the first one, it is necessary that ALL
>> the lines having an applicable promotion causes a reduction of the price
>> otherwise nothing is applied even if certain lines could have a
>> promotion, it's very restrictive in real life, no ?
>
> What are you proposing to decide if a promotion applies or not?

For example the display of the 2 fields (before and after promotion) or
a flag.

> How would you choose between two promotions?

Perhaps a priority in promotions and take the first that matches.

Cordialement

[Cédric Krier]

On 2017-11-10 17:15, Christophe (.net) wrote:
>
>
> Le 10/11/2017 à 16:51, Cédric Krier a écrit :
> > On 2017-11-10 15:36, Christophe (.net) wrote:
> >> A note or 2 on the use of this module (v4.4).
> >> 1) I recognize that the terms promotion means a decrease in price but if
> >> the rule generates a price higher than the unit price the promotion is
> >> not applied. I think it's a shame, it might be necessary to change the
> >> name of the module :-)
> >
> > I do not understand.
>
> To not limit the operation to a single price decrease but also allow an
> increase ...

Since when customer will agree to have a promotion that increase the
price?

> >> 2) Another point that stems from the first one, it is necessary that ALL
> >> the lines having an applicable promotion causes a reduction of the price
> >> otherwise nothing is applied even if certain lines could have a
> >> promotion, it's very restrictive in real life, no ?
> >
> > What are you proposing to decide if a promotion applies or not?
>
> For example the display of the 2 fields (before and after promotion) or
> a flag.

I do not understand. How that makes the system decide to change the
price or not?

> > How would you choose between two promotions?
>
> Perhaps a priority in promotions and take the first that matches.

Why limiting to a single promotion?

[Cédric Krier]

I want to be clear about the design. It was done with the idea to
apply on a set of line only one promotion. This way promotion does not
accumulate (there is a unique field 'promotion' on sale line).
I think we could maybe change the test to decide line by line if the
promotion applied instead of having a unique test on all lines.

But the decision is to decide how to apply such kind of promotions:

- 15% if quantity of product is greater than 10kg.
- 10% for products of category "Fruits".


So now we have a sale with:

- 5kg of potatoes at 10€/kg
- 5kg of apples at 15€/kg
- 3u of melons at 20€/u

Should the sale be:

A)
- potatoes: 8.5€/kg
- apples: 13.5€/kg
- melons: 18€/u

B)
- potatoes: 8.5€/kg
- apples: 12.75€/kg
- melons: 18€/u

C)
- potatoes: 8.5€/kg
- apples: 12.75€/kg
- melons: 20€/u

For now, we have option C implemented, but maybe we should implement B.

[Christophe (.net)]

For case B, if it is sold 15kg of apples you think to apply both
promotions at once?

Regard

[Cédric Krier]

I do not understand the question. In the example of case B, both
promotions are already applied.

[Axel Braun]

But why? apples is less than 10kg, so only 10% for category 'fruits' should
apply.

In general one would expect that all matching conditions are applied. So if
15kg apples are sold, I would expect to see 11,25€/kg.

Cheers
Axel

[Cédric Krier]

On 2017-11-19 13:28, Axel Braun wrote:
> Am Samstag, 18. November 2017, 23:04:46 CET schrieb Cédric Krier:
> > On 2017-11-18 22:37, Christophe (.net) wrote:
> > > Le 11/11/2017 à 11:18, Cédric Krier a écrit :
> > > > I want to be clear about the design. It was done with the idea to
> > > > apply on a set of line only one promotion. This way promotion does not
> > > > accumulate (there is a unique field 'promotion' on sale line).
> > > > I think we could maybe change the test to decide line by line if the
> > > > promotion applied instead of having a unique test on all lines.
> > > >
> > > > But the decision is to decide how to apply such kind of promotions:
> > > > - 15% if quantity of product is greater than 10kg.
> > > > - 10% for products of category "Fruits".

I think I must clearly write how those percentages will be encoded in
the module:

-15%: unit_price * 0.85
-10%: unit_price * 0.9

> > > > So now we have a sale with:
> > > > - 5kg of potatoes at 10€/kg
> > > > - 5kg of apples at 15€/kg
> > > > - 3u of melons at 20€/u
> > > >
> > > > Should the sale be:
> > > >
> > > > A)
> > > >
> > > > - potatoes: 8.5€/kg
> > > > - apples: 13.5€/kg
> > > > - melons: 18€/u
> > > >
> > > > B)
> > > >
> > > > - potatoes: 8.5€/kg
> > > > - apples: 12.75€/kg
> > > > - melons: 18€/u
> > > >
> > > > C)
> > > >
> > > > - potatoes: 8.5€/kg
> > > > - apples: 12.75€/kg
> > > > - melons: 20€/u
> > > >
> > > > For now, we have option C implemented, but maybe we should implement B.
> > >
> > > For case B, if it is sold 15kg of apples you think to apply both
> > > promotions at once?
> >
> > I do not understand the question. In the example of case B, both
> > promotions are already applied.
>
> But why? apples is less than 10kg, so only 10% for category 'fruits' should
> apply.

5kg of apples + 5kg of potatoes = 10kg of product.

> In general one would expect that all matching conditions are applied. So if
> 15kg apples are sold, I would expect to see 11,25€/kg.

The module formula are based by default on the sale price so the
promotions are not cumulative. Non cumulative promotion is the most
common practice as far as I have seen. But it is possible to add other
base price for computation which may include previous promotions.
Such case the formula would be written:

current_price - (unit_price * 0.15)

[Axel Braun]

In this case the rebate is not on item, but on header (order) level, as the
criteria '15% if quantity of product is greater than 10kg' is fulfilled for
the overall order. 15% should than apply additionally on the order.

> > In general one would expect that all matching conditions are applied. So
> > if
> > 15kg apples are sold, I would expect to see 11,25€/kg.
>
> The module formula are based by default on the sale price so the
> promotions are not cumulative. Non cumulative promotion is the most
> common practice as far as I have seen. But it is possible to add other
> base price for computation which may include previous promotions.
> Such case the formula would be written:
>
> current_price - (unit_price * 0.15)

Yes, I'm just learning (in my current project) how create business can be in
defining rebates - 160 different conditions.....

Cheers
Axel