[IMP] account_payment_order: Set orders to done on payment reconciliation

[hbrunn]

@luc-demeyer @pedrobaeza this is the close orders on reconciliation PR. But I don't really get what you mean in point 2 of #784 (comment) - isn't this in terms of reconciliation the same, just with a different account?

When all is ironed out here, this should be very simple to port to 13 and 14

[pedrobaeza]

What I want to move is:

• Instead of generating bank.payment.line, to generate account.payment.
• On v14, it allows all the options of the transfer account (including specific account and journal).
• Use the standard flow, appearing as blue lines in reconciliation and being able to have them in "In process of payment" state in the invoice.

[hbrunn]

your message is about 14, right?

[pedrobaeza]

It can be done as well in v13, but yes, one missing thing in this version is to respect the define transfer account.

[pedrobaeza]

But yes, for v12 I don't think it's possible.

[pedrobaeza]

Reviewing the PR, this can be complementary to what I'm talking about, so OK for me.

[luc-demeyer]

I see the code is already in process of being merged, hence my feedback comes a bit late:
imho we should not put the state back to uploaded once the order is done.
If the accountant removes a reconciliation than he usually knows which actions he needs to perform to redo the reconciles but he will not expect a status change on a done payment order.
I suggest to drop the def remove_move_reconcile(self) logic.

[pedrobaeza]

It's still time for comments, Luc, as no merge command has been launched. I think the reconcile cancel logic is OK, as long as after reconciling again, it turns again to "Done" status, which is what seems to happen.

[hbrunn]

yes, when you reconcile those move lines again the state goes back to done. @luc-demeyer would you be satisfied by a test that proves this?

[luc-demeyer]

@hbrunn @pedrobaeza
Even though the order comes back to 'done' after redoing the reconcile I think it will not be appreciated by the accountant to reopen a 'done' payment order.
Consider it as a TODO list for the accountant for his payments. Once it's done, it means to him that either the payment has been successfully executed or alternatively that he may even never perform the payment (in which case the open item will usually be reconciled via a Refund or a Journal Entry in a Miscellanuous Journal).
For V13 we have added a button to set a payment order to 'done', cf. 752da9a, which I think is a good idea to force a payment order to 'done'. I mentionned the partial reconciles in #784 (comment). Imagine following use case: a payment order is uploaded by the accountant assistant to the web banking application, the accountant connects to the web banking application and changes the amount of one of the payments because of e.g. there is a dispute on a delivery before signing and hence executing the payment. Once the bank statement is downloaded with this reduced amount we'll have a partial reconcile for that particular supplier invoice and this one will remain in that state until the dispute is resolved (could be easily half year later). For the accountant the payment order is 'done'. After dispute resolution the open balance will be paid via a new Payment Order (and that one will be automatically set to done with the logic in this PR).
Hence I think it would be useful to also cherry-pick 752da9a for V12.

[hbrunn]

thanks for the point of view of the accountant. Is everyone on board with removing the unreconcile functionality and adding 752da9a here?

[pedrobaeza]

In my country, it's not possible to edit a sent SEPA order, and if it's the case, as you have said: you have the manual done button to set it again as done. I'm against removing such part, as it's the way to control things. Invoices work this way as well, removing its paid state when unreconciling.

[EvvFoxy]

I see the code is already in process of being merged, hence my feedback comes a bit late: imho we should not put the state back to uploaded once the order is done. If the accountant removes a reconciliation than he usually knows which actions he needs to perform to redo the reconciles but he will not expect a status change on a done payment order. I suggest to drop the def remove_move_reconcile(self) logic.

@luc-demeyer @pedrobaeza @hbrunn From a functional point of view, I agree with Luc Demeyer. Undoing a reconciliation should never reopen a payment order. A reconciliation can be undone for different reasons, but IMHO should never lead to reopening a payment order.

[hbrunn]

now two people for don't mess with the state on unreconcile and two against. @StefanRijnhart would you care to break the tie?

[StefanRijnhart]

@hbrunn I believe that in the case that the transfer move of a payment order is unreconciled after it was first reconciled it does not mean that the payment order is not done. I can only see this happen as a temporary, administrative situation so I tend to go with Luc and Els. Pedro's argument about the analogy with reopened invoices rings true on the technical level yet at the same time it will be much more common to have multiple invoices with the same amount, even for the same customer, than it is to have payment orders of the same amount so it makes much more sense to have this behaviour for invoices, but maybe not for payment orders.

[pedrobaeza]

Ok, you have one vote more for the no state modification on unreconciling after Stefan's argumentation.

[hbrunn]

now without reopening on unreconciliation. Thanks everyone involved!

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[pedrobaeza]

/ocabot merge nobump

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 12.0-ocabot-merge-pr-860-by-pedrobaeza-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at e6b3aea. Thanks a lot for contributing to OCA. ❤️