- Mailing Lists
- Contributors
- Re: OCA/bank-payment-alternative
Archives
- By thread 1419
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 22
Contributors
Re: OCA/bank-payment-alternative
I've been in OCA for years, and honestly, this environment, decisions, and 0 accountability... it just seems like no one wants to take responsibility for anything, and in the end, OCA is shelved due to the lack of collaboration. A new repository will be opened among and for members who truly want to collaborate appropriately.
| ||||||||||||||||||
Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
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
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
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_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Valentín Vinagre - 05:06 - 26 Jun 2025
Reference
-
OCA/bank-payment-alternative
Dear OCA friends,On March 26th 2025, Stéphane Bidoul sent an email on this mailing-list with the subject "The future of OCA/bank-payment". If you missed it, you can find it in the archives:After some long discussion/debate, it was decided to let the chance for an alternative OCA banking project that would use the native payment method object of the "account" module (account.payment.method.line). This project is named OCA/bank-payment-alternative and you can find it here:We had to change the module names in OCA/bank-payment-alternative. Here are the new names that were chosen :OCA/bank-payment OCA/bank-payment-alternative account_payment_order account_payment_batch_oca account_banking_pain_base account_payment_sepa_base account_banking_sepa_credit_transfer account_payment_sepa_credit_transfer account_banking_mandate account_payment_mandate account_banking_mandate_sale account_payment_mandate_sale account_banking_sepa_direct_debit account_payment_sepa_direct_debit account_payment_mode native + account_payment_base_oca account_payment_partner native account_payment_sale account_payment_base_oca_sale Here are the main changes in the datamodel introduced by OCA/bank-payment-alternative :- Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)
- Introduction of account.payment.lot, which represent the Payments Lots (corresponds to the PmtInf i.e. Payment Information block of the SEPA XML files). If your bank groups the debits/credits on your bank statement for the payments, a lot matches one debit or credit payment line on your bank account. This object is generated upon confirmation of the payment order and is used in the generation of the XML (and should soon be used in the bank statement reconcile interface)
- the datamodel of the mandate has been simplified: the field "format" also has the information of the "scheme" field, so "format" now has 3 possible values : basic, sepa_core or sepa_b2b. The field "scheme" has been removed. The field "type" has 2 possible values: recurrent or oneoff (instead of 3 possible values : generic, recurrent or oneoff). The field "recurrent_sequence_type" has been removed because we don't need to handle the "first" vs "recurring" sequence any more : since November 2016, "the requirement to use the sequence type ‘First’ in a first of a recurrent series of Collections is no longer mandatory" according to the European Payment Council (EPC), cf SDD Core Rulebook. The "final" sequence is now supported by the state field which has a new "final" state that can be activated via a button. The field "partner_id" is NOT a related field of partner_bank_id any more, which solves the bug "account_banking_mandate: Change in the filtering behavior of the "Bank Account" field" https://github.com/OCA/bank-payment/issues/1473 With all these simplifications on the mandate datamodel, the form view and list view of mandates are more user-friendly.
- The field generated_user_id has been removed from account.payment.order (the info is present in the chatter)
- On account.payment.method, the boolean field "payment_order_only" has been renamed to "payment_order_ok" (for consistency)
- The boolean field "convert_to_ascii" has been removed from account.payment.method : we consider that this option should be always on (there is a hook in the code in case you need to disable it).
Here is a summary of the new features and improvements by order of importance :- Take into account the boolean field "allow_out_payment" of res.partner.bank on payment orders : when you try to confirm a payment order that has bank accounts on payment lines with allow_out_payment = False, you will get a blocking error message. The affected payment lines will be shown in red and you will have a smart button that gives access to the bank accounts that are not allowed to send money to. To enable "allow_out_payment", you need to be part of a specific group "Validate bank accounts" (XMLID account.group_validate_bank_account). As a consequence, we don't inherit the native ACL of res.partner.bank that give full rights to partner manager any more : the security is handled by "allow_out_payment".
- by default, there is a sequence of payment orders and another sequence for debit orders. It is possible to configure a specific sequence for a payment mode.
- add support for "Regulatory Reporting" in the SEPA XML structure (tag RgltryRptg). Needed in some countries for international non-SEPA credit transfers.
- replace unstructured address by structured address in SEPA XML file (mandatory starting 11/2025)
- add support for pain.008.01.08 (SDD) and pain.001.001.09 (SCT), which are now the recommended versions of the EPC
- easier download of the banking file after generation
- add field acc_number_scrambled on res.partner.bank for easy and direct use of scrambled account number
- search on partner_id from account.payment.order
- support currencies with decimal_places != 2 in ISO20022 XML file generation
- on mandates, fields format, type, signature date and partner are not editable any more when state != draft
- remove support for pain.001.001.02/04/05 (SCT) and pain.008.01.03/04 (SDD) which have never been selected by the EPC, to simplify the code
- stop using safe_eval() in XML generation
- replace all @api.onchange by computed fields
- add sql unicity constraint on payment order number per company
Many bugs have been fixed:- account_banking_sepa_direct_debit: in the SEPA XML file, 'Instruction Identification' and 'End to End Identification' contain "False" https://github.com/OCA/bank-payment/pull/1475
- grouping doesn't take into account the mandate nor sequence type https://github.com/OCA/bank-payment/issues/1336
- No error when creating a SEPA mandate with a non-IBAN bank account https://github.com/OCA/bank-payment/issues/1337
- account_banking_pain_base: Wrong length in AdrLine https://github.com/OCA/bank-payment/issues/1209
- sepa boolean should be false when a payment line has a mandate with format=basic https://github.com/OCA/bank-payment/issues/1476
- account_banking_sepa_direct_debit: cron that expires mandates unused for 3 years should only apply to sepa mandates https://github.com/OCA/bank-payment/issues/1477
You can have a complete list of the changes and bug fixes of OCA/bank-payment-alternative on these 2 issues:But, for me, the most important of OCA/bank-payment-alternative is the investment made on the quality of the code, not only on the SEPA XML generation but also on the lower-level modules.OCA/bank-payment-alternative will continue to focus on code quality and innovation (which involves datamodel changes when needed).Now that the modules are merged, the next priority should be on providing migration scripts for v17 to v18 migration.So, for v18, you now have the choice between OCA/bank-payment and OCA/bank-payment-alternative. Happy hacking !--Alexis de Lattre
Akretion France - 27 rue Henri Rolland - 69100 Villeurbanne - France
Mail : alexis.delattre@akretion.com
by Alexis de Lattre - 03:34 - 21 Jun 2025
