1. Mailing Lists
  2. Contributors
  3. Re: The future of oca/bank-payment

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: The future of oca/bank-payment

Re: The future of oca/bank-payment

Avatar

Re: The future of oca/bank-payment

by
Tecnativa. S. L., Pedro M. Baeza
- 26/03/2025 18:54:55
>About the work method to bring these evolutions, I also totally agree that doing changes in small steps is preferable, but the problem is when you want to do large scale improvements, it is impossible when a version is released, as you inevitably need to break compatibility for someone, even in small ways, so improvements within an Odoo series we are quickly frozen. So the best moment is when doing a major upgrade. That is why Alexis prepared the work on 16.0 to show what he was aiming at, and now is a good moment to land his work in 18.0.

That's not true. He continously refuses to split the changes, and has a chaotic commit history, with no explanations, data model changes, etc, all mixed, as it happened in v9.

> About the Payment Mode, In my view it does bring value, in terms of compatibility and interoperability with standard Odoo, as well as ergonomics

There's no such compatibility problems, and the interoperability is already assured on the generated account.payment. This is not something new of this version.

> avoiding two fields and models with almost identical meaning.

That's the problem: they are far from being identical in meaning. The payment mode is far more advanced than the payment method line. It allows you to have a text associated that it's shown in the invoices. It allows you to dynamically have bank account numbers displayed in the invoice (both customers and your own bank accounts). It allows you to aggregate as you prefer payment methods with bank accounts, etc.

Imagine this case: you have a generic payment mode called "SEPA DD" with 5 bank accounts (journals) linked, but other payment modes "SEPA DD Bank 1", "SEPA DD Bank 2", etc, and for certain invoices, you change the payment mode for fixing that bank, but by default, the generic one is used and the bank is not important. You won't be able to do this with your new approach.

> About the migration effort, yes, there is some

There's a lot of effort, and confused users about the why of this change. There's no advantages in this change. And you are not saving tons of code as the previous refactoring did. Just 2 m2o fields...

I stay in my position of keeping current modules, which are not old, are stable and with no need of changing that.

Regards.

Reference