[18.0][FIX] Payment return import iso20022 match by payment id

[qgroulard]

Draft PR to open a discussion.
From my understanding and functional tests, the payment_id and not the move_id is passed as the End2end_identification from the generation of the payment order to the reception of the return.

I don't understand how can we expect to receive the move_id as the line reference. Is this a mistake or can someone explain this mechanism to me ?

[qgroulard]

Anyone ? @pedrobaeza @carlosdauden ?

[pedrobaeza]

Please check latest code, which may resolve your problem.

[qgroulard]

1. The latest code still searches the payment by move_id, see: https://github.com/OCA/account-payment/blob/18.0/account_payment_return_import_iso20022/models/payment_return.py#L19

2. While in account_banking_sepa_direct_debit, the End2end_identification is set as the payment_id and not the move_id, see: https://github.com/OCA/bank-payment/blob/18.0/account_banking_sepa_direct_debit/models/account_payment_order.py#L175

Also see https://github.com/OCA/account-payment/blob/18.0/account_payment_return_import_iso20022/wizard/camt_parser.py#L64 for the last brick, that puts the EndtoEndId (from 2.) in the line reference used in 1.

Thus there is something that I truly don't understand. Don't you use account_banking_sepa_direct_debit to generate your payment orders ? Then, what mechanism do you use to inject the move_id in the EndtoEndId tag ?

[pedrobaeza]

@carlosdauden can you please check this PR to see what he is stating?

Yes, we use bank-payment modules, but we haven't got problems with this AFAIK.

[qgroulard]

1. The latest code still searches the payment by move_id, see: https://github.com/OCA/account-payment/blob/18.0/account_payment_return_import_iso20022/models/payment_return.py#L19

   2. While in account_banking_sepa_direct_debit, the End2end_identification is set as the payment_id and not the move_id, see: https://github.com/OCA/bank-payment/blob/18.0/account_banking_sepa_direct_debit/models/account_payment_order.py#L175

Also see https://github.com/OCA/account-payment/blob/18.0/account_payment_return_import_iso20022/wizard/camt_parser.py#L64 for the last brick, that puts the EndtoEndId (from 2.) in the line reference used in 1.

Thus there is something that I truly don't understand. Don't you use account_banking_sepa_direct_debit to generate your payment orders ? Then, what mechanism do you use to inject the move_id in the EndtoEndId tag ?

@carlosdauden

Sorry but I need to move forward with this.

We have tested the full workflow from account_banking_sepa_direct_debit to account_payment_return_import_iso20022, our observations are explained in this comment.

[gva-acsone]

Functional test LGTM

[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.

[qgroulard]

Hi, just to let you know that we have been using this PR in production for 4 months with great results.

We are only using the OCA modules account_banking_sepa_direct_debit and account_payment_return_import_iso20022, nothing custom on top.

This still looks like the way to go to me.