# Discount on Sale

**URL:** <https://discuss.tryton.org/t/discount-on-sale/472>\
**Category:** Feature\
**Tags:** sales\
**Created:** [January 4, 2018, 7:33pm UTC](https://discuss.tryton.org/t/discount-on-sale/472 "2018-01-04T19:33:26Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![udono](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/udono/32/2114_2.png) [@udono](https://discuss.tryton.org/u/udono)\
**Post date:** [January 4, 2018, 7:33pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/1 "2018-01-04T19:33:26Z")

</div>

# Rational

For marketing reasons it should be possible to grant discounts to base prices  
and inform customers about the price reduction on sale.  
To have a fine-grained control what to discount or not, the feature is  
implemented on line level.  
The discount can be seen as a ratio between the unit price and the base price and as a difference discount amount between base price and unit price.  
Discount is calculated with these formulas:

```
                     unit price
a) discount = 1 - ------------
                     base price

b) unit price = base price * (1 - discount )

c) discount_amount = base price - unit price
                    = base price * discount

```

E.g.:

```
base price = 100
unit price = 90
discount = 0.1
discount amount = 10

```

The discount is represented in percentage and as an amount.  
It is possible to set a discount for sale lines without a product.

When calculating the discount from the unit price and vice versa,  
rational numbers are resulted, which needs to be rounded.

# Proposal

The feature is implemented in module:

```
sale_discount depends sale

```

The sale line gets the new fields discount and base\_price.

### Field base\_price

```
base_price = fields.numeric(
    'Base Price', digits=…, states={
        'readonly': Eval('product') | Eval('discount')})

```

The base price is filled at line creation time with 0.0.  
Without a given product the base price is editable by the user,  
but then it will be no longer editable, if there is a discount.

On change product the base\_price is re-evaluated by a method per default  
to the actual list\_price of the product.  
The base price can be influenced by functionalities provided by separate  
modules.  
Besides the product list price, the base price could be filled with a:

- price from a price list,
- price from a parent price list (when hierarchy is added),
- price from a catalog price

### Field discount

```
discount = fields.Function(
    fields.numeric('Discount', digits=…,
    getter='on_change_with_discount', setter='set_discount'))

```

Because the base price is constant for the same product and constant when  
there is a discount, the ratio between unit price and the discount value is  
always determined.  
It calculates:

```
* a new discount value by a change of the unit price by formula a)
* a new unit price by a change of the discount value by formula b)

```

### Field discount amount

```
discount_amount = fields.Function(
    fields.numeric('Discount Amount', digits=…,
    getter='on_change_with_discount', setter='set_discount'))

```

# Implementation

- [Manage discount on sale line (#9589) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue9589)

---

<div class="post-metadata">

**Author:** ![risto3](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/r/a87d85/32.png) [@risto3](https://discuss.tryton.org/u/risto3)\
**Post date:** [January 5, 2018, 6:49am UTC](https://discuss.tryton.org/t/discount-on-sale/472/2 "2018-01-05T06:49:06Z")

</div>

Yes, but also for purchases. Punctual discounting happens there too.

BTW, these discounts may be fractions, typically to round the discounted unit price.

Example: product list price 465.69  
discounted unit price = 442.00  
calculated discount = 5.087

I very much like the suggestion to be able to calculate either the discount derived from the discounted unit price as well as the latter applying the discount. This will save much time during entry/validation.

---

<div class="post-metadata">

**Author:** ![resteve](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/resteve/32/823_2.png) [@resteve](https://discuss.tryton.org/u/resteve)\
**Post date:** [January 5, 2018, 7:37am UTC](https://discuss.tryton.org/t/discount-on-sale/472/3 "2018-01-05T07:37:44Z")

</div>

Maybe you are interesting about discount modules that use gross unit price, discount and recalculate unit price:

- account\_invoice\_modules
- sale\_discount
- purchase\_discount

See

> **[Bitbucket](https://bitbucket.org/trytonspain/workspace/repositories/)**

Also there are other discount modules:

- sale\_discount\_price\_list
- sale\_pos\_discount
- account\_invoice\_3\_discount
- sale\_3\_discount
- …

See:

> **[Bitbucket](https://bitbucket.org/zikzakmedia/workspace/repositories/)**

> **[Bitbucket](https://bitbucket.org/nantic/workspace/repositories/)**

---

<div class="post-metadata">

**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\
**Post date:** [January 5, 2018, 10:49am UTC](https://discuss.tryton.org/t/discount-on-sale/472/4 "2018-01-05T10:49:20Z")

</div>

> [@udono](#):
>
> On sale and invoice it should be possible to grant a discount to the list
> 
> price of a product.

Discount is a marketing effect so there is no need to support it on invoice, this will just make the code more complex and cumbersome for supplier invoice and other customer invoice not subject to discount.

> [@udono](#):
>
> The discount is a ratio between the unit price and the product list price

For me, it is not that simple. The price to use as base price is not necessary the list price. I had already seen many different cases: the list price, the price from another price list, the price from a parent price list (when hierarchy is added), the price from a catalog price etc.

> [@udono](#):
>
> calculated withe these formulas

It should take care of the rounding issue. The computation should be stable.

> [@udono](#):
>
> Once an invoice or sale is done, the discount value needed to be freezed.

It should be filled when the line is created, just like the unit price is filled.

> [@udono](#):
>
> The product gets a new Boolean field with name “party discount”.  
> It indicates that the product can receive a default discount from the  
> invoices or sales party.

For me, this is a too simplistic design. Discount is normally limited in value. Indeed I think this is another feature which involve unit price tolerance. It probably needs to follow the `MatchMixin` pattern.

> [@udono](#):
>
> The party gets a new numeric field with name “discount”.  
> This “discount” is applied to sales or invoices of the party to lines  
> using a product which has “party discount” enabled.

I do not think it is the right approach. This should be managed by price list.

> [@risto3](#):
>
> Yes, but also for purchases. Punctual discounting happens there too.

I do not see the need to compute such discount. When purchasing, you do not want to follow into the marketing tricks of discount. The only thing that matter is the actual unit price.

> [@resteve](#):
>
> there are other discount modules

This shows that there are no standard method to do discount, so the proposal should find a good generic way which allow to easily implement any kind of method.

Also I think the proposal is missing the most important point. Discount should be seen by the customer so it should be displayed on the sale report.

---

<div class="post-metadata">

**Author:** ![risto3](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/r/a87d85/32.png) [@risto3](https://discuss.tryton.org/u/risto3)\
**Post date:** [January 5, 2018, 11:06am UTC](https://discuss.tryton.org/t/discount-on-sale/472/5 "2018-01-05T11:06:08Z")

</div>

> [@ced](#):
>
> I do not see the need to compute such discount. When purchasing, you do not want to follow into the marketing tricks of discount. The only thing that matter is the actual unit price.

I believe this is incoherent. The sale (or purchase) order should reflect the reality of the  
transaction as should necessarily the invoice too. Especially when these elements are apparent on the ‘official’ documents exchanged.

resteve: thanks, I take a look!

---

<div class="post-metadata">

**Author:** ![udono](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/udono/32/2114_2.png) [@udono](https://discuss.tryton.org/u/udono)\
**Post date:** [January 5, 2018, 11:29am UTC](https://discuss.tryton.org/t/discount-on-sale/472/6 "2018-01-05T11:29:46Z")

</div>

> [@risto3](#):
>
> I believe this is incoherent. The sale (or purchase) order should reflect the  
> reality of the transaction.

I think we are clear in this point:  
On sale you wanted to inform your customer that you give him a discount to  
make your offer more attractive in price.

The difference is here:  
If you purchase a product for a smaller price than your expected price it could  
have many reasons. Maybe your pricelist is not up to date, the supplier made  
an error or it is a real discount. Anyway in all cases the difference from  
your price expectation would be shown as a discount.  
So on purchase the proposed discount implementation provides misleading  
information and would need another conception, which is going beyond the scope  
of this proposal.  
For now you can just collect the effective unit price of any purchase and  
you have information about the price in the cost price diagram or stock moves.

> [@risto3](#):
>
> as should necessarily the invoice too.  
> Especially when these elements are apparent on the ‘official’ documents  
> exchanged.

Yes, but it can be also done in another way, without influencing the invoice  
calculations at all.  
When a sale creates an invoice, we can add a default information text per line about  
the given discount like “Including 10% black Friday discount”.

---

<div class="post-metadata">

**Author:** ![udono](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/udono/32/2114_2.png) [@udono](https://discuss.tryton.org/u/udono)\
**Post date:** [January 5, 2018, 1:59pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/7 "2018-01-05T13:59:04Z")

</div>

> [@ced](#):
>
> Discount is a marketing effect so there is no need to support it on invoice, this will just make the code more complex and cumbersome for supplier invoice and other customer invoice not subject to discount.

Added to proposal.

> [@ced](#):
>
> For me, it is not that simple. The price to use as base price is not necessary the list price. I had already seen many different cases: the list price, the price from another price list, the price from a parent price list (when hierarchy is added), the price from a catalog price etc.

Added to proposal.

> [@ced](#):
>
> It should take care of the rounding issue. The computation should be stable.

Here I am not sure what to do.  
The precision of the base price is at least depending on another external module.  
The precision of the unit price is depending on user preference.  
So we need to represent the discount with enough precision.

On the other hand does it not make much sense to have decimal  
places on a percentage.

For the customer the exact calculation is not so important when  
we show only the unit price and the discount.  
In this example

> [@risto3](#):
>
> Example: product list price 465.69  
> discounted unit price = 442.00  
> calculated discount = 5.087

we can represent the discount to the customer as 5%. The internal  
representation could be with 16 digits.

What do you think?

> [@ced](#):
>
> It should be filled when the line is created, just like the unit price is filled.

Added to proposal.

> [@ced](#):
>
> For me, this is a too simplistic design. Discount is normally limited in value. Indeed I think this is another feature which involve unit price tolerance. It probably needs to follow the MatchMixin pattern.

Removed all additional features from proposal.

---

<div class="post-metadata">

**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\
**Post date:** [January 5, 2018, 2:22pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/8 "2018-01-05T14:22:21Z")

</div>

> [@udono](#):
>
> What do you think?

Of course discount should be rounded, probably with 2 digits. But it is not the important part, the important part is when the computation is triggered between the three fields which one need to be updated and how. This process must always have the same result no matter the order in which the form is filled.

> [@udono](#):
>
> Field base\_price

I think this should be added in `sale` module because it will be also needed to implement the tolerance on the unit price.

> [@udono](#):
>
> The base price is filled at line creation time with 0.0.

I do not think it makes sense to fill with 0 when no information is provided.

> [@udono](#):
>
> Without a given product the base price is editable by the user.  
> But when there is a discount it is not editable, too.

I think it should never be editable by the user otherwise it will not be usable for tolerance.

---

<div class="post-metadata">

**Author:** ![risto3](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/r/a87d85/32.png) [@risto3](https://discuss.tryton.org/u/risto3)\
**Post date:** [January 6, 2018, 10:51am UTC](https://discuss.tryton.org/t/discount-on-sale/472/9 "2018-01-06T10:51:59Z")

</div>

> [@udono](#):
>
> For the customer the exact calculation is not so important when
> 
> we show only the unit price and the discount.
> 
> In this example
> 
> Example: product list price 465.69
> 
> discounted unit price = 442.00
> 
> calculated discount = 5.087
> 
> we can represent the discount to the customer as 5%. The internal  
> representation could be with 16 digits.
> 
> What do you think?

I guess I disagree. In fact, perhaps the sort of discount should be distinguished as to  
whether it is a percentage or a fixed amount. I believe that would resolve my issues.

To take my example, either 5.087% discount or a fixed discount of 23.69 would do.  
In fact, the example I took was exactly that, fixed, but I fit it into OpenERP percentage  
style discounts and what seemed to be your proposal basis.

In any event, I still strongly believe minimally a fractional discount is still necessary.

A similar resolve is needed for invoicing based upon advancement where  
such advancement is either in percentage terms or fixed (elaboration left to a new topic).

---

<div class="post-metadata">

**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\
**Post date:** [January 8, 2018, 4:35pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/10 "2018-01-08T16:35:50Z")

</div>

Good point. I guess it should be solved by having two ways to compute discount as percentage or as amount. I guess we could have a selection field on the line to define which one to use and probably the default value should be ‘amount’ as it is the one which is sure to provide always the right value. But as the way discount are done is probably a choice in the company (the way price list are configured), I think the default value should be configurable.

---

<div class="post-metadata">

**Author:** ![coogor](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/coogor/32/47_2.png) [@coogor](https://discuss.tryton.org/u/coogor)\
**Post date:** [January 11, 2018, 10:19pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/11 "2018-01-11T22:19:31Z")

</div>

> [@ced](#):
>
> > [@udono](#):
> >
> > On sale and invoice it should be possible to grant a discount to the list
> > 
> > price of a product.
> 
> Discount is a marketing effect so there is no need to support it on invoice, this will just make the code more complex and cumbersome for supplier invoice and other customer invoice not subject to discount.

Well, this statement does not really reflect business practice.  
Most customers want to see all discounts on the invoice, either on line item level, or on header level (Total per discount category)

We would need as well the option to send just a credit note for the rebates: First an invoice for the full amount, and secondly a credit note for the rebates (mostly needed in central payer scenarios)

---

<div class="post-metadata">

**Author:** ![udono](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/udono/32/2114_2.png) [@udono](https://discuss.tryton.org/u/udono)\
**Post date:** [January 12, 2018, 12:21pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/12 "2018-01-12T12:21:15Z")

</div>

> [@coogor](#):
>
> > [@ced](#):
> >
> > > [@udono](#):
> > >
> > > On sale and invoice it should be possible to grant a discount to the list  
> > > price of a product.
> > 
> > Discount is a marketing effect so there is no need to support it on invoice, this will just make the code more complex and cumbersome for supplier invoice and other customer invoice not subject to discount.
> 
> Well, this statement does not really reflect business practice.  
> Most customers want to see all discounts on the invoice, either on  
> line item level, or on header level (Total per discount category)

This all should be possible and a manageable by add-on modules,  
based on this feature, but not in the scoop of this feature.

> [@coogor](#):
>
> We would need as well the option to send just a credit note for the rebates: First an invoice for the full amount, and secondly a credit note for the rebates (mostly needed in central payer scenarios)

Sounds interesting to me, but _your_ feature is IMHO a complete different story, which is not scoop of _my_ feature, too.

---

<div class="post-metadata">

**Author:** ![coogor](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/coogor/32/47_2.png) [@coogor](https://discuss.tryton.org/u/coogor)\
**Post date:** [January 27, 2018, 1:39pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/13 "2018-01-27T13:39:23Z")

</div>

> [@udono](#):
>
> > [@](#):
> >
> > We would need as well the option to send just a credit note for the rebates: First an invoice for the full amount, and secondly a credit note for the rebates (mostly needed in central payer scenarios)
> 
> Sounds interesting to me, but your feature is IMHO a complete different story, which is not scoop of my feature, too.

Just wanted to mention a market requirement in that context…

---

<div class="post-metadata">

**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\
**Post date:** [February 6, 2018, 1:40pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/14 "2018-02-06T13:40:29Z")

</div>

> [@ced](#):
>
> Good point. I guess it should be solved by having two ways to compute discount as percentage or as amount. I guess we could have a selection field on the line to define which one to use and probably the default value should be ‘amount’ as it is the one which is sure to provide always the right value. But as the way discount are done is probably a choice in the company (the way price list are configured), I think the default value should be configurable.

Why not including both fields as functional ones? As the percentage depends on the discount amount and the unit\_price I don’t think it will be hard to compute it.

---

<div class="post-metadata">

**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\
**Post date:** [February 6, 2018, 2:22pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/15 "2018-02-06T14:22:08Z")

</div>

Because the user will want to decide which version to promote to the customer.  
Also percentage may not always result a rational number which can not be defined without rounding issue in decimal.

---

<div class="post-metadata">

**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\
**Post date:** [February 27, 2018, 12:36pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/16 "2018-02-27T12:36:48Z")

</div>

> [@ced](#):
>
> Because the user will want to decide which version to promote to the customer.
> 
> Also percentage may not always result a rational number which can not be defined without rounding issue in decimal.

I think the best option is to store the base\_unit\_price from product and then let the user decide what needs to be shown on the report. If we have the base\_unit\_price and the unit\_price we can compute all the required information: Discount Amount and Discount Percentage with formulas.

---

<div class="post-metadata">

**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\
**Post date:** [February 27, 2018, 12:41pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/17 "2018-02-27T12:41:03Z")

</div>

I do not think it is viable to request the user to choose the format on each line.  
I think we must find a solution which determine which format to use automatically.

---

<div class="post-metadata">

**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\
**Post date:** [February 27, 2018, 1:04pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/18 "2018-02-27T13:04:36Z")

</div>

> [@ced](#):
>
> I do not think it is viable to request the user to choose the format on each line.
> 
> I think we must find a solution which determine which format to use automatically.

Probably it makes sense to include a configuration value on sale level, with a default value on the sale configuration like we do for the invoice/shipment method.

---

<div class="post-metadata">

**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\
**Post date:** [February 27, 2018, 1:10pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/19 "2018-02-27T13:10:46Z")

</div>

I do not think a configuration is the right answer because the discount depend on how the price is computed and this computation can be based on different formula per products. Some will have a nice percentage result, others not. That’s why I think this should be done with a smart algorithm which decide which method to use.

---

<div class="post-metadata">

**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\
**Post date:** [February 27, 2018, 11:21pm UTC](https://discuss.tryton.org/t/discount-on-sale/472/20 "2018-02-27T23:21:48Z")

</div>

Maybe such algorithm could be:

- compute the percentage
- if the percentage is a multiple of 5%, then display it
- otherwise compute and display the amount

The value 5% could be a parameter.

[Next page](https://discuss.tryton.org/t/discount-on-sale/472.md?page=2)