[14.0][IMP] account_payment_order: Fix dates in payments

[Raul-S73]

The date of payments is corrected because the date on which the payment order is confirmed is currently established
This means that payments are not grouped correctly.

Before:

With this changes:

[pedrobaeza]

This was changed on purpose on #1305 and #1311

[Raul-S73]

@pedrobaeza
How are payments going to be grouped if the due date is always the date on which the collection order is confirmed?
If I want to have payments grouped by due date, how do I do it?

[pedrobaeza]

You should change the grouping criteria in the other module then.

[pedrobaeza]

Anyway, if I don't remember bad, the *_grouped_output module groups everything together without more criteria.

[Raul-S73]

@pedrobaeza

Hello again,
I have done this PR due to the needs of our clients.
When they place the payment order until now they were grouped by the due date, this way they had everything more under control. Now there is no possibility to group that way.

With these changes, it returns to grouping by due date, making the groupings in the payment order.

[pedrobaeza]

It was incorrect before, not following the accrual principle. If your customer wants such grouping, I think you must change it at the grouping module, or in your custom.

[gdgellatly]

@pedrobaeza @Raul-S73 This is also a big problem for us. With fixed execution date even, you get the date of confirmation and not the fixed date you proposed. It really is not intuitive, but seeing it won't be changed we will just put in own module.

[pedrobaeza]

As said, that way of working is not correct in accounting terms. It's just like Odoo, that worked a lot of time wrongly posting entries directly in the bank account when you register a payment, and now it works correctly.

[gdgellatly]

cmon @pedrobaeza I am a chartered accountant, so I don't need telling what is correct in accounting terms. It is absolutely correct to show a payment at the date it is paid. whether that is tomorrow or in 6 months time. It is extremely common and every accountant knows this.

[pedrobaeza]

The question is that this is not a payment, it's the promise of a future payment. That's why the journal entry date + due date has been adjusted this way.

[gdgellatly]

Just to follow this up by way of example. I have a balance date of 31 December, and a fixed payment going on 1st Jan. By you argument, the financial year it should appear is whether I do it on the 31st or 1st? complete nonsense to say that a confirmation date is an accounting date.

[pedrobaeza]

On the 31st of December, you have the balance in the outstanding receipt. On the 1st of January, when coming to your bank, you neutralize the outstanding receipt, and have it on the bank account.

What is not correct is to have all the outstanding receipt balance, its neutralization, and the bank balance on the 1st of January.

[gdgellatly]

On the 31st of December, you have the balance in the outstanding receipt. On the 1st of January, when coming to your bank, you neutralize the outstanding receipt, and have it on the bank account.

What is not correct is to have all the outstanding receipt balance, its neutralization, and the bank balance on the 1st of January.

It is a January payment not a december payment, anyway I can't be bothered arguing standard accounting practice going back to the days of postdated cheques. You are right, we will just be wrong somewhere else.

[pedrobaeza]

Well, I'm trying to understand any use case outside of the common ones to check for inconsistencies. Till now, we haven't found any. I don't get if your last comment is irony, or I'm missing some detail being English my foreign language.

[gdgellatly]

It just means it is not a fight worth having when I can add to a custom module in 5 minutes. The use case is simple. It is not a promise of a future payment, it is a plan to pay on a certain date. Now I might understand if we were talking about customer payments, but if you are trying to do any cashflow planning even then I think it is unwise to not record at the correct date, but for suppliers no such promise exists. It is simply a future dated transaction.

[pedrobaeza]

Well, I think any cashflow forecasting should be done using the due date, not the accounting date. It's the same case as with invoices: you have the entry date on the day you post the invoice, but the due date specifies when it should paid/debt.

[gdgellatly]

As I say, I completely disagree, the issue was raised by internal audit, a team of 4 accountants prior to external audit. A fixed execution date is the payment date. But not worth the fight, we fixed it where it needs fixing and everyone can be happy.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.