[15.0][OU-FIX] account: fill payment_method_line_id

[remytms]

The payment_method_line_id field is a stored field and should be filled during migration. Here is a proposal to fill it with python code in post-migration.py.

[pedrobaeza]

This is already filled in end-migration:

OpenUpgrade/openupgrade_scripts/scripts/account/15.0.1.2/end-migration.py

Line 36 in ff1363a

def _fast_fill_account_payment_payment_method_line_id(env):

Maybe the comment in the analysis work file is needed, but nothing more.

[remytms]

Indeed, I did not look at the right place, with updated comment it will be easier.

I did this commit because I have a case where payment_method_line_id is not set with the actual migration script. But is correctly filled with the python code I posted.

E.g.:

=> select id, move_id, payment_method_id, payment_method_line_id from account_payment where id = 146;
 id  | move_id | payment_method_id | payment_method_line_id 
-----+---------+-------------------+------------------------
 146 |    1310 |                 4 |                       
(1 ligne)

=> UPDATE account_payment ap
        SET payment_method_line_id = apml.id
        FROM account_move am
        JOIN account_payment_method_line apml ON apml.journal_id = am.journal_id
        WHERE ap.move_id = am.id AND ap.payment_method_id = apml.payment_method_id;
UPDATE 31

=> select id, move_id, payment_method_id, payment_method_line_id from account_payment where id = 146;
 id  | move_id | payment_method_id | payment_method_line_id 
-----+---------+-------------------+------------------------
 146 |    1310 |                 4 |                       
(1 ligne)

With python code I ended with:

=> select id, move_id, payment_method_id, payment_method_line_id from account_payment where id = 146;
 id  | move_id | payment_method_id | payment_method_line_id 
-----+---------+-------------------+------------------------
 146 |    1310 |                 2 |                      4
(1 row)

I will look at the existing SQL command to see why it does not fill payment_method_line_id correctly in all cases.

[remytms]

We see in my previous comment that when using the python code (the same as compute method) it changes the payment_method_id. That is because in 16.0 payment_method_id is the one found in payment_method_line_id.

The SQL command in the OU script does not update the line because there is no such payment_method_line that match the condition.

=> select * from account_payment as ap join account_move as am on ap.move_id = am.id join account_payment_method_line apml ON apml.journal_id = am.journal_id  where move_id = 1310 AND ap.payment_method_id = apml.payment_method_id;
-> return 0 records

[remytms]

In fact, I think the problem comes from the fact that inbound/outbount_payment_method were not correctly ported from 14.0 to 15.0.

I have an account.journal like that in 14.0:

Using the account_banking_sepa_credit_transfer module.

And in 16.0:

The sepa_credit_transfer method is removed when migrating because of this line. It creates payment_method_line_ids only for "manual" payment method.

Is there a reason for that ?

[pedrobaeza]

Not all payment methods should generate payment method lines. That's why this is only handling manual ones, but I think for SEPA DD/SCT may be correct to generate them.

[remytms]

Thanks @pedrobaeza I will submit a correction for SEPA method in another PR. And for this PR I just left the improved comment in the analysis file.

[legalsylvain]

Thanks !

/ocabot merge nobump

[OCA-git-bot]

What a great day to merge this nice PR. Let's do it!
Prepared branch 15.0-ocabot-merge-pr-4537-by-legalsylvain-bump-nobump, awaiting test results.

[OCA-git-bot]

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