Actually maturity dates on invoices are computed using payment term and based on invoice date. But we have customers who want to compute it based on shipment date. This is normally the case when the invoice is delayed a lot with respect shipment.
I’ve been reviewing code and it will not be difficult to add a custom module to implement it, but imho it could be interesting to add on core.
In case multiple shipments grouped in a invoice what is considered shipment date?
So IIUC you are proposing to adding a select box to allow the user to choose the date used for computing the deltas. By default this checkbox will only have the invoice date but when the account_inovice_stock module is activated it will have an extra option to use the shipment date.
I do not see the point. If you base the invoicing on the shipment than it means that you create the invoice at the time the shipment is done so the invoice date will be the same as the shipment date.
As you can confirm the reception of the invoice only when the customer confirm it. You just have to post the invoice at this confirmation. This way the invoice date correspond to the reception date.
But in some cases it could happen that the invoice date can not be set in the past if other invoices have been posted with a date after. So it may be useful to have an optional field payment_term_date which is used to compute the terms if filled instead of the invoice date. But we should probably have a warning in case this date creates a term in the past.
The examples is about a supplier invoice. In this case we cannot define a invoice date different of the given by supplier.
Some kind of configuration in payment term will be interesting as described @pokoli to set “payment_term_date” when creating an invoice. In this way users can define terms “30d after invoice date” or “30d after shipment date” on parties.
I do not agree because it makes no sense. The invoice can only rely on itself to compute the terms. “After shipment date” means nothing for an invoice.
There should be a mechanism to propose users the “payment_term_date”. IMHO The feature is incomplete if the have to input date manually on each invoice of a Party with this kind of negotiated payment term.
This is something you should tell us. How is this negotiated in your case? For each customer (independently of the payment term used) or depening on the payment term?
It is depending on payment term. For this reason I mentioned examples such as “30d after invoice date” or “30d after shipment date” (theses are descriptive names for payment terms).
But what happens if a customer uses a shorter payment term for a specific sale? Which date should be used? The invoice or the shipment?
I mean if you agree to always use the shipment date no mather the payment term it should be something defined on the party but if you agree to use a diferent date depending on the term it should be defined on the payment term.
For me there is an issue in the division of responsibility. The payment term can not be responsible of the starting date of its computation because it does not have any link to other document. And more over invoices are not always related to any shipment.
So for me it will be good to have in standard a payment_term_date on invoice which override the default starting date. This will also solve a common issue for supplier invoice which is that companies do not always now how the term is computed and so this will allow to just fill the term date (without any payment term).
By default in standard the payment_term_date is empty but it is easily to customize the purchase or sale to fill it with whatever people want.
But nothing more should be added in standard.