Skip to Content

Contributors

Re: The future of oca/bank-payment

Just ping me if you need review, unfortunately we get failure trying to test locally, but we are in the middle of a 450 module migration, down to last dozen or so, most ultimately depending on payment order. We have production data, freshly migrated via enterprise to do real proper testing on. Only problem we face is we can't aggregate the current merge requests.  Although maybe there is a better way we can do that.

merges:
    - origin $ODOO_VERSION
    # Can't merge 1439 at the moment because of this
    # test-requirements.txt commit:
    # befd64bd07aaa293026b648bc06494d6f1b466fc
    #- origin refs/pull/1438/head # 'account_payment_mode'
    #- origin refs/pull/1439/head # 'account_payment_partner'
    #- origin refs/pull/1440/head # 'account_payment_order'

On Wed, Apr 16, 2025 at 7:22 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:

- The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.
- The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.
- It contains a lot of datamodel changes apart from the main question, which are the same problematic.

And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...

I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.

Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.

Regards.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe


by Graeme Gellatly - 11:06 - 16 Apr 2025

Reference

  • The future of oca/bank-payment
    Hi everyone,

    The oca/bank-payment repository has the essential modules to prepare and generate SEPA (and more) payment orders for credit transfer and direct debit.

    Today, there are important decisions to make about the future of this module.

    18 months ago, Alexis de Lattre, (one of) the original authors of these modules, started a huge effort to modernize these modules and improve their overall quality.
    He explained his approach in this PR 1174 for 16.0  [1]. 
    Naturally, that PR was not merged because it came too late in the 16.0 release cycle. 

    Now Alexis continues this effort with a series of 18.0 pull requests, with the important addition that he proposes to replace the Payment Mode object by the now native object from Odoo. 

    In Odoo v18, Odoo SA introduced new "Payment mode" M2O fields in the "account" module (cf this commit [6]):
    - on res.partner : one property field "Customer Payment Method" and one property field "Supplier Payment Method"
    - on invoices (account.move) : one field "Payment Method", copied from res.partner and that can be modified
    Up to Odoo v17, these "Payment mode" fields were not native ; they were added by the OCA module account_payment_partner from OCA/bank-payment.
    These new native "Payment mode" fields use the model account.payment.method.line (which was introduced in v15).

    Migrating to use these native fields makes a lot of sense to align with Odoo to avoid duplication of fields and logic.

    For more context, There was some discussion in the 16.0 PR [1], the 18.0 migration issue [4], as well as [5].

    I personally very much welcome this effort as I think the quality of Alexis' work is excellent (as usual), and this will create a solid foundation for the future.
    Indeed, over the many years of history of these modules, the only significant refactoring was Pedro's important work to adapt them to use Account Payment, and these modules start to show their great age.

    Alexis' work can be tested on runboat PR 1406 for direct debit [2] and PR 1405 for credit transfer [3]. From the preliminary tests we have done at Acsone it works fine.

    Of course, such work is not a traditional migration, and is difficult to review due to the importance of the changes. This will also create some additional migration work for maintainers of modules that depend on it (for instance the migration from Payment Mode to native Payment Methods will require some effort, although not difficult).

    On the other hand, reaching the same result by incremental improvements is going to be impossible, because as soon as a module is merged it starts to be extended, and some evolutions will not be possible in a backward-compatible way.

    So Akretion and Acsone propose to add migration scripts, and merge Alexis' work in 18.0 and rapidly iterate from there to review and add possible features that would have been missed in the transition. At Acsone we plan to put significant effort on this repo in the coming 3-4 months.

    Would there be agreement on such an approach?

    Best regards,

    -Stéphane


    by Stéphane Bidoul - 11:45 - 26 Mar 2025