Archives
Contributors
Re: The future of oca/bank-payment
Well, I would like to give my opinion, as this is a big topic.
IMO, the idea is interesting but has a lot of issues when we go to practice.
For example with the current system we can decide the bank to pay at the end in a simple way, no complication on that side. With this change, everything becomes more complicated, removing part of the functionality that we have and it was much better that the current Odoo behavior. Also, it implies that users will see one TRansference payment method for each journal, and that is a nonsense.
Also, Odoo proposes to generate the payment on the invoices and merge them together at the end to generate the SEPA files, but this si completly different in our case, as we create the payments when we have grouped the moves. Trying to fit both behaviors together might be problematic in the end as the intentions of the fields are completly different.
Personally, I think that we can imagine some benefits, but we will loose functionalities on the change and that is something that is not interesting.
Trying to reuse something that Odoo SA did for EE might have sense, but in this case, it doesn't fit the effort IMO. So, I would prefer to avoid this big change.
My 2 cents.
El mié, 26 mar 2025 a las 12:27, Pedro M. Baeza (<notifications@odoo-community.org>) escribió:
I have expressed my rejection specifically on this new approach due to a lot of reasons:- It's complicating everything, not easing it.- It requires a lot of effort to adapt to it. Both users and developers need to change all they know.- There's no need for this change.- It's not bringing any value.I have exposed all the detailed reasons on the PRs with no answer from anybody.But it's not only that. It's the continuous contempt of Alexis refusing to follow the general OCA guidelines that we all agreed:- One PR per module migration.- Split changes by batches for being reviewable and debatable.- Not clear commit history.- Etc.And I personally have pinged him tens of times for checking fixes or improvements in this set of modules with 0 answers. He disappears during a year and a half, and then comes with a pull request that is changing 108 files at the same time, with breaking changes, and trying to impose to the rest these non agreed changes. I don't think it's fair, even if he is able to do good code.If you want to go this way, you should start a new module set, with different names, but leave the current ones unaltered. We are superseding this week the existing migrations on the current approach to finish them and getting them merged, as several top contributors companies like ForgeFlow, Dixmit and Tecnativa need them already.Regards._______________________________________________
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 - 12:45 - 26 Mar 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