Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • Re: The future of oca/bank-payment
    Hello contributors,

    I think most of us can agree on:
    1. It's legit OCA users/contributors who adopted OCA/bank-payment expect an easy and early migration to Odoo v18 as this is a bit the promise of the OCA when we do the usual PRs dance to make the small refactors.
    2. While it may not seem urgent, a big refactor of OCA/bank-payment seems legit as well and desirable in the long run (see Alexis, Acsone and Noviat points).
    So what about a plan like that:
    1. on OCA/pank-payment we get the essential modules ported to 18.0 with refactor, so users expecting a cheap and early migration get it.
    2. in the meantime, a new repo like OCA/bank-payment-next is created and get the refactor on v18.0 (with possible backports to please some users eventually, some already use that in v16 it seems)
    The parties in favor of the refactor agree to assume the effort for:
    1. porting a minimal set of "must have" OCA/bank-payment modules to the new design in v18.0 (like 10 modules out of the 19 modules in the 16.0 branch?)
    2. creating a set of scripts for migrating these "must have" modules from the standard 18.0 to the new 18.0 design.
    3. The script may somewhat be tested a bit like OpenUpgrade is tested: a database A is created with the standard 18.0 modules, scripts are applied and tests in the next branches are run on the migrated database.
    Then we should of kind make a deal where if these first parties do this work in v18.0,
    Then in version 19.0, the next design is adopted as the base and the parties not in favor of the immediate refactor, assume a part of the remaining port work for some of the other important modules.

    Then it would boil down to agreeing on what are these "must have modules" people in favor of the refactor must agree port and assume a migration script for. What do you think?


    On Thu, Mar 27, 2025 at 11:17 AM luc.demeyer <notifications@odoo-community.org> wrote:

    What about organising a 2-3 days code sprint in the short term with the key OCA contributors for the bank-payment repo to align our ideas via face-to-face meetings.

    I am worried about ending up with two forks of these modules which would weaken our combined strength in this area.

    I don’t think we can afford waiting on the October code sprint to sort this one out.

    I am prepared to travel to France, Spain, ... if it can help to move forward on this.

     

    Regards,

    Luc

     

    From: Alexis de Lattre <notifications@odoo-community.org>
    Sent: Thursday, 27 March 2025 11:37
    To: Contributors <contributors@odoo-community.org>
    Subject: Re: The future of oca/bank-payment

     

     

     

    Le mer. 26 mars 2025 à 18:58, Pedro M. Baeza <notifications@odoo-community.org> a écrit :

    >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.

     

    I agree with most of your critics on commit history, single PR vs 1 PR per change, etc. I'm not the "perfect contributor".

     

    But I'm very surprised about your critics on the way I made the "revolution" in OCA/bank-payment v9. Do you really think I could have made the revolution in v9 with the rule "1 PR per change" ? I made so many datamodel changes in v9 that, with this rule, I would have had to make 20 PRs. Is it possible to do a datamodel revolution across 20 PRs ? When I made this work during the Sorrento code sprint, I had 7 or 8 iterations on the new datamodel before finding the "best" datamodel, which is still in use today. Could you imagine 7 or 8 datamodel iterations across 20 PRs ?

     

    My opinion is : the rule "one PR per change" doesn't work when you need to make big changes. This is what happened in v9 ; this is what needs to be done now.

    In my v16 "revolution" PR (https://github.com/OCA/bank-payment/pull/1174), I made 33 changes. So I would have had to make 33 PRs. Given the time and effort needed to make a 1 OCA PR, the consequence is that I wouldn't start such a big work because of the lack of time and energy. But this big cleanup/refactoring/improvements was really needed, so I decided to invest the time to do it, with the same spirit that when I made the revolution in OCA/bank-payment for v9 during the Sorrento code sprint : do the big cleanup/refactoring/improvements with little considerations for the question "will it be accepted/merge in OCA" but focus on "what's best for the quality of the code of OCA/bank-payment".

     

    > About the Payment Mode, In my view it does bring value, in terms of compatibility and interoperability with standard Odoo, as well as ergonomics

     

    There'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.

     

    These features are present in my module account_payment_base_oca, cf :

    cf fields "report_description", "show_bank_account" and "show_bank_account_chars".

     

    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.

     

    In my implementation in PR #1401, you CAN have a generic payment mode called "SEPA DD" with 5 bank accounts (journals) :

    1) Odoo auto-generate 5 account.payment.method.line ; they have "selectable=False" by default.

    2) you manually create a 6th account.payment.method.line with :

    - selectable=True

    - bank_account_link = "variable"

    - variable_journal_ids : M2M that points to the 5 bank journals

    - journal_id = False

    (company_id is defined as related=journal_id.company_id in the account module ; account_payment_base_oca changes that to a computed field, so have company_id set to self.env.company when journal_id=False)

    The native 3 M2O "Payment Mode" fields (2 on res.partner and 1 on invoices) are updated to filter on selectable=True.

     

    I'm the one who introduced bank_account_link=variable on payment mode during the Sorrento code sprint on OCA/bank-payment v9. Don't count on me to remove this feature !!!

     

    > About the migration effort, yes, there is some

     

    There'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...

     

    The why of this change is pretty simple : adopt the native datamodel of Odoo on payment mode (and keep the great features we have in OCA/bank-payment since v9, including bank_account_link=variable). In v18, there are 3 M2O fields that point to account.payment.method.line (2 on res.partner, 1 on invoice).

     

    I stay in my position of keeping current modules, which are not old, are stable and with no need of changing that.

     

    Just a few code example of why I initiated this big cleanup in OCA/bank-payment v16 that I now propose in v18. Most of this dirty code has been written by me back in v5, so I have no problem to critize it:

    https://github.com/OCA/bank-payment/blob/17.0/account_banking_sepa_credit_transfer/models/account_payment_order.py#L172 => ISO20022 XML generation is hard-coded to 2 decimals, so the current code doesn't support currencies that have a number of decimals different than 2. This is not a problem for SEPA credit transfer, but this is a real problem for international credit transfer that use non-SEPA ISO20022 files.

    https://github.com/OCA/bank-payment/blob/17.0/account_payment_order/models/account_journal.py#L10  => this code adds 2 fields "inbound_payment_order_only" and "outbound_payment_order_only" that are used nowhere ! It's just "dead code" !

     

    --

    Alexis de Lattre

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Raphaël Valyi
    Founder and consultant

    by Raphaël Akretion - 01:05 - 27 Mar 2025
  • RE: The future of oca/bank-payment

    What about organising a 2-3 days code sprint in the short term with the key OCA contributors for the bank-payment repo to align our ideas via face-to-face meetings.

    I am worried about ending up with two forks of these modules which would weaken our combined strength in this area.

    I don’t think we can afford waiting on the October code sprint to sort this one out.

    I am prepared to travel to France, Spain, ... if it can help to move forward on this.

     

    Regards,

    Luc

     

    From: Alexis de Lattre <notifications@odoo-community.org>
    Sent: Thursday, 27 March 2025 11:37
    To: Contributors <contributors@odoo-community.org>
    Subject: Re: The future of oca/bank-payment

     

     

     

    Le mer. 26 mars 2025 à 18:58, Pedro M. Baeza <notifications@odoo-community.org> a écrit :

    >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.

     

    I agree with most of your critics on commit history, single PR vs 1 PR per change, etc. I'm not the "perfect contributor".

     

    But I'm very surprised about your critics on the way I made the "revolution" in OCA/bank-payment v9. Do you really think I could have made the revolution in v9 with the rule "1 PR per change" ? I made so many datamodel changes in v9 that, with this rule, I would have had to make 20 PRs. Is it possible to do a datamodel revolution across 20 PRs ? When I made this work during the Sorrento code sprint, I had 7 or 8 iterations on the new datamodel before finding the "best" datamodel, which is still in use today. Could you imagine 7 or 8 datamodel iterations across 20 PRs ?

     

    My opinion is : the rule "one PR per change" doesn't work when you need to make big changes. This is what happened in v9 ; this is what needs to be done now.

    In my v16 "revolution" PR (https://github.com/OCA/bank-payment/pull/1174), I made 33 changes. So I would have had to make 33 PRs. Given the time and effort needed to make a 1 OCA PR, the consequence is that I wouldn't start such a big work because of the lack of time and energy. But this big cleanup/refactoring/improvements was really needed, so I decided to invest the time to do it, with the same spirit that when I made the revolution in OCA/bank-payment for v9 during the Sorrento code sprint : do the big cleanup/refactoring/improvements with little considerations for the question "will it be accepted/merge in OCA" but focus on "what's best for the quality of the code of OCA/bank-payment".

     

    > About the Payment Mode, In my view it does bring value, in terms of compatibility and interoperability with standard Odoo, as well as ergonomics

     

    There'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.

     

    These features are present in my module account_payment_base_oca, cf :

    cf fields "report_description", "show_bank_account" and "show_bank_account_chars".

     

    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.

     

    In my implementation in PR #1401, you CAN have a generic payment mode called "SEPA DD" with 5 bank accounts (journals) :

    1) Odoo auto-generate 5 account.payment.method.line ; they have "selectable=False" by default.

    2) you manually create a 6th account.payment.method.line with :

    - selectable=True

    - bank_account_link = "variable"

    - variable_journal_ids : M2M that points to the 5 bank journals

    - journal_id = False

    (company_id is defined as related=journal_id.company_id in the account module ; account_payment_base_oca changes that to a computed field, so have company_id set to self.env.company when journal_id=False)

    The native 3 M2O "Payment Mode" fields (2 on res.partner and 1 on invoices) are updated to filter on selectable=True.

     

    I'm the one who introduced bank_account_link=variable on payment mode during the Sorrento code sprint on OCA/bank-payment v9. Don't count on me to remove this feature !!!

     

    > About the migration effort, yes, there is some

     

    There'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...

     

    The why of this change is pretty simple : adopt the native datamodel of Odoo on payment mode (and keep the great features we have in OCA/bank-payment since v9, including bank_account_link=variable). In v18, there are 3 M2O fields that point to account.payment.method.line (2 on res.partner, 1 on invoice).

     

    I stay in my position of keeping current modules, which are not old, are stable and with no need of changing that.

     

    Just a few code example of why I initiated this big cleanup in OCA/bank-payment v16 that I now propose in v18. Most of this dirty code has been written by me back in v5, so I have no problem to critize it:

    https://github.com/OCA/bank-payment/blob/17.0/account_banking_sepa_credit_transfer/models/account_payment_order.py#L172 => ISO20022 XML generation is hard-coded to 2 decimals, so the current code doesn't support currencies that have a number of decimals different than 2. This is not a problem for SEPA credit transfer, but this is a real problem for international credit transfer that use non-SEPA ISO20022 files.

    https://github.com/OCA/bank-payment/blob/17.0/account_payment_order/models/account_journal.py#L10  => this code adds 2 fields "inbound_payment_order_only" and "outbound_payment_order_only" that are used nowhere ! It's just "dead code" !

     

    --

    Alexis de Lattre

    by Luc De Meyer. - 12:16 - 27 Mar 2025
  • Re: Peppol 2026 Belgium
    Hi Tom,
    There are some modules in https://github.com/oca/edi to generate invoices in the correct format. But I think there is nothing to send the invoices through the Peppol Network.

    Kr,
    F.

    Le jeu. 27 mars 2025 à 11:38, Tom Blauwendraat <notifications@odoo-community.org> a écrit :

    I did this at some point, would it help? This is about generating PEPPOL compatible invoices.

    On 3/27/25 11:12, François Wyaime wrote:
    Hello,

    Does OCA have any plans to comply with the PEPPOL 2026 requirements in Belgium?

    We have customers on versions 11.0, 13.0, 15.0, and 16.0, and we cannot migrate all of them before 2026.

    Kind regards,

    François WYAIME
    Odoo Expert @ ABAKUS IT-SOLUTIONS

    _______________________________________________
    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 franz.wyaime - 12:11 - 27 Mar 2025
  • Re: Peppol 2026 Belgium

    I did this at some point, would it help? This is about generating PEPPOL compatible invoices.

    On 3/27/25 11:12, François Wyaime wrote:
    Hello,

    Does OCA have any plans to comply with the PEPPOL 2026 requirements in Belgium?

    We have customers on versions 11.0, 13.0, 15.0, and 16.0, and we cannot migrate all of them before 2026.

    Kind regards,

    François WYAIME
    Odoo Expert @ ABAKUS IT-SOLUTIONS

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Tom Blauwendraat - 11:36 - 27 Mar 2025
  • Re: The future of oca/bank-payment


    Le mer. 26 mars 2025 à 18:58, Pedro M. Baeza <notifications@odoo-community.org> a écrit :
    >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.

    I agree with most of your critics on commit history, single PR vs 1 PR per change, etc. I'm not the "perfect contributor".

    But I'm very surprised about your critics on the way I made the "revolution" in OCA/bank-payment v9. Do you really think I could have made the revolution in v9 with the rule "1 PR per change" ? I made so many datamodel changes in v9 that, with this rule, I would have had to make 20 PRs. Is it possible to do a datamodel revolution across 20 PRs ? When I made this work during the Sorrento code sprint, I had 7 or 8 iterations on the new datamodel before finding the "best" datamodel, which is still in use today. Could you imagine 7 or 8 datamodel iterations across 20 PRs ?

    My opinion is : the rule "one PR per change" doesn't work when you need to make big changes. This is what happened in v9 ; this is what needs to be done now.
    In my v16 "revolution" PR (https://github.com/OCA/bank-payment/pull/1174), I made 33 changes. So I would have had to make 33 PRs. Given the time and effort needed to make a 1 OCA PR, the consequence is that I wouldn't start such a big work because of the lack of time and energy. But this big cleanup/refactoring/improvements was really needed, so I decided to invest the time to do it, with the same spirit that when I made the revolution in OCA/bank-payment for v9 during the Sorrento code sprint : do the big cleanup/refactoring/improvements with little considerations for the question "will it be accepted/merge in OCA" but focus on "what's best for the quality of the code of OCA/bank-payment".
     
    > About the Payment Mode, In my view it does bring value, in terms of compatibility and interoperability with standard Odoo, as well as ergonomics

    There'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.

    These features are present in my module account_payment_base_oca, cf :
    cf fields "report_description", "show_bank_account" and "show_bank_account_chars".
     
    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.

    In my implementation in PR #1401, you CAN have a generic payment mode called "SEPA DD" with 5 bank accounts (journals) :
    1) Odoo auto-generate 5 account.payment.method.line ; they have "selectable=False" by default.
    2) you manually create a 6th account.payment.method.line with :
    - selectable=True
    - bank_account_link = "variable"
    - variable_journal_ids : M2M that points to the 5 bank journals
    - journal_id = False
    (company_id is defined as related=journal_id.company_id in the account module ; account_payment_base_oca changes that to a computed field, so have company_id set to self.env.company when journal_id=False)
    The native 3 M2O "Payment Mode" fields (2 on res.partner and 1 on invoices) are updated to filter on selectable=True.

    I'm the one who introduced bank_account_link=variable on payment mode during the Sorrento code sprint on OCA/bank-payment v9. Don't count on me to remove this feature !!!
     
    > About the migration effort, yes, there is some

    There'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...

    The why of this change is pretty simple : adopt the native datamodel of Odoo on payment mode (and keep the great features we have in OCA/bank-payment since v9, including bank_account_link=variable). In v18, there are 3 M2O fields that point to account.payment.method.line (2 on res.partner, 1 on invoice).
     
    I stay in my position of keeping current modules, which are not old, are stable and with no need of changing that.

    Just a few code example of why I initiated this big cleanup in OCA/bank-payment v16 that I now propose in v18. Most of this dirty code has been written by me back in v5, so I have no problem to critize it:
    https://github.com/OCA/bank-payment/blob/17.0/account_banking_sepa_credit_transfer/models/account_payment_order.py#L172 => ISO20022 XML generation is hard-coded to 2 decimals, so the current code doesn't support currencies that have a number of decimals different than 2. This is not a problem for SEPA credit transfer, but this is a real problem for international credit transfer that use non-SEPA ISO20022 files.
    https://github.com/OCA/bank-payment/blob/17.0/account_payment_order/models/account_journal.py#L10  => this code adds 2 fields "inbound_payment_order_only" and "outbound_payment_order_only" that are used nowhere ! It's just "dead code" !

    --
    Alexis de Lattre
    by Alexis de Lattre - 11:36 - 27 Mar 2025
  • Peppol 2026 Belgium
    Hello,

    Does OCA have any plans to comply with the PEPPOL 2026 requirements in Belgium?

    We have customers on versions 11.0, 13.0, 15.0, and 16.0, and we cannot migrate all of them before 2026.

    Kind regards,

    François WYAIME
    Odoo Expert @ ABAKUS IT-SOLUTIONS
    by franz.wyaime - 11:11 - 27 Mar 2025
  • Re: Compatibility OCA OCB + OpenUpgrade
    yes

    On Thu, Mar 27, 2025 at 2:36 PM Aboubacar TRAORE <notifications@odoo-community.org> wrote:
    Hello everybody,

    I want to know if it is possible to use OpenUpgrade with OCB. For example, if I use OCB v16 and want to update to OCB v17.

    Thanks.

    _______________________________________________
    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 - 03:55 - 27 Mar 2025
  • Compatibility OCA OCB + OpenUpgrade
    Hello everybody,

    I want to know if it is possible to use OpenUpgrade with OCB. For example, if I use OCB v16 and want to update to OCB v17.

    Thanks.
    by Aboubacar TRAORE - 02:36 - 27 Mar 2025
  • Re: Work centers planning gantt chart and other planning tools
    Hi Samuel,
    That’s a great use case. We actually developed a planning tool for HR resource management that might serve as inspiration for your client's manufacturing planning needs. You can check it out here:
    https://github.com/OCA/resource/pull/5

    It uses the web_timeline module (https://github.com/OCA/web/tree/17.0/web_timeline) to provide a Gantt-style view for scheduling personnel. While it’s designed for HR purposes, the same structure could potentially be adapted to visualize work center availability and manufacturing capacity.

    As far as I know, a dedicated Gantt for manufacturing planning in CE doesn't currently exist, but this could be a solid starting point if you're considering a custom solution. Happy to chat further if you'd like help shaping that idea.

    Best,

    On Wed, Mar 26, 2025 at 5:28 PM Samuel Macias Oropeza <notifications@odoo-community.org> wrote:
    Hello!

    We have a client who's working with v17 CE. Their main issue right now is planning and managing their manufacturing capacity, as in work center availability and determining how many machines they'd actually need to fulfill manufacturing demand. We showed them Enterprise's work center planning gantt chart, and they seemed to like it. With that in mind, could you recommend some alternatives as well as complimentary tools available for Community?

    Thank you!

    --

    SAMUEL MACIAS OROPEZA

    TECH LEAD

    smacias@opensourceintegrators.com

    P.O. BOX 940, HIGLEY, AZ 85236





    Security Notice: Don't be too quick to click!
    Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Binhex Logo
    Jorge Elena Poblet
    Founder & CEO
    Binhex
    j.elena@binhex.cloud
    Office (Spain) : +34 622 40 08 08
    Office (USA): +1 561 403 4406
    Offices:
    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
    LinkedIn Twitter Facebook YouTube
    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
    by Jorge Elena Poblet - 11:06 - 26 Mar 2025
  • Work centers planning gantt chart and other planning tools
    Hello!

    We have a client who's working with v17 CE. Their main issue right now is planning and managing their manufacturing capacity, as in work center availability and determining how many machines they'd actually need to fulfill manufacturing demand. We showed them Enterprise's work center planning gantt chart, and they seemed to like it. With that in mind, could you recommend some alternatives as well as complimentary tools available for Community?

    Thank you!

    --

    SAMUEL MACIAS OROPEZA

    TECH LEAD

    smacias@opensourceintegrators.com

    P.O. BOX 940, HIGLEY, AZ 85236





    Security Notice: Don't be too quick to click!
    Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.
    by Samuel Macias Oropeza - 10:26 - 26 Mar 2025
  • 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 ergonomics

    There'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 some

    There'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 Alomar
    CEO & 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
  • Re: The future of oca/bank-payment
    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 ergonomics

    There'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 some

    There'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 Alomar
    CEO & Founder

    by Enric Tobella Alomar - 07:30 - 26 Mar 2025
  • Re: The future of oca/bank-payment
    >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 ergonomics

    There'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 some

    There'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.
    by Pedro M. Baeza - 06:55 - 26 Mar 2025
  • Re: The future of oca/bank-payment
    Dear Enric,

    Le mer. 26 mars 2025 à 12:47, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :
    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.

    Did you test my v18 PR that adds the module account_payment_base_oca https://github.com/OCA/bank-payment/pull/1401 ?
    My goal was to use the native object account.payment.method.line (used in v18 as "payment mode" on partners and invoices) while keeping the feature "decide the bank to pay at the end in a simple way". And I managed to implement it without breaking the native behavior. It was important to keep this feature !
     
    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.

    With my implementation in PR 1401, we don't loose functionalities. It's important !
     
    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.

    I don't know about EE because I don't use EE. All I know is that Odoo SA added a "payment mode" on partners and invoices in v18 (at last !) using account.payment.method.line. I think that, as implemented in my PR 1401, we can adopt this new native "payment mode" and not loose functionalities.

    Alexis
    by Alexis de Lattre - 06:13 - 26 Mar 2025
  • Re: The future of oca/bank-payment
    > we can decide the bank to pay at the end in a simple way

    In the current version of Alexis's PR this is possible and works the same as before.

    > users will see one TRansference payment method for each journal

    If I understand your concern correctly, that also is solved, as we can mark which Payment Modes are selectable in the partner and invoice forms.

    > we will loose functionalities

    What do you think we will loose ? To me it works exactly as before.

    > It's not bringing value

    About the Payment Mode, In my view it does bring value, in terms of compatibility and interoperability with standard Odoo, as well as ergonomy, avoiding two fields and models with almost identical meaning.

    About the migration effort, yes, there is some, but we went through much worse. But on the other hand, hiding the upstream fields is also work to do, and I'm afraid that will create confusion and compatibility issues with standard modules.

    @pedro, 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.

    Also, folks, keep in mind this is not only about the Payment Mode, which I highlighted because it is the one that will require a bit of technical migration effort, but also about many many other improvements and cleanups described in the 16.0 PR (https://github.com/OCA/bank-payment/pull/1174#issue-1981603414).

    > If you want to go this way, you should start a new module set, with different names

    That is a possibility yes, but we would really prefer to reach an agreement, to avoid dispersing the efforts of the community.

    Best regards,

    -Stéphane


    by Stéphane Bidoul - 05:31 - 26 Mar 2025
  • Re: The future of oca/bank-payment
    I personally agree with Pedro and Enric's position. IMHO the changes would not bring much benefit and the impact is not worth it. Not only the loss of functionalities but also the change in the way users would need to work.

    I don't think it is much of a problem to simply hide the new fields (or highlight somehow the difference between them and the OCA ones).

    Regards

    El mié, 26 mar 2025 a las 12:48, Enric Tobella Alomar (<notifications@odoo-community.org>) escribió:
    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

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Jordi Masvidal Brun - 02:46 - 26 Mar 2025
  • 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
  • Re: The future of oca/bank-payment
    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.
    by Pedro M. Baeza - 12:26 - 26 Mar 2025
  • RE: The future of oca/bank-payment

    >>> 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.

     

    I support this approach, and indeed we’ll probably have to rework some parts after the merge.

     

    Luc De Meyer

     

    From: Stéphane Bidoul <notifications@odoo-community.org>
    Sent: Wednesday, 26 March 2025 11:47
    To: Contributors <contributors@odoo-community.org>
    Subject: 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 Luc De Meyer. - 12:21 - 26 Mar 2025
  • 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