- Mailing Lists
- Contributors
- Re: The future of oca/bank-payment
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: The future of oca/bank-payment
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
https://github.com/OCA/bank-payment/graphs/contributors
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>) escribió:
On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar <notifications@odoo-community.org> 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) 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
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Enric Tobella Alomar
CEO & Founder

by Enric Tobella Alomar - 11:51 - 2 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 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
by Stéphane Bidoul - 11:45 - 26 Mar 2025