Discount per family and per amount of products in a month

[Gonzalo]

First, sorry for my english.

The problem is complex, I will try to explain it the best I can.
We are trying to use Tryton + GNU Health for a clinic. The clinic has a kind of subscription/insurance where you paid an amount per month and you get an amount of services to use (for example, 3 medical consultation free...).
So should be able to know the amount of this products/services uses by a person in the last month, and the price will depend on this.

To make things more complicated, the subscription can be per family too, i.e., if your son uses the total of medical consultation that you had free, you will have to pay.

I tried to use price_list but I don't understand how it works. Anyway, I think you can’t consider the historic with that.

Thanks for your time

[Sergi Almacellas Abellana]

El 24/10/17 a les 17:29, Gonzalo ha escrit:

> First, sorry for my english.
>
> The problem is complex, I will try to explain it the best I can.
> We are trying to use Tryton + GNU Health for a clinic. The clinic has a kind of subscription/insurance where you paid an amount per month and you get an amount of services to use (for example, 3 medical consultation free...).

The sale_subscription [1] module can be used to generate a montlhy
invoice for invoicing the insurance.

> So should be able to know the amount of this products/services uses by a person in the last month, and the price will depend on this. >

The sale_promotion [2] module can be used to generate a promotion on the
sales. One option is to generate a promotion code on each subscription
consumption. Subscription codes can be filled by on_change when setting
the party.

> To make things more complicated, the subscription can be per family too, i.e., if your son uses the total of medical consultation that you had free, you will have to pay.
>

That will be a fact of only selecting the promotion, when used by one of
the members of the familty.

Hope it helps.

[1] http://doc.tryton.org/4.4/modules/sale_subscription/doc/index.html
[2] http://doc.tryton.org/4.4/modules/sale_promotion/doc/index.html


--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Cédric Krier]

No price list is really not the right solution.

I think you should automatically append to the invoices deduction line
with negative line for each product that is eligible for the deduction.

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

[Cédric Krier]

On 2017-10-25 10:30, Sergi Almacellas Abellana wrote:
> El 24/10/17 a les 17:29, Gonzalo ha escrit:

> > So should be able to know the amount of this products/services uses by a person in the last month, and the price will depend on this. >
> The sale_promotion [2] module can be used to generate a promotion on the
> sales. One option is to generate a promotion code on each subscription
> consumption. Subscription codes can be filled by on_change when setting
> the party.

Promotion will not ensure that it applies only for the quantity per
month of each products.

> > To make things more complicated, the subscription can be per family too, i.e., if your son uses the total of medical consultation that you had free, you will have to pay.
> >
> That will be a fact of only selecting the promotion, when used by one of
> the members of the familty.

Indeed I think the subscription should be linked to the sale and invoice
to know what to apply.

[Richard PALO]

Le 25/10/2017 à 10:43, Cédric Krier a écrit :
> On 2017-10-24 08:29, Gonzalo wrote:
>> The problem is complex, I will try to explain it the best I can.
>> We are trying to use Tryton + GNU Health for a clinic. The clinic has
>> a kind of subscription/insurance where you paid an amount per month
>> and you get an amount of services to use (for example, 3 medical
>> consultation free...).
>> So should be able to know the amount of this products/services uses by
>> a person in the last month, and the price will depend on this.
>>
>> To make things more complicated, the subscription can be per family
>> too, i.e., if your son uses the total of medical consultation that you
>> had free, you will have to pay.
>>
>> I tried to use price_list but I don't understand how it works. Anyway,
>> I think you can’t consider the historic with that.
>
> No price list is really not the right solution.
>
> I think you should automatically append to the invoices deduction line
> with negative line for each product that is eligible for the deduction.
>

I believe there should be some additional things to consider, typically for suppliers
where instead of communicating net prices to their [professional] clients, there are:
1. Fixed reductions : typically by category of product. (e.g. public price - 50%)
2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%)
3. There may be as well volume discounts (in absence of a different article reference number)
4. I understand there may be fixed price reductions too (that is, not a percentage) in the
currency used, e.g. 1€ (or 1£ or 1€) or what have you...

In these cases, the public list price is communicated when updated, as are the
reduction coefficients, according to what is negotiated.

There is, therefore, an impact on the price list... Naturally a broker may have this
on both supplier and client price lists. It seems that currently the pricing and price list
schemas don't deal with these common practices.

cheers,
--

Richard PALO

[Cédric Krier]

On 2017-10-25 13:47, Richard PALO wrote:
> I believe there should be some additional things to consider, typically for suppliers
> where instead of communicating net prices to their [professional] clients, there are:

We don't try to compute instead of the supplier because you do not know
how they compute and any way, it is not needed. The current supplier
price list per quantity is good enough for approximation.

> 1. Fixed reductions : typically by category of product. (e.g. public price - 50%)

Supported by sale_promotion

> 2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%)

Supported by price list

> 3. There may be as well volume discounts (in absence of a different article reference number)

Supported by sale_promotion

> 4. I understand there may be fixed price reductions too (that is, not a percentage) in the
> currency used, e.g. 1€ (or 1£ or 1€) or what have you...

Also supported by price list and sale_promotion even if it is highly
doubtable because of the currency.

[Richard PALO]

Le 25/10/2017 à 13:57, Cédric Krier a écrit :
> On 2017-10-25 13:47, Richard PALO wrote:
>> I believe there should be some additional things to consider, typically for suppliers
>> where instead of communicating net prices to their [professional] clients, there are:
>
> We don't try to compute instead of the supplier because you do not know
> how they compute and any way, it is not needed. The current supplier
> price list per quantity is good enough for approximation.
>

I don't understand what you say here.

>> 1. Fixed reductions : typically by category of product. (e.g. public price - 50%)
>
> Supported by sale_promotion
>

This is not the same, promotion is only a punctual reduction, either global or by specific
line on the invoice... it is not 'permanent' like the habitual price list conditions are.

>> 2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%)
>
> Supported by price list
>

I see the formula possibility with hard coded coefficients, but I can't seem to get the price
list to work at all on suppliers anyway... it simply igores it and uses only the price_unit
value on the suppliers form of the product. (though I wonder if the patches for issue3797 may
cause any problem here?)

>> 3. There may be as well volume discounts (in absence of a different article reference number)
>
> Supported by sale_promotion
>

again, not the same as with 1.

>> 4. I understand there may be fixed price reductions too (that is, not a percentage) in the
>> currency used, e.g. 1€ (or 1£ or 1€) or what have you...
>
> Also supported by price list and sale_promotion even if it is highly
> doubtable because of the currency.
>

same as 2.

By the way, I tried the standard approach... Purchase order -> reception -> Invoice
and directly with invoice (which loses the supplier specifics from issue3797), but neither
seem to understand the supplier price list as configued on the supplier price list as it seems
to be only for 'sales' and not 'purchases'.

It is primordial to support these on price lists for suppliers as it is unacceptable
to force entering line by line standard supplier conditions on articles purchased.
There may be hundreds or thousands of lines per month to enter! The forms are already
way too verbose for any real-life volume.

--

Richard PALO

[Richard PALO]

I believe as well that supplier purchase categories could or
should probably relate to purchase.product_supplier as opposed to
being dumped on product.template

cheers
--

Richard PALO

[Cédric Krier]

On 2017-10-26 07:19, Richard PALO wrote:
> Le 25/10/2017 à 13:57, Cédric Krier a écrit :
> > On 2017-10-25 13:47, Richard PALO wrote:
> >> I believe there should be some additional things to consider, typically for suppliers
> >> where instead of communicating net prices to their [professional] clients, there are:
> >
> > We don't try to compute instead of the supplier because you do not know
> > how they compute and any way, it is not needed. The current supplier
> > price list per quantity is good enough for approximation.
> >
>
> I don't understand what you say here.

You can not compute in place of the supplier because you will compute
wrong. Also supplier will mostly never tell you what computation they
do.

> >> 1. Fixed reductions : typically by category of product. (e.g. public price - 50%)
> >
> > Supported by sale_promotion
> >
> This is not the same, promotion is only a punctual reduction, either global or by specific
> line on the invoice... it is not 'permanent' like the habitual price list conditions are.

No sale promotion are not necessary limited in time. The start/end date
are optional.

> >> 2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%)
> >
> > Supported by price list
> >
> I see the formula possibility with hard coded coefficients, but I can't seem to get the price
> list to work at all on suppliers anyway... it simply igores it and uses only the price_unit
> value on the suppliers form of the product.

No price list are not for supplier on purpose.

> (though I wonder if the patches for issue3797 may cause any problem
> here?)

Already manage: https://codereview.tryton.org/40731002/diff/60001/purchase.py#newcode1139

> By the way, I tried the standard approach... Purchase order -> reception -> Invoice
> and directly with invoice (which loses the supplier specifics from issue3797), but neither
> seem to understand the supplier price list as configued on the supplier price list as it seems
> to be only for 'sales' and not 'purchases'.

Now if you really want it you can create a custom module
purchase_price_list, it will be very easy to implement.

> It is primordial to support these on price lists for suppliers as it is unacceptable
> to force entering line by line standard supplier conditions on articles purchased.
>
> There may be hundreds or thousands of lines per month to enter! The forms are already
> way too verbose for any real-life volume.

So do not fill it. You do not need to have the supplier price, it is
there for information.

[Richard PALO]

Le 26/10/2017 à 10:09, Cédric Krier a écrit :
> On 2017-10-26 07:19, Richard PALO wrote:
>> Le 25/10/2017 à 13:57, Cédric Krier a écrit :
>>> On 2017-10-25 13:47, Richard PALO wrote:
>>>> I believe there should be some additional things to consider, typically for suppliers
>>>> where instead of communicating net prices to their [professional] clients, there are:
>>>
>>> We don't try to compute instead of the supplier because you do not know
>>> how they compute and any way, it is not needed. The current supplier
>>> price list per quantity is good enough for approximation.
>>>
>>
>> I don't understand what you say here.
>
> You can not compute in place of the supplier because you will compute
> wrong. Also supplier will mostly never tell you what computation they
> do.
>

Well, I guess we disagree on this point. A 'sale' is an *agreement* on the 'price' of *the* 'article'.
Frequently the supplier agreement is based on such a formula as mentioned prior.

>>>> 1. Fixed reductions : typically by category of product. (e.g. public price - 50%)
>>>
>>> Supported by sale_promotion
>>>
>> This is not the same, promotion is only a punctual reduction, either global or by specific
>> line on the invoice... it is not 'permanent' like the habitual price list conditions are.
>
> No sale promotion are not necessary limited in time. The start/end date
> are optional.
>

What I meant is that a sale 'promotion' is over and above the habitual supplier agreement,
and that the existing invoice reduction scheme seems to handle this okay.

>>>> 2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%)
>>>
>>> Supported by price list
>>>
>> I see the formula possibility with hard coded coefficients, but I can't seem to get the price
>> list to work at all on suppliers anyway... it simply igores it and uses only the price_unit
>> value on the suppliers form of the product.
>
> No price list are not for supplier on purpose.
>
>> (though I wonder if the patches for issue3797 may cause any problem
>> here?)
>
> Already manage: https://codereview.tryton.org/40731002/diff/60001/purchase.py#newcode1139
>
>> By the way, I tried the standard approach... Purchase order -> reception -> Invoice
>> and directly with invoice (which loses the supplier specifics from issue3797), but neither
>> seem to understand the supplier price list as configued on the supplier price list as it seems
>> to be only for 'sales' and not 'purchases'.
>
> Now if you really want it you can create a custom module
> purchase_price_list, it will be very easy to implement.
>

Ah, this is indeed the issue I encounter I guess :-(
Will need to do this asap!

>> It is primordial to support these on price lists for suppliers as it is unacceptable
>> to force entering line by line standard supplier conditions on articles purchased.
>>
>> There may be hundreds or thousands of lines per month to enter! The forms are already
>> way too verbose for any real-life volume.
>
> So do not fill it. You do not need to have the supplier price, it is
> there for information.
>

?? I thought that stock receptions used the order prices (not the invoiced price) for stock
valuation on the stock move. Has this changed, or do I misunderstand the workflow?
That is, it is frequent here to have invoices based upon [one or more] deliveries.


--

Richard PALO

[Cédric Krier]

On 2017-10-27 22:27, Richard PALO wrote:
> > So do not fill it. You do not need to have the supplier price, it is
> > there for information.
> >
>
> ?? I thought that stock receptions used the order prices (not the invoiced price) for stock
> valuation on the stock move. Has this changed, or do I misunderstand the workflow?
> That is, it is frequent here to have invoices based upon [one or more] deliveries.

You should know the price of the product when you validated the
quotation and at worst when you receive the goods so you can update the
price on the move.

[Richard PALO]

Le 28/10/2017 à 01:12, Cédric Krier a écrit :
> On 2017-10-27 22:27, Richard PALO wrote:
>>> So do not fill it. You do not need to have the supplier price, it is
>>> there for information.
>>>
>>
>> ?? I thought that stock receptions used the order prices (not the invoiced price) for stock
>> valuation on the stock move. Has this changed, or do I misunderstand the workflow?
>> That is, it is frequent here to have invoices based upon [one or more] deliveries.
>
> You should know the price of the product when you validated the
> quotation and at worst when you receive the goods so you can update the
> price on the move.
>

Indeed, that is my point.

With respect to promotions, sale_promotion is only for sales and not purchases.
It seems that it should be neutral, but I imagine you suggest in this case that
a purchase_promotion module be devised....
--

Richard PALO

[Cédric Krier]

If you want but I do not think it is a generic feature because as I said
most of companies will never encode all the rules of suppliers supposed
that they know it. At best they will have a spreadsheet with the price
list (and some will be per quantity) which can be uploaded as product
supplier price.
But the common behaviour is to just adapt the price from the received
quotation. This workflow will be improved by the
new purchase_request_quotation: https://bugs.tryton.org/issue6175
And even I'm wondering if the unit_price should not be editable on more
state than draft and not required before confirmed.

[Richard PALO]

It is a good idea to analyse the use cases.

I personally believe there are many who value 'verification' and
'update when needing correction' as opposed to manual data entry
with greater risks.

The latter also greatly complicates control of *unusual* price variations which
necessitate rectification by the supplier.

Nobody is exempt of errors, but the general rule is to reduce their heads popping up
and certainly catch them when they do... not to mention avoiding any increase in the
PO => Reception => Invoice entry/validation time.

That is, there are companies that may already be on the critical path time-wise to
get their monthly VAT reports ready... They don't necessarily have the budget to double
their staffing in order to do so.

As for quotations, those are prior to selecting the products from a specific supplier
for confirmation ... there is no guarantee that a supplier will offer special pricing
on all items (which is frequently only on certain non "consumable" articles).
(RFQs may [in some cases] be machine generated and comprehensive)
RFQ's never send the habitual price with the request to the supplier... it remains
extremely useful to have 'a' price present in the draft order preparation to evaluate
the price quotation received (sometimes the special price negotiation is just beginning!).

cheers,

--

Richard PALO