Archives
Contributors
-
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 -
Re: The future of oca/bank-payment
Up to the moment, I haven't heard any convincing reason to switch to the new refactoring, except saying the generic words "it does bring value, in terms of compatibility and interoperability with standard Odoo", which is not true, as the compatibility was assured in my previous refactoring generating 100% compatible account.payment records with the account.payment.method.line set on them. On contrary, this new refactoring is deforming more the standard, touching a lot the account.payment.method.line object, as you can see in https://github.com/OCA/bank-payment/pull/1401/files#diff-be0f3f1e5863cde871372af8c252f077a8111278e1fdda3f562415e2d96164ce, trying to convert this object into account.payment.mode. Why doing that if we already have the exact model we need?!! And it's also limiting the selection of the standard res.partner many2one fields. This is not making it more compatible, this is breaking enterprise modules' way or working, as you can't select the payment method line they need!The effort to educate all our users to the new system is not justified, and there's still more work to do, as the migration scripts are not done.Finally, this new refactoring has been done over the forked 16.0 version of Alexis, not the clean 17.0 latest version, which is discarding all the contributions made by other OCA contributors meanwhile, which is ugly, and it will also cause solved bugs to appear again.Due to all of this, we should stick to the existing version, and answering Michael's reply that has just entered while I was redacting this, the current suite has no technical debt. Don't get it wrong.Regards.
by Pedro M. Baeza - 08:40 - 28 Mar 2025 -
Re: Peppol 2026 Belgium
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
by Graeme Gellatly - 06:56 - 28 Mar 2025 -
Re: The future of oca/bank-payment
Hi everybodyFor 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 ctsBest regardscamptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSAkim JuilleratBusiness solutionsSoftware architectOn 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 modifiedUp 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
by Akim Juillerat - 09:56 - 27 Mar 2025 -
Re: The future of oca/bank-payment
Sorry, I just made an important typo in my previous email below: I wrote:"So what about a plan like that:- on OCA/pank-payment we get the essential modules ported to 18.0 with refactor, so users expecting a cheap and early migration get it.
- in the meantime, a new repo like OCA/bank-payment-next is created and get the refactor on v18.0 (with possible backports to please some users eventually, some already use that in v16 it seems)
Of course I meant: 1. on OCA/pank-payment we get the essential modules ported to 18.0 WITHOUT refactor, so users expecting a cheap and early migration get it.On Thu, Mar 27, 2025 at 12:06 PM Raphaël Valyi <notifications@odoo-community.org> wrote:Hello contributors,I think most of us can agree on:- It's legit OCA users/contributors who adopted OCA/bank-payment expect an easy and early migration to Odoo v18 as this is a bit the promise of the OCA when we do the usual PRs dance to make the small refactors.
- While it may not seem urgent, a big refactor of OCA/bank-payment seems legit as well and desirable in the long run (see Alexis, Acsone and Noviat points).
So what about a plan like that:- on OCA/pank-payment we get the essential modules ported to 18.0 with refactor, so users expecting a cheap and early migration get it.
- in the meantime, a new repo like OCA/bank-payment-next is created and get the refactor on v18.0 (with possible backports to please some users eventually, some already use that in v16 it seems)
The parties in favor of the refactor agree to assume the effort for:- porting a minimal set of "must have" OCA/bank-payment modules to the new design in v18.0 (like 10 modules out of the 19 modules in the 16.0 branch?)
- creating a set of scripts for migrating these "must have" modules from the standard 18.0 to the new 18.0 design.
- The script may somewhat be tested a bit like OpenUpgrade is tested: a database A is created with the standard 18.0 modules, scripts are applied and tests in the next branches are run on the migrated database.
Then we should of kind make a deal where if these first parties do this work in v18.0,Then in version 19.0, the next design is adopted as the base and the parties not in favor of the immediate refactor, assume a part of the remaining port work for some of the other important modules.Then it would boil down to agreeing on what are these "must have modules" people in favor of the refactor must agree port and assume a migration script for. What do you think?On Thu, Mar 27, 2025 at 11:17 AM luc.demeyer <notifications@odoo-community.org> wrote:What about organising a 2-3 days code sprint in the short term with the key OCA contributors for the bank-payment repo to align our ideas via face-to-face meetings.
I am worried about ending up with two forks of these modules which would weaken our combined strength in this area.
I don’t think we can afford waiting on the October code sprint to sort this one out.
I am prepared to travel to France, Spain, ... if it can help to move forward on this.
Regards,
Luc
From: Alexis de Lattre <notifications@odoo-community.org>
Sent: Thursday, 27 March 2025 11:37
To: Contributors <contributors@odoo-community.org>
Subject: Re: The future of oca/bank-paymentLe mer. 26 mars 2025 à 18:58, Pedro M. Baeza <notifications@odoo-community.org> a écrit :
>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.
I agree with most of your critics on commit history, single PR vs 1 PR per change, etc. I'm not the "perfect contributor".
But I'm very surprised about your critics on the way I made the "revolution" in OCA/bank-payment v9. Do you really think I could have made the revolution in v9 with the rule "1 PR per change" ? I made so many datamodel changes in v9 that, with this rule, I would have had to make 20 PRs. Is it possible to do a datamodel revolution across 20 PRs ? When I made this work during the Sorrento code sprint, I had 7 or 8 iterations on the new datamodel before finding the "best" datamodel, which is still in use today. Could you imagine 7 or 8 datamodel iterations across 20 PRs ?
My opinion is : the rule "one PR per change" doesn't work when you need to make big changes. This is what happened in v9 ; this is what needs to be done now.
In my v16 "revolution" PR (https://github.com/OCA/bank-payment/pull/1174), I made 33 changes. So I would have had to make 33 PRs. Given the time and effort needed to make a 1 OCA PR, the consequence is that I wouldn't start such a big work because of the lack of time and energy. But this big cleanup/refactoring/improvements was really needed, so I decided to invest the time to do it, with the same spirit that when I made the revolution in OCA/bank-payment for v9 during the Sorrento code sprint : do the big cleanup/refactoring/improvements with little considerations for the question "will it be accepted/merge in OCA" but focus on "what's best for the quality of the code of OCA/bank-payment".
> 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.
These features are present in my module account_payment_base_oca, cf :
cf fields "report_description", "show_bank_account" and "show_bank_account_chars".
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.
In my implementation in PR #1401, you CAN have a generic payment mode called "SEPA DD" with 5 bank accounts (journals) :
1) Odoo auto-generate 5 account.payment.method.line ; they have "selectable=False" by default.
2) you manually create a 6th account.payment.method.line with :
- selectable=True
- bank_account_link = "variable"
- variable_journal_ids : M2M that points to the 5 bank journals
- journal_id = False
(company_id is defined as related=journal_id.company_id in the account module ; account_payment_base_oca changes that to a computed field, so have company_id set to self.env.company when journal_id=False)
The native 3 M2O "Payment Mode" fields (2 on res.partner and 1 on invoices) are updated to filter on selectable=True.
I'm the one who introduced bank_account_link=variable on payment mode during the Sorrento code sprint on OCA/bank-payment v9. Don't count on me to remove this feature !!!
> 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...
The why of this change is pretty simple : adopt the native datamodel of Odoo on payment mode (and keep the great features we have in OCA/bank-payment since v9, including bank_account_link=variable). In v18, there are 3 M2O fields that point to account.payment.method.line (2 on res.partner, 1 on invoice).
I stay in my position of keeping current modules, which are not old, are stable and with no need of changing that.
Just a few code example of why I initiated this big cleanup in OCA/bank-payment v16 that I now propose in v18. Most of this dirty code has been written by me back in v5, so I have no problem to critize it:
https://github.com/OCA/bank-payment/blob/17.0/account_banking_pain_base/models/account_payment_order.py#L14 => use of safe_eval
https://github.com/OCA/bank-payment/blob/17.0/account_banking_sepa_credit_transfer/models/account_payment_order.py#L161 => passing "line.currency_id.name" as string, which is then interpreted by safe_eval... beurk !
https://github.com/OCA/bank-payment/blob/17.0/account_banking_sepa_credit_transfer/models/account_payment_order.py#L172 => ISO20022 XML generation is hard-coded to 2 decimals, so the current code doesn't support currencies that have a number of decimals different than 2. This is not a problem for SEPA credit transfer, but this is a real problem for international credit transfer that use non-SEPA ISO20022 files.
https://github.com/OCA/bank-payment/blob/17.0/account_payment_order/models/account_journal.py#L10 => this code adds 2 fields "inbound_payment_order_only" and "outbound_payment_order_only" that are used nowhere ! It's just "dead code" !
--
Alexis de Lattre
_______________________________________________
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
--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant
by Raphaël Akretion - 01:12 - 27 Mar 2025
