Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: The future of oca/bank-payment

Archives

Contributors

Re: The future of oca/bank-payment

Re: The future of oca/bank-payment

Re: The future of oca/bank-payment

For me I think this is perhaps not the optimal way. It will become a nightmare as things converge, doing migrations etc for the average user. I would personally feel better if the modules were not renamed and we created say a 18.0-experimental (or future or native or whatever name) branch in the existing repo which is kept synced with 18.0 except these modules.

On Wed, Apr 16, 2025 at 10:22 AM Alexis de Lattre <notifications@odoo-community.org> wrote:
Thanks Virginie for your summary of Friday's meeting.

In the end, I think there is user demand for both solutions:
- Pedro's proposal, which is more conservative with focus on stability of the code and stability of the datamodel,
- my proposal, which is more "bleeding-edge" with focus on innovation and adopting the latest datamodel of Odoo SA, with re-write of large parts of the OCA/bank-payment code base.
I think OCA could host both solutions, with a perspective for re-unification in v19+ if the community that continued with the account.payment.mode object decides to switch to the native datamodel.
In fact, one of the numerous improvements that I proposed in my "revolution" PR for v16.0 (https://github.com/OCA/bank-payment/pull/1174) has been adopted in OCA/bank-payment v16: support the "in_payment" status on invoices ; it is a good example that my revolution PR also benefits to the official 16.0 branch.

During Friday's meeting, I also noticed the difference of judgement on the current code quality of OCA/bank-payment: I personally think that the quality of the current code is pretty poor ; Pedro didn't share my concern on this. The consequence is that, for me, a (partial) re-write of OCA/bank-payment was really needed ; that's what I did in my revolution PR for v16. I can understand that re-writing OCA/bank-payment can raise fears and worries for stability and that some users may prefer to delay the adoption. But I know other OCA devs share my concern about the need for a big cleanup/re-write of OCA/bank-payment and support my v16 revolution PR.

So my proposal is the following: create a new OCA project called bank-payment-native (feel free to propose a better name) with a 18.0 branch that will host my 18.0 migration PRs. To avoid naming conflicts, I would rename the modules:
- account_payment_order => account_payment_order_native
- account_banking_pain_base => account_payment_sepa_base (or account_payment_iso20022_base ?)
- account_banking_sepa_direct_debit => account_payment_sepa_direct_debit (or account_payment_iso20022_direct_debit ?)
- account_banking_sepa_credit_transfer => account_payment_sepa_credit_transfer (or account_payment_iso20022_credit_transfer ?)
- account_banking_mandate => account_payment_mandate
- account_banking_mandate_sale => account_payment_mandate_sale
- account_payment_sale => account_payment_sale_native
The modules account_payment_mode and account_payment_partner are already replaced by a single module account_payment_base_oca in my v18 migration PR.
Again, feel free to propose better module names.

My proposal to create a new OCA bank-payment project may seem a bit extreme because this has never happened before in OCA. But, on the other side, the alternative proposal to keep account.payment.mode involves hiding 3 native fields of the "account" module (2 native fields on res.partner "property_outbound_payment_method_line_id" & "property_inbound_payment_method_line_id" and 1 native field on account.move "preferred_payment_method_line_id"), which also never happened before in OCA AFAIK.

I think the OCA Banking PSC (https://odoo-community.org/psc-teams/banking-10) should decide in the coming days if they agree with the creation of this new OCA project "bank-payment-native" or not (I talked about this with Virginie Dewulf today and she also thinks that it is the role of the Banking PSC to take this decision).

Regards,

Alexis

Le mar. 15 avr. 2025 à 10:43, Virginie Dewulf <virginie@odoo-community.org> a écrit :
Hello everyone,

Last Friday, we had a meeting with Alexis, Pedro, a few PSC of bank project and with Benoit Guillot and Denis Roussel who are Board members and part of the new "Community Health" Working group.

Thanks a lot to those who came and in particular to Alexis and Pedro for the constructive discussion on a Friday night!

We could clarify different aspects:

1/ a part linked to the expected behavior of a maintainer of a module (mainly stick around, answer to other's reviews and follow up of "his" modules and PRs...) which was a part of the discussion in this emails thread. There is no concrete outcome on this topic: it was about sharing feelings and fears of maintaining something done by another and not getting the expected support for it afterwards.

2/ the almost philosophical question about "how to make big changes and refactors inside the OCA code?". 
We agreed that it is accepted to make one PR changing code on various modules. The only constraint is that one PR must make sense on its whole and should ideally not change various aspects/logics at once. The goal of this is to make the work of reviewers easier: they should be able to understand why the changes occur and how they are implemented. We agreed that there is a part of subjectivity here as well but we encourage people to work in a logical way as much as possible when creating new PR's, as well as making meaningful commits. However when there are huge refactors, having one commit per change is not always easy (you change something in commit 4 then change it again in commit 6 together with another thing, it is really more R&D). In this case it is not meaningful to review the PR commit per commit, but it is best to review the final outcome as a whole. 
==> I encourage authors to clarify how they expect the reviewers to do their job and make their life as easy as possible.

3/ on the bank payment topic now:
* Alexis' proposal [3] will most certainly offer an improved code quality as a whole and is normally keeping all current features as is (with light changes in the user interface, like a menu will change place but nothing crazy, as we work with Odoo where this happens a lot)

* The way the PR's has been done make it hard for reviewers to make sure everything will be kept as is, no issue is introduced etc. It is thus hard to make a quick review on this on version 18.

* As the current version of the code is (almost) ready in v18 [3] based on Tecnativa's migration work, this version could be merged into v18 right now (wait for the last point of this email though).

* However, in Alexis' refactor, there is a full refactor of the XML generation that can be included in v18 (no impact on the screens or the features for the end-users, and it is a separated part easy to review). Pedro proposed to work on that together with Alexis and have it integrated in version 18 (even in v16 if requested).

* In Alexis' refactor, the refactor includes the use of standard Odoo field. In the OCA history, we usually use the standard fields as much as possible. However it is also risky as we don't know if Odoo will change the way it is used/coded in the following version (well, this is our daily life, right?!). 
As for this specific case, it is really not clear why Odoo decided to use those fields (the feature doesn't look finished [2]), it might be even riskier to use them from version 18.
=> Alexis would like to get internal Odoo accounting team's insight about their intention on this fields.
=> Pedro will action his network to get an answer on that

* Based on Odoo's intention regarding the fields in question, Pedro and Alexis will work on Alexis' refactor to have it finalized and reviewed for version 19, so that only one stronger solution is kept inside the OCA. 

(Indeed, there is no urgency on Alexis' side to have the big refactored code and improvements in v18 merged into OCA code -- he wanted to have a better version of this existing module as a final purpose, whatever the version.)

Conclusion
We ended the meeting with this last idea, on which Alexis would reflect and decide if he agrees to proceed this way. We agreed that we are waiting for his answer's by this Friday the 18th April.

And finally, we also mentioned the next Spanish OCA Days where Alexis and Pedro could start working on the v19 common option, if we go into this direction.

For those interested to join this event, here are the info, from 2nd to 4th June 2025, in Cartagena (Murcie, Spain):
(I'll be there and I hope to see you there as well!)

References:
[1] PR for migration to 18 for account payment mode https://github.com/OCA/bank-payment/pull/1438, the one for account payment partner https://github.com/OCA/bank-payment/pull/1439
[3] Alexis' refactor proposition

Virginie Dewulf
Executive Director
+32 477 64 17 20


Le lun. 14 avr. 2025 à 22:22, Akim Juillerat <notifications@odoo-community.org> a écrit :
Hello

The meeting was interesting but as I had to leave before the end, I'm wondering what was the outcome as I don't have the link anymore to the working document?

I guess we'll need to have both solutions (old models and Alexis' refactor) coexisting at least in v18.0 ?

Best regards

camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Akim Juillerat
Business solutions
Software architect
+41 62 544 03 78

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


On Thu, Apr 3, 2025 at 11:33 AM Peter Niederlag <notifications@odoo-community.org> wrote:
Hi,

thx for all the passion and patience everythin puts into finding a 
responsible way to pave the road to the future.

As a newbie I can't participate in the discussion due to a lack of 
knowledge.

If no general agreement can be found I'd vote for a good 
communication-strategy that avoids the "f"-word in favor of opinionated 
branching/repos under the umbrella of OCA with the message and strategy 
of "-legacy" vs '-enterprise-compliant" or "-next" and the freedom of 
choice for the users. No agreement should result in free 
choice/competition for the users while clearly explaining the users of 
the two different approaches.

Everyone heading in the very same direction probably would still be the 
best option of all.

best regards,
thx to all you people strengthening the open source way of getting 
things done,
Peter



On 02.04.25 21:36, Virginie Dewulf wrote:





> Hello contributors,





> Thanks for sharing your opinions on this important topic.





> *Proposed next steps:* A





> continuous chain of emails won't help to find a common solution. With





> the "Community Health" WG, I propose to organize an online meeting with





> the concerned parties to find a way towards an agreement. Luc's





> suggestion of having a few days together is a good one, if there is no





> agreement online. The Spanish Odoo Days will be held in June soon: this





> could be a good opportunity.





> The result of the meeting will be shared in this thread to keep a public track of the conversation.





> *A reminder of our intention as a community* We





> are all on the same team, trying to find an open source way in the Odoo





> ecosystem that changes every year. I sometimes picture Odoo S.A. as a





> big and super fast boat on the sea of ERPs. The OCA is a gathering of





> hundreds of small little sailboat (=our PSC teams responsible for





> managing several repos), trying to follow the wind and stay together as





> much as possible. But it is sometimes really hard and chaotic (like with





> the account apocalypse in v13).





> *The underlying problematic of this discussion* Here





> we have an important question: who is the captain of this specific





> sailboat? As each part of the sailboat has been built by a different





> contributor and sometimes taken care for several years by another, who





> has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?





> This is the





> question that we will need to answer as a community, because those





> discussions happened in the past and will continue to arise. And to not





> loose our time and energy on fighting between each others, we will need





> proper governance guidelines on this.





> This will be a task for the





> Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn





> in a newer version of the PSC-guide [1] (which at the moment mention nothing about process to find an agreement).





> Enjoy your week!   Virginie Dewulf Executive Director  Odoo Community Association [2] (OCA) +32 477 64 17 20





> Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar < notifications@odoo-community.org [3] > a écrit :





> I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.





> https://github.com/OCA/bank-payment/graphs/contributors [4]





> Also, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:





> User





> Created PRs





> Merged PRs





> Comments





> Reviews





> OCI





> pedrobaeza





> 49





> 49





> 776





> 539





> 623





> victoralmau





> 72





> 68





> 38





> 64





> 147





> HaraldPanten





> -





> -





> 93





> 80





> 90





> alexis-via





> 41





> 22





> 84





> 48





> 86





> carlosdauden





> 9





> 8





> 12





> 60





> 74





> ValentinVinagre





> 5





> 5





> 40





> 49





> 63





> sergio-teruel





> 5





> 4





> 11





> 35





> 45





> luc-demeyer





> 26





> 14





> 38





> 15





> 40





> joao-p-marques





> 12





> 12





> 19





> 18





> 38





> etobella





> 16





> 15





> 14





> 12





> 35





> ramiadavid





> 11





> 10





> 9





> 19





> 35





> Tisho99





> 15





> 15





> 24





> 10





> 34





> MiquelRForgeFlow





> 12





> 11





> 16





> 15





> 33





> rousseldenis





> 7





> 4





> 28





> 19





> 31





> StefanRijnhart





> 5





> 4





> 20





> 20





> 31





> It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.





> Kind regards,





> El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (< notifications@odoo-community.org [5] >) escribió:





> On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar < notifications@odoo-community.org [6] > wrote:   I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.





> I reviewed the account_payment_partner PR ( https://github.com/OCA/bank-payment/pull/1439 [7] ) and commented to explain again the drawback of keeping payment modes.





> That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.





> If we want to continue using payment modes, we need a better solution to that problem.    My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).    I still hope we can converge. But if we can't, the way to fork is certainly debatable.





> In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork. In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.





> Best regards,





> -Stéphane





> _______________________________________________





> Mailing-List: https://odoo-community.org/groups/contributors-15 [8]





> Post to: mailto: contributors@odoo-community.org [9]





> Unsubscribe: https://odoo-community.org/groups?unsubscribe [10]





> 





> --





> *Enric Tobella Alomar* CEO & Founder





> www.dixmit.com [11]





> _______________________________________________





> Mailing-List: https://odoo-community.org/groups/contributors-15 [12]





> Post to: mailto: contributors@odoo-community.org [13]





> Unsubscribe: https://odoo-community.org/groups?unsubscribe [14]





> 





> 





> _______________________________________________





> Mailing-List: https://odoo-community.org/groups/contributors-15 [15]





> Post to: mailto:contributors@odoo-community.org





> Unsubscribe: https://odoo-community.org/groups?unsubscribe [16]





> 





> 





> 





> [1] https://odoo-community.org/about/psc-guide





> [2] https://odoo-community.org/





> [3] mailto:notifications@odoo-community.org





> [4] https://github.com/OCA/bank-payment/graphs/contributors





> [5] mailto:notifications@odoo-community.org





> [6] mailto:notifications@odoo-community.org





> [7] https://github.com/OCA/bank-payment/pull/1439





> [8] https://odoo-community.org/groups/contributors-15





> [9] mailto:contributors@odoo-community.org





> [10] https://odoo-community.org/groups?unsubscribe





> [11] http://www.dixmit.com





> [12] https://odoo-community.org/groups/contributors-15





> [13] mailto:contributors@odoo-community.org





> [14] https://odoo-community.org/groups?unsubscribe





> [15] https://odoo-community.org/groups/contributors-15





> [16] https://odoo-community.org/groups?unsubscribe





> 

mit freundlichen Grüßen,
Peter Niederlag





-- 
Dipl. Ökonom Peter Niederlag
Geschäftsführender Gesellschafter

Lösungen für digitale Zeiten
Agile DevOps, Cloud, TYPO3, Odoo und Linux

Datenbetrieb Technologie UG(haftungsbeschränkt)
Lipper Hellweg 146,  33605 Bielefeld
Geschäftsführer: Peter Niederlag
HRB 41826 Amtsgericht Bielefeld
Fon 0521 / 446 958 60
Fax 0521 / 446 958 69

_______________________________________________
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 - 01:16 - 16 Apr 2025

Reference

  • The future of oca/bank-payment
    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

    by Stéphane Bidoul - 11:45 - 26 Mar 2025