[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