Probably but this is something that is still used because of long lasting comercial relations.
This sound reasonable but the main problem here is that we need to compare the day of the relativedelta with the current due day, which is currently not possible.
Indeed, I guess we could improve the API to pass the current date to the get function.
in France, I have a supplier like that where the payment day should be done on fixed days after a fixed term of 30 days. But it isn’t a common practice.
For me, it isn’t a required functionnality (I am living without it until now), but if present, I would use it.
Only a fixed day or a list of fixed days?
it is a list. in fact it is the same example as your: on 10 or 20 after fixed term of 30 days.
For only one day, payment conditions are already functional (few of my suppliers are using that too).
Thanks for your effort but I do not think we should manage this case manually as we now that for each invoice of this party we have to pay on a specific day so the system should be able to compute the correct day because we know all the terms involved.
If we have to declare it manually it can be easly solved by updating the term days manually once the invoice is posted.
I’m gonna to talk about another use case for Spain too. Just to give more real data to the topic.
A customer of us use this feature for more than 3 percent of its customers (+200 customers over a total of ~=6000) so in our experience is quite usual.
Moreover it is not only used a fixed or a set of fixed days else a period days to make the payments too.
Below some of them as examples. Fixed days are represented separated by commas, period days by dash:
Editing the line after posting should be a special case where the terms are re-negotiated afterward.
I still think we need to allow definition of custom terms manually.
Of course, I do not say that this manual edition is a good solution when the term rules are perfectly known. But it will help for one time special case.
I’m still in favor of improving the current payment term design to filter out some lines with the current computed date.
Indeed we have similar scenarios on several customers. By now we use account_payment_days but would be great to get it on core.
We have both these cases too (naturally)…
A famous case, also in France, is for subcontractors typically paid either 45 days + end-of-month OR end-of-month + 45 days.
Perhaps there is a possible solution… The possibility to indicate ‘end-of-month’ would allow a bit more flexibility to the deltas, especially if it were possible to add the terms in a list as indicated above with ‘+’.
This is currently possible. You just have to create two relativedeltas from the same line:
This will use always last day of the month.
I presume you mean 45days… yes, okay, and inversely for the other case.
But this doesn’t seem to work reliably with a fixed day other than the last day
(which is presumably what instigated this topic in the first place).
For example, if trying to do the similar (30days + day of month the 10th),
it seems to work okay for invoices issued prior to the 10th of the month, but not for later dates.
That is, seems there is missing a check that the next 10th of the month should be used and not the last one.
Is this equivalent to use -1 day as the day of the month?
No, as negative values are not supported for relativedelta day:
>>> from dateutil import relativedelta
>>> from datetime import date
>>> today = date.today()
>>> today + relativedelta.relativedelta(day=-1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.8/site-packages/dateutil/relativedelta.py", line 405, in __radd__
return self.__add__(other)
File "/usr/lib/python3.8/site-packages/dateutil/relativedelta.py", line 387, in __add__
ret = (other.replace(**repl)
ValueError: day is out of range for month
And there is a domain on the field which enforces that the day is between 1 and 31.
Sorry. I mixed Recurrence rules with Payterm.
I got it.
Recurrence rules are dateutil.rrule based and Payterm is relativedelta based:
class PaymentTermLineRelativeDelta(sequence_ordered(), ModelSQL, ModelView):
'Payment Term Line Relative Delta'
__name__ = 'account.invoice.payment_term.line.delta'
line = fields.Many2One('account.invoice.payment_term.line',
'Payment Term Line', required=True, ondelete='CASCADE')
day = fields.Integer('Day of Month',
domain=['OR',
('day', '=', None),
[('day', '>=', 1), ('day', '<=', 31)],
])
month = fields.Many2One('ir.calendar.month', "Month")
With a self-explained domain.
Yes, that’s something that we are currently missing and also to be able to set multiple fixed thats.
Guess a bug report is in order as this breaks the prior 30day clause
For example, if the invoice date is 31/03 then 30d the 10th will return 10/04 (10 days ) instead of 10/05
Another simple user case that does not work as a user would expect:
A Payment Term defined to be reached Day of Month 5.
From day 1 to 5 of the same month the result is the result expected:
Invoice date: 2020-07-01 -> Due: 2020-07-05
For the rest of the month the result is not the result expected (overdue date):
Invoice date: 2020-07-06 -> Due: 2020-07-05
User would expect in this case:
Invoice date: 2020-07-06 -> Due: 2020-08-05