Archives
Contributors
Re: The future of oca/bank-payment
Hi,
We are affected by this, and extend these for the NZ case, but are not quite far enough along in our migration testing efforts to be able to offer anything concrete.
In my previous career we had a rule, First you must be equal, then you can be different. For me, this feels like a classic case of thinking the first is met, going to market and finding out it might not be, or it is communicated incorrectly. I don't know if it is true or not, is resolvable or not or if the effort is worth it. But until the objections can be resolved, I do not think you can make such a change.
However, having now read through the correspondence on the PR's, and envisioning our own users and use cases, if the default Odoo behaviour/proposed change is as described, essentially tying payment modes to specific journals then I think there needs to be a lot of convincing as to how this is better. I think it is all very well to say test on runboat but I would much rather we had some video/screen recording here that really shows the changes, and the pro's and con's.
On Thu, Mar 27, 2025 at 7:31 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:
Dear Alexis,I think that Pedro exposed a perfect example of what we might loose. We are trying to enforce the logic of the system to fit in Odoo's standard, but sometimes it doesn't. I think this is one of this cases. Maybe on the future Odoo makes changes so we don't have this discussion anymore, but it is not the moment right now.Actually, some of my customers are using the exact example that Pedro provided.Anyways, this is just a complain of one of the changes, for all the others, I would prefer to see a more granular commit history in order to evaluate it. Also, some of the changes have conflicts with changes applied to the module by other contributors that you forget to add. Right now we are providing a massive change with 4000 additions and 8000 deletions. Also, there we can find conflicts.Just to finish, the migrations that you made come from your main branch. I know that you use only some of the versions, but the right approach is to use 17 to get the changes of the latest version (also it is easier to detect changes on names and so on to create the migration scripts). It might be harder for you, but this is how it should be done.Kind regards,El mié, 26 mar 2025 a las 18:58, Pedro M. Baeza (<notifications@odoo-community.org>) escribió:>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.> About the Payment Mode, In my view it does bring value, in terms of compatibility and interoperability with standard Odoo, as well as ergonomicsThere'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.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.> About the migration effort, yes, there is someThere'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...I stay in my position of keeping current modules, which are not old, are stable and with no need of changing that.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 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 - 08:38 - 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