Archives
Contributors
-
Re: The future of oca/bank-payment
Alexis, even if getting feature parity, that doesn't dismiss that the migration scripts must be done and we must re-educate all the users to the change, while it's not needed.And not only that, you are deforming the standard even more than the previous solution, and that without counting the still rough edges.I'm still standing on the current set of modules, and we already have them migrated.Regards.
by Pedro M. Baeza - 06:46 - 1 Apr 2025 -
Re: The future of oca/bank-payment
Dear community,--Le mer. 26 mars 2025 à 18:09, Alexis de Lattre <alexis.delattre@akretion.com> a écrit :Dear Enric,Le mer. 26 mars 2025 à 12:47, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :For example with the current system we can decide the bank to pay at the end in a simple way, no complication on that side. With this change, everything becomes more complicated, removing part of the functionality that we have and it was much better that the current Odoo behavior. Also, it implies that users will see one TRansference payment method for each journal, and that is a nonsense.Did you test my v18 PR that adds the module account_payment_base_oca https://github.com/OCA/bank-payment/pull/1401 ?My goal was to use the native object account.payment.method.line (used in v18 as "payment mode" on partners and invoices) while keeping the feature "decide the bank to pay at the end in a simple way". And I managed to implement it without breaking the native behavior. It was important to keep this feature !I prepared a short screencast of my PR 1401 that illustrate the fact that my implementation keeps the feature "decide the bank to pay at the end in a simple way", like in OCA/bank-payment v9 to v17 :So we can adopt the native object "account.payment.method.line" and keep the great features of OCA/bank-payment.I even added a small improvement : when you configure "Link to Bank Account" to "Variable", you can select a Default Bank Journal if you want (it's optional).Alexis de Lattre
by Alexis de Lattre - 06:36 - 1 Apr 2025 -
Container Import Workflow
Hi everyone,
We’re working with a client that requires improvements to the container import process in Odoo, and we’re preparing to start development soon. As many of you may know, container imports typically involve a specific workflow, including:
Import documentation
Import type (air, sea, consolidated, etc.)
Landed costs allocation
Container tracking and scheduling
Customs and clearance milestones
Follow-ups on estimated arrival/departure dates
Our current approach is to extend the purchase order model to serve as the foundation of this workflow, allowing us to maintain a familiar structure while introducing the additional logic and tracking needed for container-level visibility and process automation.
Before we begin, we’d like to ask the community:
Is anyone else currently working on something similar or interested in collaborating on this?
Are there existing OCA modules or partial solutions we should consider extending?
We see potential value in making this a broader OCA-compliant project, especially as container tracking and landed cost accuracy are pain points for many companies working with international suppliers.
Happy to share a more detailed spec or jump on a call to discuss use cases. Looking forward to hearing your thoughts and ideas.
Best regards,--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy
by Jorge Elena Poblet - 04:21 - 1 Apr 2025 -
AW: New module for uuid fields
Hi Michael,this sounds interesting to me! Unfortunately, I can't access the repo.Can you share it?
Best,Friedrich
Email: friedrich.sauer@servicum.comPhone: 01721324603
Von: Elektro-Shop Köck GmbH - Michael Köck
Gesendet: Dienstag, 01. April 2025 13:17
Bis: Contributors
Betreff: New module for uuid fields
Hello everyone,
I am currently working on a project where I wanted to use the native postgres type uuid, instead of storing the uuids in plain char fields. Since such a field does not seem to be available in Odoo yet, I threw together a very simple module: https://github.com/mkoeck/base-uuid-field/
Since I saw that there are some existing OCA modules using uuid’s (but storing them in plain char fields), I thought this module might also be interesting to others. I would be happy to integrate this into an existing OCA repo, if someone guides me what the best direction for this would be.
Do note, that I am quite the novice with JS / owl, so any feedback, but especially on that is appreciated J
Best regards,
Michael
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Friedrich Sauer - 04:11 - 1 Apr 2025 -
OWL Trainers Wanted (RFQ Deadline 17th April) by the OCA and AEOdoo
Hello contributors,
The OCA and the Spanish Association (Asociación Española de Odoo ) join forces to organize training on OWL in 2025, in English and in Spanish, with the same content, by the same trainers or different trainers (but the general content must be the same: collaboration to prepare the content will be needed).
⌛ Deadline for submission of your offer: 17th April midnight CET.English:
- Direct link to the RFQ: https://drive.google.com/file/d/1akmiHqtIkX5UU71xIHexpWk4l11TQoWr/view
- RFQ process is explained here: https://odoo-community.org/about/rfq-process#scrollTop=0
The corresponding call on the AEOdoo website in Spanish is here:
https://www.aeodoo.org/blog/licitaciones-abiertas-2/licitacion-curso-tecnico-owl-94
We are looking forward to receiving your proposals and to organizing this demanded content this year!
by Virginie Dewulf - 09:51 - 1 Apr 2025 -
Generic "sequence" and "display_name"
Hello!
I have just opened a server-ux issue to discuss two new generic modules sequence and display_name which are currently in this repo. I would like to get some feedback in the issue before I make pull requests to the OCA, since it is easier to develop all modules in the same branch when they depend on each other.
Best regards,Henrik Norlin
by Henrik Norlin - 08:26 - 31 Mar 2025 -
Re: Contributors
Hi Lope,
The cooperative modules are not yet available in v18. They are available in v16, and there is an ongoing work to port them to v17.
So you could either do the porting yourself to v18, but you have to get in contact with the developer porting to v17 to synchronize with them. We could also do the porting for you (Coop IT Easy is the main author of these modules). In this case, you can contact me directly : victor@coopiteasy.be.
Moreover, depending on your use case, you might need a localization module for your country.
Have a nice day,
Victor Champonnois - Coop IT Easy
On 29/03/25 00:17, Lope Soriao wrote:
I'm working with cooperative in the Philippines, I'm trying to install cooperative module in odoo 18, community edition. Anybody to help.
Help will very appreciated._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Victor - 12:11 - 31 Mar 2025 -
Re: Contributors
Hi Lope,
The cooperative modules are not yet available in v18. They are available in v16, and there is an ongoing work to port them to v17.
So you could either do the porting yourself to v18, but you have to get in contact with the developer porting to v17 to synchronize with them. We could also do the porting for you, in this case you can contact me directly : victor@coopiteasy.be
Moreover, depending on your use case, you might need a localization module for your country.
Have a nice day,
Victor Champonnois - Coop IT Easy
On 31/03/25 03:58, Aboubacar TRAORE wrote:
I am willing to help. What are the modules you are installing?
Le ven. 28 mars 2025 à 23:18, Lope Soriao <notifications@odoo-community.org> a écrit :
I'm working with cooperative in the Philippines, I'm trying to install cooperative module in odoo 18, community edition. Anybody to help.
Help will very appreciated._______________________________________________
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
by Victor - 09:41 - 31 Mar 2025 -
Re: Contributors
I am willing to help. What are the modules you are installing?Le ven. 28 mars 2025 à 23:18, Lope Soriao <notifications@odoo-community.org> a écrit :I'm working with cooperative in the Philippines, I'm trying to install cooperative module in odoo 18, community edition. Anybody to help.Help will very appreciated.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Aboubacar TRAORE - 03:58 - 31 Mar 2025 -
Re: Contributors
I'm working with cooperative in the Philippines, I'm trying to install cooperative module in odoo 18, community edition. Anybody to help.Help will very appreciated.
by buboy2k6@gmail.com - 12:16 - 29 Mar 2025 -
report_py3o
Hello everyone,
we are currently using report_py3o under odoo 16. Is it possible to use report_py3o under odoo 18 or will it be possible in the future?
Please do not hesitate to contact us if you have any questions.
With kind regards
Martin Bando
Computer Science Expert - Software Development | OPAL Solutions GmbH
martin.bando@opal-solutions.de | https://opal-solutions.de
Niederlassung Bochum | T +49 (0)234 541 444 06
Technische Probleme?:
Schreiben Sie direkt eine Email an helpdesk@opal-solutions.de.
Hauptsitz Rheinland | Karl-Heinz-Beckurts-Straße 13 | 52428 Jülich
Niederlassung Ruhrgebiet/Sauerland | Heinrichstraße 67 | 44805 Bochum
Niederlassung Münster/Osnabrück | Gewerbepark 18 | 49143 Bissendorf
T +49 (0)2461 690 280 | F +49 (0)2461 690 284
Amtsgericht Düren | HRB 5889 | Geschäftsführung: Michael von Steht
OPAL Solutions GmbH ist ein Unternehmen der OPAL Associates Holding AGAGB | Impressum | Informationen zum Datenschutz
Follow us on
WICHTIGE MITTEILUNG
Diese E-Mail und deren Anlagen enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser E-Mail und deren Anlagen sind nicht gestattet. OPAL haftet nicht für Schäden, die durch den unerlaubten Gebrauch dieser E-Mail und deren Anlagen entstehen.
IMPORTANT MESSAGE
This e-mail and their attachments may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this e-mail. Unauthorized copying and unauthorized distribution of this e-mail and their attachments are not allowed. OPAL is not liable for damages caused by unauthorized use of this e-mail and attachments.
by Martin Bando - 09:01 - 28 Mar 2025 -
Re: Peppol 2026 Belgium
If you are in the chosen countries. Sadly not for me.On Fri, Mar 28, 2025 at 9:31 PM Enric Tobella Alomar <notifications@odoo-community.org> wrote:Peppol is free and accessible with Odoo communityKind regards,El vie, 28 mar 2025 a las 6:57, Graeme Gellatly (<notifications@odoo-community.org>) escribió:IMO this is something the OCA should look to provide as a chargeable service. Maybe AP access is cheaper in Europe, but OCA can bundle the whole thing.On Fri, Mar 28, 2025 at 1:07 AM Johan Van Hirtum <notifications@odoo-community.org> wrote:Dear,
You need an access point. You find the list of all certified access point on https://peppol.org/members/peppol-certified-service-providers/
Odoo is on the list, but I guess only with EE. You can choose any other access point, but most are not free and there will be a small cost to write the correct connection. So maybe a small EE implementation with only the accounting app, is an elegant and cheap solution..
With kind regards,
Van Hirtum Johan
Van: François Wyaime [mailto:notifications@odoo-community.org]
Verzonden: donderdag 27 maart 2025 12:12
Aan: Contributors
Onderwerp: Re: Peppol 2026 BelgiumHi Tom,
There are some modules in https://github.com/oca/edi to generate invoices in the correct format. But I think there is nothing to send the invoices through the Peppol Network.
Kr,
F.
Le jeu. 27 mars 2025 à 11:38, Tom Blauwendraat <notifications@odoo-community.org> a écrit :
I did this at some point, would it help? This is about generating PEPPOL compatible invoices.
On 3/27/25 11:12, François Wyaime wrote:
Hello,
Does OCA have any plans to comply with the PEPPOL 2026 requirements in Belgium?
We have customers on versions 11.0, 13.0, 15.0, and 16.0, and we cannot migrate all of them before 2026.
Kind regards,François WYAIME
Odoo Expert @ ABAKUS IT-SOLUTIONS
_______________________________________________
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_______________________________________________
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
--Enric Tobella AlomarCEO & Founder_______________________________________________
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 - 09:36 - 28 Mar 2025 -
Re: Peppol 2026 Belgium
Peppol is free and accessible with Odoo communityKind regards,El vie, 28 mar 2025 a las 6:57, Graeme Gellatly (<notifications@odoo-community.org>) escribió:IMO this is something the OCA should look to provide as a chargeable service. Maybe AP access is cheaper in Europe, but OCA can bundle the whole thing.On Fri, Mar 28, 2025 at 1:07 AM Johan Van Hirtum <notifications@odoo-community.org> wrote:Dear,
You need an access point. You find the list of all certified access point on https://peppol.org/members/peppol-certified-service-providers/
Odoo is on the list, but I guess only with EE. You can choose any other access point, but most are not free and there will be a small cost to write the correct connection. So maybe a small EE implementation with only the accounting app, is an elegant and cheap solution..
With kind regards,
Van Hirtum Johan
Van: François Wyaime [mailto:notifications@odoo-community.org]
Verzonden: donderdag 27 maart 2025 12:12
Aan: Contributors
Onderwerp: Re: Peppol 2026 BelgiumHi Tom,
There are some modules in https://github.com/oca/edi to generate invoices in the correct format. But I think there is nothing to send the invoices through the Peppol Network.
Kr,
F.
Le jeu. 27 mars 2025 à 11:38, Tom Blauwendraat <notifications@odoo-community.org> a écrit :
I did this at some point, would it help? This is about generating PEPPOL compatible invoices.
On 3/27/25 11:12, François Wyaime wrote:
Hello,
Does OCA have any plans to comply with the PEPPOL 2026 requirements in Belgium?
We have customers on versions 11.0, 13.0, 15.0, and 16.0, and we cannot migrate all of them before 2026.
Kind regards,François WYAIME
Odoo Expert @ ABAKUS IT-SOLUTIONS
_______________________________________________
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_______________________________________________
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
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 09:30 - 28 Mar 2025 -
Re: The future of oca/bank-payment
Hi,1. This isn't heated, everyone involved knows everyone personally and are used to their comms style.2. As C2C pointed out, if you don't need the existing feature set, then actually you likely don't need the new one anyway.3. In general, you need to give Odoo a couple of versions to consolidate a model. It is far more likely that moving early will incur technical debt as Odoo realise their mistakes, than waiting and using the stable existing OCA model. In any case, the point of contention is a very small, low cost to maintain model. It is probably much cheaper to maintain the status quo for now.4. A solution will eventually be converged on. It's not the first time, and it won't be the last. Things from the outside might look diametrically opposed, but they aren't really that far apart. For now, in terms of getting this across the line for v18, it seems stability trumps a saved field or two.On Fri, Mar 28, 2025 at 8:22 PM Elektro-Shop Köck GmbH - Michael Köck <notifications@odoo-community.org> wrote:
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-paymentHi 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 10On 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
_______________________________________________
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
by Graeme Gellatly - 08:56 - 28 Mar 2025 -
Re: The future of oca/bank-payment
Hi Michael,First of all, thanks for your comments. At the end, all opinions are welcomed.I usually agree (and I think that Pedro too), that it is better to follow Odoo's way in most of the cases. We could see a lot of PR where we proposed to follow Odoo way. However, there are exceptions.For example, in Spanish Localization, we developed a complete different way to create tax reports without using tax tags in order to avoid problems on the creation of the reports.Another example would be EDI. Odoo proposed a way for that, but it was limited. OCA decided to make their own framework for that.This is a similar case IMO. Odoo proposes a limited way that works in small cases. It is interesting, but it is limited and that is a problem in the long term for complex environments. Also, Odoo's proposal fits on their workflow, but we are using a different way. For this reason, we say that we would like to keep the old way just to simplify transition, as we don't see the benefits. In order to make the two ways work together, we are making an overengineered system. This can be counterproductive at the long term.Kind regards,El vie, 28 mar 2025 a las 8:22, Elektro-Shop Köck GmbH - Michael Köck (<notifications@odoo-community.org>) escribió:
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-paymentHi 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 10On 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
_______________________________________________
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
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 08:40 - 28 Mar 2025
