Issue 9855

Title
Set invoice method and payment term from last purchases
Priority
feature
Status
resolved
Nosy list
albertca, ced, resteve, reviewbot, roundup-bot
Assigned to
ced
Keywords
review

Created on 2020-11-20.17:20:46 by ced, last changed 4 weeks ago by roundup-bot.

Messages

New changeset aa4a9dbdc9fe by Cédric Krier in branch 'default':
Set payment term and invoice method from last party's purchases
https://hg.tryton.org/tryton-env/rev/aa4a9dbdc9fe
New changeset c406a025d2b5 by Cédric Krier in branch 'default':
Add default customer payment term configuration
https://hg.tryton.org/modules/sale/rev/c406a025d2b5
New changeset b1f2a922a249 by Cédric Krier in branch 'default':
Set payment term and invoice method from last party's purchases
https://hg.tryton.org/modules/purchase/rev/b1f2a922a249
New changeset da277943635d by Cédric Krier in branch 'default':
Add default customer payment term configuration
https://hg.tryton.org/modules/account_invoice/rev/da277943635d
Author: [hidden] (resteve)
Date: 2020-11-23.09:33:40

Hie,

you could do a default payment term in purchase/sale (global configuration) [1] but it's wrong design force payment term from last purchase/sale when a customer/supplier has a default payment term [2]

In case you like force payment term from last purchase, please, do this NEW feature about configuration: the company decide to configure in case like purchase term from last purchase or a default supplier payment term.

[1] https://codereview.tryton.org/318881002/patch/329041002/322661011
[2] https://codereview.tryton.org/318881002/patch/329041002/322661010

My 2ct.

Author: [hidden] (albertca) Tryton committer
Date: 2020-11-22.16:52:20
Missatge de Cédric Krier <cedric.krier@b2ck.com> del dia dv., 20 de nov.
2020 a les 17:55:

> On 2020-11-20 17:31, Albert Cervera i Areny wrote:
> > > Just like we set the currency using the last purchases from the same
> > > supplier, we should also set the invoice method and payment term.
> > >
> >
> > What is the rationale behind this?
>
> The same that was already discussed many times.
>
> > Most companies negotiate the payment conditions with the supplier once so
>
> This is wrong. Most of companies are SME and they never negotiate
> because they are too small.
>

SME is a very large range of company sizes (typically from 10 to 249
employees may be considered SME).

What I understand as "negotiation" does not necessarily mean signing a
contract (as I understand you suggest in the last comment) but at least a
verbal agreement on what the conditions will be. In other cases, the
agreement can be a simple document with the established conditions,
probably not worth introducing in the system as a complete contract.

>
> > the purchase person does not have to remember this setting.
>
> No change here.
>
> > In many cases
> > that negotiation may happen before a real purchase is even created in the
> > system.
>
> This is a special case.
>

I disagree but I can understand your position.

> Also, missing this parameter will make migration from previous systems
> > worse because there will be no place to store that existing information.
>
> Why should we care about other systems design.
>

I'm not talking about other system's design.

Imagine the company has been using software X for 10 years and that
software behaves just like what you want to implement now in Tryton: no
config in party form and suggest payment term based on history.

In that situation, when the company starts using Tryton, Tryton will not
suggest the right payment term because typically history of purchases is
not migrated (at least that's what we usually do at NaN-tic).

So for me, your suggested behaviour could be made compatible with existing
behaviour by leaving the default supplier payment term in the party form
and when that is empty compute the suggested payment term based on past
purchases.

I must say that this is what worries me most about your proposed change.

> > Accountants should not believe the information of supplier invoice "as
> is"
> > and should have a mechanism to ensure that information is correct.
>
> Correct against what? There is only one source of truth, it is the
> invoice.
>

I see you suggest using a future contract module. The general idea sounds
good to me but I'm afraid that the suggested design, which is
document-based is too complex for what is needed in many cases.

Having a stripped down version, which basically includes a number, an
optional name and the designed payment term may make sense to me.

For example, that contract could be a m2o in purchase.purchase and could be
filled-in automatically when the party is selected, and there's only one
available agreement/contract for the party.

> > Filling-in automatically the payment term from the party information
> > provides this mechanism.
>
> No because as already discussed before many times. Users do not change
> the default configuration on the party when needed.
>

I agree this is a problem with some users.

> Also this is a false statement that it provides any correctness
> mechanism because a default value is not an agreement. The agreement was
> done on the purchase which will set the value.
> Also any of that provides any validation mechanism. A default value is
> never a validation.
>

In fact, one of the problems of the existing design is that when the user
creates the purchase he can put payment term "X", but then the invoice is
introduced based on the default value *or* the supplier invoice (which is
what you suggest). In either case, we're not checking against the purchase.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2020-11-22.15:13:50

Also I think that verify the purchase/invoice parameters against a supplier contract, should be part of the contract management topic. This will be way better than a simple field on the party.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2020-11-20.17:57:03
On 2020-11-20 17:31, Albert Cervera i Areny wrote:
> > Just like we set the currency using the last purchases from the same
> > supplier, we should also set the invoice method and payment term.
> >
> 
> What is the rationale behind this?

The same that was already discussed many times.

> Most companies negotiate the payment conditions with the supplier once so

This is wrong. Most of companies are SME and they never negotiate
because they are too small.

> the purchase person does not have to remember this setting.

No change here.

> In many cases
> that negotiation may happen before a real purchase is even created in the
> system.

This is a special case.

> Also, missing this parameter will make migration from previous systems
> worse because there will be no place to store that existing information.

Why should we care about other systems design.

> Accountants should not believe the information of supplier invoice "as is"
> and should have a mechanism to ensure that information is correct.

Correct against what? There is only one source of truth, it is the
invoice.

> Filling-in automatically the payment term from the party information
> provides this mechanism.

No because as already discussed before many times. Users do not change
the default configuration on the party when needed.
Also this is a false statement that it provides any correctness
mechanism because a default value is not an agreement. The agreement was
done on the purchase which will set the value.
Also any of that provides any validation mechanism. A default value is
never a validation.

PS: Please do not answer directly to my email when commenting issue. Thanks.
Author: [hidden] (albertca) Tryton committer
Date: 2020-11-20.17:32:01
Missatge de Cédric Krier <bugs@tryton.org> del dia dv., 20 de nov. 2020 a
les 17:20:

>
> New submission from Cédric Krier <cedric.krier@b2ck.com>:
>
> Just like we set the currency using the last purchases from the same
> supplier, we should also set the invoice method and payment term.
>

What is the rationale behind this?

Most companies negotiate the payment conditions with the supplier once so
the purchase person does not have to remember this setting. In many cases
that negotiation may happen before a real purchase is even created in the
system.

Also, missing this parameter will make migration from previous systems
worse because there will be no place to store that existing information.

> So this leads to the suppression of the `supplier_payment_term` on party
> as it will no more be useful but I do not think we should implement the
> same behavior on supplier invoice because when they are created this way,
> the accountant has the invoice.
>

For me, the same way we check that the invoice against the purchases/stock
moves we already introduced in the system, the accountant must also check
that the payment term in the supplier invoice is correct compared to the
information in Tryton.

Accountants should not believe the information of supplier invoice "as is"
and should have a mechanism to ensure that information is correct.
Filling-in automatically the payment term from the party information
provides this mechanism.

> With such removal, the default of payment term (when unique) has no more
> sense. Instead we should have a default configuration for the customer
> payment term.
>
> ----------
> assignedto: ced
> component: account_invoice, purchase, sale
> messages: 62065
> nosy: ced
> priority: feature
> status: in-progress
> title: Set invoice method and payment term from last purchases
> type: feature request
>
> ______________________________________
> Tryton issue tracker <bugs@tryton.org>
> <https://bugs.tryton.org/issue9855>
> ______________________________________
>

-- 

<https://www.nan-tic.com>

Albert Cervera

Tel. (+34) 935 531 803

<https://www.nan-tic.com/en/news/>  <http://twitter.com/nan_tic>
<https://www.linkedin.com/company/nan-tic/>

Pot consultar la informació sobre el tractament que realitzem de les dades
de caràcter personal de conformitat amb l’article 11 LOPD aquí
<https://www.nan-tic.com/lopd>.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2020-11-20.17:20:46

Just like we set the currency using the last purchases from the same supplier, we should also set the invoice method and payment term.
So this leads to the suppression of the supplier_payment_term on party as it will no more be useful but I do not think we should implement the same behavior on supplier invoice because when they are created this way, the accountant has the invoice.
With such removal, the default of payment term (when unique) has no more sense. Instead we should have a default configuration for the customer payment term.

History
Date User Action Args
2020-12-23 21:48:35roundup-botsetmessages: + msg63597
2020-12-23 21:48:28roundup-botsetmessages: + msg63596
2020-12-23 21:48:21roundup-botsetmessages: + msg63595
2020-12-23 21:48:18roundup-botsetmessages: + msg63594
nosy: + roundup-bot
status: testing -> resolved
2020-11-23 09:33:40restevesetmessages: + msg62109
nosy: + resteve
2020-11-22 18:47:17reviewbotsetmessages: + msg62108
2020-11-22 16:52:20albertcasetmessages: + msg62107
2020-11-22 15:13:50cedsetmessages: + msg62106
2020-11-20 17:57:03cedsetmessages: + msg62068
2020-11-20 17:48:10reviewbotsetmessages: + msg62067
nosy: + reviewbot

Showing 10 items. Show all history (warning: this could be VERY long)