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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
This is not what it does. It is not because you request to be paid with one method that the customer will be using it. He is free to pay the company by any mean he wants.
Accountant does not care about that. It is the business management that care about cash flow and where the money is.
Because as I said, the accountant needs any way to check all the payment means.
You can put them on the invoice report without the need of any additional information.