Contributors

Hi all,

 

Since this has become quite a heated discussion, I’d like to add my perspective.

 

Full disclosure: I haven’t personally used oca/bank-payment, nor have I reviewed its code. Still, I think it's valuable to offer input as someone involved in IT strategy and company direction — especially from the lens of a potential new user.

 

From that perspective, if I were evaluating two versions of the same module—one with limited functionality that follows Odoo's standard interface, and another with broader features but a custom interface—I would almost certainly lean towards the one that adheres to Odoo’s standard. For me, it boils down to total cost of ownership. If I’m already maintaining systems that follow Odoo’s conventions, adding a module that fits within those boundaries is a relatively low-effort integration. On the other hand, adopting a module that diverges from the core design increases complexity and long-term maintenance costs significantly.

 

Even if the standard-compliant version lacked a few features, the cost of adding or forward-porting what I need would likely still be less than the cost of maintaining a technically divergent solution.

 

That said, I completely understand that existing users of oca/bank-payment might feel differently. For them, the custom interface is already familiar and integrated into their processes, so switching to Odoo SA's native approach might increase their short-term costs. However, it's worth recognizing that by choosing to avoid transitioning to the new standard, they are effectively taking on technical debt. This may reduce their costs in the present, but over time, as they encounter the need to adopt features from Odoo SA’s modules, the divergence from the core could significantly raise their future maintenance burden.

 

Of course, technical debt is not inherently bad—it can be a useful tool if taken on intentionally and with a plan. It's not my place to say whether the current users should make this investment now or not. Only they can weigh the effort required against the expected benefit.

 

Separately, I think it’s important to distinguish between whether to adopt the new direction and how to manage that transition. On the latter point, many valid and thoughtful suggestions have already been made.

 

Best regards,

Michael

 

Von: Akim Juillerat [mailto:notifications@odoo-community.org]
Gesendet: Donnerstag, 27. März 2025 21:58
An: Contributors
Betreff: Re: The future of oca/bank-payment

 

Hi everybody

 

For what it's worth, at camptocamp we've been using these modules until v17.0, and for a few customers we are actually migrating to v18.0 we try to avoid the use of these modules and rely on the new Odoo standard since it might be enough more than 90% of the time.

 

Then, for the 10% left where such modules are probably still needed, we'll try to use the newer version as proposed by Alexis since there does not seem to be any missing features. Better hop on the train early enough to avoid diverting too much from the standard, otherwise we'll be delaying the issue until the next migration which does not provide much benefit in the long run...

 

My 2 cts

 

Best regards

camptocamp

INNOVATIVE SOLUTIONS

BY OPEN SOURCE EXPERTS

 

Akim Juillerat

Business solutions

Software architect

+41 62 544 03 78

 

Camptocamp SA
Leberngasse 21
4600 Olten
Switzerland
+41 21 619 10 10

www.camptocamp.com

 

 

On Wed, Mar 26, 2025 at 11:46 AM Stéphane Bidoul <notifications@odoo-community.org> wrote:

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

 

[1] https://github.com/OCA/bank-payment/pull/1174

[2] https://github.com/OCA/bank-payment/pull/1406

[3] https://github.com/OCA/bank-payment/pull/1405

[4] https://github.com/OCA/bank-payment/issues/1364

[5] https://github.com/OCA/bank-payment/pull/1401

[6] https://github.com/odoo/odoo/commit/cdd15963a512e260b5b69d9ec274799747484095#diff-a13b3dfd8d9e1c45eee3b202345ad950f6b90db975708ee34b9bff2886f4513d

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

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

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