Customizable defaults on payment terms

accounting

(albert) #1

Rational

Currently tryton allows users to define the default payment term for invoices (or purchases or sales) at the party form.

That default value used to be a couple of fields of type Property but in latest versions that was converted to MultiValue fields.

The information of the party’s customer_payment_term and supplier_payment_term fields is stored in account.invoice.payment_term and the model has the fields:

  • party
  • company
  • customer_payment_term
  • supplier_payment term

The thing is that we’d like to be able to customize the way the payment term is choosen based on some other criteria (a “type” field on invoices, for example -could also be the journal), but which would only apply to customer invoices.

Proposal

The idea would be to change account.invoice.payment_term so that it only has the following fields:

  • party
  • company
  • kind
  • payment_term

Kind could be a selection with the following options:

  • Empty (affects both customer and supplier invoices)
  • Customer Invoice
  • Customer Credit Note
  • Supplier Invoice
  • Supplier Credit Note

To clarify, in our experience usually the company wants Customer Credit Notes to have a different payment term than the invoice.

This design would allow us to add a new field (invoice_type, or journal) to be applied to lines of kind “Customer Invoice” and thus provide defaults in other circumstances.

Opinions?


(Cédric Krier) #2

I think it is a complex design for very few benefit.
I think the major problem is to set a payment term for the credit note. It seems logical to consider that they are due directly by default. And as credit note are created manually, it is still possible to select a payment term for it.
Also recently we allowed to edit the maturity date because often for supplier document we can not compute the same result.


(albert) #3

To be honest, our idea is to extend the model with information regarding payment type and bank account to be used too.

This way we have a good mechanism to define each type of invoice which values to use for those three fields.

But we can also manage with another field if using it in core provide no benefit.

The discussion regarding payment type should probably be part of another thread…


(Cédric Krier) #4

I do not see the link between those fields. But to be honest, I never understood the need of payment type nor bank on an invoice. Customer are free to pay by the mean they want.


(albert) #5

By the way, we also created the account_Invoice_maturity_dates module which allows the user to change the maturity dates of an invoices using a wizard from within the invoice, which proved very handy for many users. Specially the possibility (configurable) of showing the wizard when the “Post” button is clicked.


(Cédric Krier) #6

It does not need a wizard for that. A One2Many on the lines to pay with the amount and the maturity date should be enough.


(albert) #7

Reviewing the places where payment term can be introduced I find it a bit inconsistent that the user can change the payment term on a per Sale (or Sale Subscription or Purchase) basis but cannot change it at the Project, as the module project_invoice relies on the default payment term of the customer.

Would be adding payment_term to project_invoice be an acceptable patch?


(Sergi Almacellas Abellana) #8

I agree that customer is free to pay by the mean they want but it’s also common to reach an agreement with the customer on how they will pay your invoices. The main benefit about payment types is to have more specific information about if you have to process the payment or the customer will process it. Let me explain:

  • When the agreement is to pay by Wire Transfer, the customer is the one which will initiate the payment.
  • When the payment is by SEPA or Stripe, you have to process the lines to pay and generate upload the XML file to the bank.

This is similar to the supplier has direct debit feature but also for customer payments.

Although it is possible to distinguish which customers you have mandate (an thus you have to process it’s payments) we may want to support the following case:

  • Recurring payments are due with a SEPA XML
  • Other invoices of same customer are paid by wire transfer

So in order to manage this case you have to agree on invoice level which payment type you should use and it will be good to indicate that it requires a mandate.

Probably the payment method will have a very close relation with the new payment method. Or maybe both objects represent the same concept.

Having said that I think that we should not include the bank account on the invoice also as most of the times the bank account will be a property of the Payment Type.


(Sergi Almacellas Abellana) #9

Then we should consider adding also the invoice address as currently the default one is also used.


(Cédric Krier) #10

I still do not see why the invoice should have any information about the way it will be paid.
I do not see neither why a company will not do SEPA direct debit if it has the mandate.

I do not agree. This feature is similar to the SEPA mandate.

Not at all. The payment method is to record the existing not to request.


(Jose Salvador) #11

Totally agree.

I see the relationship too.

It’s a pity we can not reuse payment method as additional info at purchase, sale and invoices to represent the intention/agreement to accomplish payments.


(Sergi Almacellas Abellana) #12

For example if you expect the customer to pay the invoice by wire-transfer it’s easier to include it on the invoice so it easier to find and the payment will be faster.

We are currently using the payment_term description to indicate this information but it forces us to duplicate the same description in diferent payment terms which is complex to maintain.


(Cédric Krier) #13

Why? You still check all your payment means frequently and fill statement for them.
For me, this is a practice that has no rational today. It could have some back in the days where banking was not electronic and moving funds was very slow and complex. Today, it is no more the case.


(Jose Salvador) #14

For me it’s all about info.

I would like to know if an invoice will be paid through SEPA, wire-transfer, “cheque/talón” (I’m not sure if those spanish words/concepts have an english translation… may be bank check??).

Surely, I don’t know any accountant in spain that does not want to have the payment type, moreover, there are payment types as “bank checks” that have additional information as a unique identifier number that accountants used to want to note it, too, same for wire-transfer, the customer expects to see the bank account number on do the payment to.