Skip to Content

Contributors

  • RE: Complete Visitors List for Odoo Experience Exhibition 2025

    Hi,

    · Yes, I am Interested, send me exclusive Fee and More information

     

    Regards.

    Shamim

     

    From: Lisa Nancy <notifications@odoo-community.org>
    Sent: Tuesday, 24 June 2025 4:18 pm
    To: Contributors <contributors@odoo-community.org>
    Subject: Complete Visitors List for Odoo Experience Exhibition 2025

     


     

    Hi,

    How are you?

    Odoo Experience Exhibition 2025, a pre-registered 3,852 Attendee list is available! to fulfil your promotional efforts.
    Date: 18 - 20 Sep 2025

    Venue: Brussels Expo - Exhibition Center, Brussels, Belgium


    Could you let me know if you want to receive the Attendee List with the Exclusive fee?


    List Includes: - Industry Type, Company_Name, Contact_Name, First_Name, Middle_Name, Last_Name, Titles, Address, City, State, ZIP Code, Phone_Number, Country and Business Type etc.

    Kindly describes your response:

    · Yes, I am Interested, send me exclusive Fee and More information
    · OPT-OUT

     

     

     

    Best regards,

    Lisa Nancy


    by Muhammad Shamim Ahmed - 01:35 - 24 Jun 2025
  • Complete Visitors List for Odoo Experience Exhibition 2025

     

    Hi,

    How are you?

    Odoo Experience Exhibition 2025, a pre-registered 3,852 Attendee list is available! to fulfil your promotional efforts.
    Date: 18 - 20 Sep 2025

    Venue: Brussels Expo - Exhibition Center, Brussels, Belgium


    Could you let me know if you want to receive the Attendee List with the Exclusive fee?


    List Includes: - Industry Type, Company_NameContact_NameFirst_NameMiddle_NameLast_Name, Titles, Address, City, State, ZIP Code, Phone_Number, Country and Business Type etc.

    Kindly describes your response:

    · Yes, I am Interested, send me exclusive Fee and More information
    · OPT-OUT




    Best regards,

    Lisa Nancy


    by "Lisa Nancy" <lisa.nancy.smartleads@gmail.com> - 01:16 - 24 Jun 2025
  • Complete Visitor Directory of Odoo Experience Exhibition 2025

    Hi,

    How are you?

    Odoo Experience Exhibition 2025, a pre-registered 7,794 Attendee list is available! to fulfil your promotional efforts.

    Date: 18 - 20 Sep 2025

    Venue: Brussels Expo - Exhibition Center, Brussels, Belgium


    Could you let me know if you want to receive the Attendee List with the Exclusive fee?

    List Includes: - Contact Information, Email Address, Company Title, URL/Website, Mobile Number, Title/Designation. Etc.***

    Kindly describes your response:

    · Yes, I am Interested, send me exclusive Fee and More information
    · OPT-OUT



    Thanks & Regards,
    Amy Roy

    by "Amy Roy" <amy.roy.leadboost@gmail.com> - 12:22 - 24 Jun 2025
  • Re: OCA/bank-payment-alternative
    Le sam. 21 juin 2025 à 11:47, Pedro M. Baeza <notifications@odoo-community.org> a écrit :
    and also not respecting such contributions attribution, which is one of the main principles of the open source.

    I agree with you, contribution attribution is very important in free software projects. If there is some code in OCA/bank-payment-alternative that doesn't respect contribution attribution please report it and we'll fix it.

    --
    Alexis de Lattre

    by Alexis de Lattre - 11:51 - 23 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    Hi Sergio
    Best regards

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le dim. 22 juin 2025, 22:06, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi Cyril,
    about external debian dependencies, like this one `libcairo2-dev`, I tried (see https://github.com/efatto/openupgrader/actions/runs/15818453346/job/44581882551 ), but this is not a binary.
    Sergio Corato


    Il giorno sab 21 giu 2025 alle ore 03:36 Cyril VINH-TUNG <notifications@odoo-community.org> ha scritto:
    Hi Sergio,

    It looks great !

    So you need an odoo instance to upgrade other instances, right ?
    I guess the goal is to let non technical persons to manage migrations... ?

    About external debian dependencies, I think you can manage that with _manifest__.py


    Best regards

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le ven. 20 juin 2025, 03:21, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Cyril VINH-TUNG - 07:50 - 23 Jun 2025
  • Re: usage bank-payment
    Hello Yves,

    I implemented this for a customer in v17.
    It would be nice having it as an OCA feature.

    Here is the code used to implement it:

    from odoo import _, models
    from odoo.exceptions import UserError
    class AccountPaymentRegister(models.TransientModel):
        _inherit = "account.payment.register"
        def _create_payments(self):
            # If there are multiple lines for the same move, we only use the first one
            # Example: 50% on Jun30 and 50% on Jul15,
            # the first payment should select the first 50% amount, and not the full amount
            # NOTE: only for SDD, should be extended to other payment methods? configurable?
            sdd_method = self.env.ref("account_sepa_direct_debit.payment_method_sdd")
            if self.payment_method_line_id.payment_method_id == sdd_method:
                original_method = self.payment_method_line_id
                # A SDD batch should be able to include multiple due dates
                # previous to the requested payment date
                dt = self.payment_date
                self.line_ids = self.line_ids.filtered(lambda x: x.date_maturity <= dt)
                if not self.line_ids:
                    raise UserError(_("No invoice matches the SDD payment date selected."))
                # For some reason, the payment method is reset at this point :-P
                self.payment_method_line_id = original_method
            return super()._create_payments()


    On 14/02/2025 10:32, Yves Goldberg wrote:
    Hi,

    Having an invoice
    with payment mode/method "[sepa_direct_debit] SEPA Direct Debit for customers (inbound)" 

    with payment condition to pay in 3 times:
    1# mensualités de 30,00 € le 14/02/2025
    2# mensualités de 30,00 € le 15/02/2025
    3# mensualités de 40,00 € le 16/02/2025

    How may I automatically add the due amount to a mandate? Based on the above example, I would like to have a payment with amount 30,00 added on Feb 14th mandate and another 30,00 on another mandate with date Feb 15 etc.

    Maybe account_payment_order module can partially help. Any existing module could further help ?
    Thank you.





     --
    Yves Goldberg
    --


    --
    DANIEL REIS
    MANAGING PARTNER

    >> Schedule time on my calendar.
    M: +351 919 991 307
    E: dreis@OpenSourceIntegrators.com
    A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

    [Logo OpenSourceIntegrators.com]


    by Daniel Reis - 12:50 - 23 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    (I added extra debian packages in `test.yml` file, thanks for the hint)

    Anyway, this module could be used to automate the tests for the openupgrade scripts, AFAIK they are not done until now.

    Sergio Corato


    Il giorno lun 23 giu 2025 alle ore 10:02 Sergio Corato <sergiocorato@gmail.com> ha scritto:
    Hi Cyril,
    about external debian dependencies, like this one `libcairo2-dev`, I tried (see https://github.com/efatto/openupgrader/actions/runs/15818453346/job/44581882551 ), but this is not a binary.
    Sergio Corato


    Il giorno sab 21 giu 2025 alle ore 03:36 Cyril VINH-TUNG <notifications@odoo-community.org> ha scritto:
    Hi Sergio,

    It looks great !

    So you need an odoo instance to upgrade other instances, right ?
    I guess the goal is to let non technical persons to manage migrations... ?

    About external debian dependencies, I think you can manage that with _manifest__.py


    Best regards

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le ven. 20 juin 2025, 03:21, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Sergio Corato - 11:45 - 23 Jun 2025
  • Re: OCA/bank-payment-alternative
    Indeed, that was another of the reasons explained in the two online meetings, and some attendees minimized its impact, but we have clear examples like the one you are mentioning. For the reference: https://github.com/OCA/connector-ecommerce/pull/83#pullrequestreview-2949188707

    Regards.

    by Pedro M. Baeza - 10:46 - 23 Jun 2025
  • Re: OCA/bank-payment-alternative

    The worst part of all this is that it creates incompatibilities between modules. This means that if you have a module that depends on the new fork, you won't be able to use modules that rely on the traditional ones.

    For example, if this PR https://github.com/OCA/connector-ecommerce/pull/83 is migrated with the new dependency on account_payment_base_oca_sale, then I can no longer use any module that depends on account_payment..., making entire sets of modules incompatible with each other.

    This is a disaster when trying to migrate projects, as it forces you to give up certain modules.


    El dom, 22 jun 2025 a las 17:22, Xavier Brochard (<notifications@odoo-community.org>) escribió:
    Le samedi 21 juin 2025, 11:47:12 CEST Pedro M. Baeza a écrit :
    
    
    > There are a lot of people that strongly disagrees with the creation of this
    
    
    > fork, that is something with no precedence in OCA, and offered to merge the
    
    
    > improvements into the main branch, with the only exception of the point 1
    
    
    > "Adoption of the native object account.payment.method.line as "Payment
    
    
    > Method" (replaces the OCA object account.payment.mode)", postponing the
    
    
    > decision to version 19 to check with Odoo SA if they expand the usage of
    
    
    > that fields, because the so called "native model" is not for that purpose,
    
    
    > and the changes that have been made for adopting it as so is deforming even
    
    
    > more the standard, but *it was miserable ignored*. You can see in the same
    
    
    > thread the technical reasons to not use such data model, but also the
    
    
    > ethical and practical ones, as the fork started on version 16, ignoring all
    
    
    > the improvements and bugfixes done meanwhile in 17 (or now announced in
    
    
    > this thread as new things, while they were there for a long time thanks to
    
    
    > multiple contributors), and also not respecting such contributions
    
    
    > attribution, which is one of the main principles of the open source. I'm
    
    
    > *deeply disappointed* by both the attitude of the people involved,
    
    
    > including some board members, and the arbitration done by the OCA itself,
    
    
    > and I'm personally commiting to *bring the improvements* mentioned here
    
    
    > that are still pending (obviously, respecting the attribution) to the *main
    
    
    > OCA/bank-payment branch*, so please take all of this into account when you
    
    
    > decide which one to use. Regards.
    
    + + + + + +
    
    
    
    Xavier
    

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


    by Javier Colmenero Fernández - 10:15 - 23 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    Hi Cyril,
    about external debian dependencies, like this one `libcairo2-dev`, I tried (see https://github.com/efatto/openupgrader/actions/runs/15818453346/job/44581882551 ), but this is not a binary.
    Sergio Corato


    Il giorno sab 21 giu 2025 alle ore 03:36 Cyril VINH-TUNG <notifications@odoo-community.org> ha scritto:
    Hi Sergio,

    It looks great !

    So you need an odoo instance to upgrade other instances, right ?
    I guess the goal is to let non technical persons to manage migrations... ?

    About external debian dependencies, I think you can manage that with _manifest__.py


    Best regards

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le ven. 20 juin 2025, 03:21, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Sergio Corato - 10:06 - 23 Jun 2025
  • Re: Membership
    Hello,

    If your name doesn't appear on the OCA member list, it might be linked to the survey about sharing your data, that you need to fill in.

    Rebecca sends this information in the email confirming your membership:

    To be listed on the website as a member of the OCA:

    1. Complete this survey: https://odoo-community.org/survey/start/ec93270c-f080-4ef0-821d-f5ec4531f371

    2. You'll also need to fill out an ICLA (if not done so previously) to be listed: https://odoo-community.org/about/cla



    Virginie Dewulf
    Executive Director
    +32 477 64 17 20


    Le ven. 6 juin 2025 à 13:45, Amir Akbari <notifications@odoo-community.org> a écrit :

    Hi all,

    I registered in community as a member and signed CLA but my name and details do not available in OCA member list.

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


    by Virginie Dewulf - 08:26 - 23 Jun 2025
  • Re: OCA/bank-payment-alternative
    Le samedi 21 juin 2025, 11:47:12 CEST Pedro M. Baeza a écrit :
    
    > There are a lot of people that strongly disagrees with the creation of this
    
    > fork, that is something with no precedence in OCA, and offered to merge the
    
    > improvements into the main branch, with the only exception of the point 1
    
    > "Adoption of the native object account.payment.method.line as "Payment
    
    > Method" (replaces the OCA object account.payment.mode)", postponing the
    
    > decision to version 19 to check with Odoo SA if they expand the usage of
    
    > that fields, because the so called "native model" is not for that purpose,
    
    > and the changes that have been made for adopting it as so is deforming even
    
    > more the standard, but *it was miserable ignored*. You can see in the same
    
    > thread the technical reasons to not use such data model, but also the
    
    > ethical and practical ones, as the fork started on version 16, ignoring all
    
    > the improvements and bugfixes done meanwhile in 17 (or now announced in
    
    > this thread as new things, while they were there for a long time thanks to
    
    > multiple contributors), and also not respecting such contributions
    
    > attribution, which is one of the main principles of the open source. I'm
    
    > *deeply disappointed* by both the attitude of the people involved,
    
    > including some board members, and the arbitration done by the OCA itself,
    
    > and I'm personally commiting to *bring the improvements* mentioned here
    
    > that are still pending (obviously, respecting the attribution) to the *main
    
    > OCA/bank-payment branch*, so please take all of this into account when you
    
    > decide which one to use. Regards.
    
    + + + + + +
    
    
    
    Xavier
    

    by xavier - 05:20 - 22 Jun 2025
  • Re: OCA/bank-payment-alternative
    There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.

    I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.

    Regards.

    by Pedro M. Baeza - 11:45 - 21 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    Oh I see
    Maybe I suggest you to add this in the readme
    Bravo


    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le ven. 20 juin 2025, 19:12, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi Cyril,

    Thanks!

    No, it migrates itself!

    It's both for non technical people and for technical people who want to simplify the process, the next step is to include EE in the migration.

    It's also to give the final user the freedom to do the migration be himself, as Odoo is actually criticized to be partially a lock-in software for the hard migration process.

    Sergio Corato 

    Il sab 21 giu 2025, 03:36 Cyril VINH-TUNG <notifications@odoo-community.org> ha scritto:
    Hi Sergio,

    It looks great !

    So you need an odoo instance to upgrade other instances, right ?
    I guess the goal is to let non technical persons to manage migrations... ?

    About external debian dependencies, I think you can manage that with _manifest__.py


    Best regards

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le ven. 20 juin 2025, 03:21, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Cyril VINH-TUNG - 07:26 - 21 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    Hi Cyril,

    Thanks!

    No, it migrates itself!

    It's both for non technical people and for technical people who want to simplify the process, the next step is to include EE in the migration.

    It's also to give the final user the freedom to do the migration be himself, as Odoo is actually criticized to be partially a lock-in software for the hard migration process.

    Sergio Corato 

    Il sab 21 giu 2025, 03:36 Cyril VINH-TUNG <notifications@odoo-community.org> ha scritto:
    Hi Sergio,

    It looks great !

    So you need an odoo instance to upgrade other instances, right ?
    I guess the goal is to let non technical persons to manage migrations... ?

    About external debian dependencies, I think you can manage that with _manifest__.py


    Best regards

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le ven. 20 juin 2025, 03:21, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Sergio Corato - 07:11 - 21 Jun 2025
  • OCA/bank-payment-alternative
    Dear OCA friends,

    On March 26th 2025, Stéphane Bidoul sent an email on this mailing-list with the subject "The future of OCA/bank-payment". If you missed it, you can find it in the archives:

    After some long discussion/debate, it was decided to let the chance for an alternative OCA banking project that would use the native payment method object of the "account" module (account.payment.method.line). This project is named OCA/bank-payment-alternative and you can find it here: 

    We had to change the module names in OCA/bank-payment-alternative. Here are the new names that were chosen :

    OCA/bank-payment OCA/bank-payment-alternative
    account_payment_order account_payment_batch_oca
    account_banking_pain_base account_payment_sepa_base
    account_banking_sepa_credit_transfer account_payment_sepa_credit_transfer
    account_banking_mandate account_payment_mandate
    account_banking_mandate_sale account_payment_mandate_sale
    account_banking_sepa_direct_debit account_payment_sepa_direct_debit
    account_payment_mode native + account_payment_base_oca
    account_payment_partner native
    account_payment_sale account_payment_base_oca_sale

    Here are the main changes in the datamodel introduced by OCA/bank-payment-alternative :
    1. Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)
    2. Introduction of account.payment.lot, which represent the Payments Lots (corresponds to the PmtInf i.e. Payment Information block of the SEPA XML files). If your bank groups the debits/credits on your bank statement for the payments, a lot matches one debit or credit payment line on your bank account. This object is generated upon confirmation of the payment order and is used in the generation of the XML (and should soon be used in the bank statement reconcile interface)
    3. the datamodel of the mandate has been simplified: the field "format" also has the information of the "scheme" field, so "format" now has 3 possible values : basic, sepa_core or sepa_b2b. The field "scheme" has been removed. The field "type" has 2 possible values: recurrent or oneoff (instead of 3 possible values : generic, recurrent or oneoff). The field "recurrent_sequence_type" has been removed because we don't need to handle the "first" vs "recurring" sequence any more : since November 2016, "the requirement to use the sequence type ‘First’ in a first of a recurrent series of Collections is no longer mandatory" according to the European Payment Council (EPC), cf SDD Core Rulebook. The "final" sequence is now supported by the state field which has a new "final" state that can be activated via a button. The field "partner_id" is NOT a related field of partner_bank_id any more, which solves the bug "account_banking_mandate: Change in the filtering behavior of the "Bank Account" field" https://github.com/OCA/bank-payment/issues/1473 With all these simplifications on the mandate datamodel, the form view and list view of mandates are more user-friendly.
    4. The field generated_user_id has been removed from account.payment.order (the info is present in the chatter)
    5. On account.payment.method, the boolean field "payment_order_only" has been renamed to "payment_order_ok" (for consistency)
    6. The boolean field "convert_to_ascii" has been removed from account.payment.method : we consider that this option should be always on (there is a hook in the code in case you need to disable it).
    Here is a summary of the new features and improvements by order of importance :
    • Take into account the boolean field "allow_out_payment" of res.partner.bank on payment orders : when you try to confirm a payment order that has bank accounts on payment lines with allow_out_payment = False, you will get a blocking error message. The affected payment lines will be shown in red and you will have a smart button that gives access to the bank accounts that are not allowed to send money to. To enable "allow_out_payment", you need to be part of a specific group "Validate bank accounts" (XMLID account.group_validate_bank_account). As a consequence, we don't inherit the native ACL of res.partner.bank that give full rights to partner manager any more : the security is handled by "allow_out_payment".
    • by default, there is a sequence of payment orders and another sequence for debit orders. It is possible to configure a specific sequence for a payment mode.
    • add support for "Regulatory Reporting" in the SEPA XML structure (tag RgltryRptg). Needed in some countries for international non-SEPA credit transfers.
    • replace unstructured address by structured address in SEPA XML file (mandatory starting 11/2025)
    • add support for pain.008.01.08 (SDD) and pain.001.001.09 (SCT), which are now the recommended versions of the EPC
    • easier download of the banking file after generation
    • add field acc_number_scrambled on res.partner.bank for easy and direct use of scrambled account number
    • search on partner_id from account.payment.order
    • support currencies with decimal_places != 2 in ISO20022 XML file generation
    • on mandates, fields format, type, signature date and partner are not editable any more when state != draft
    • remove support for pain.001.001.02/04/05 (SCT) and pain.008.01.03/04 (SDD) which have never been selected by the EPC, to simplify the code
    • stop using safe_eval() in XML generation
    • replace all @api.onchange by computed fields
    • add sql unicity constraint on payment order number per company
    Many bugs have been fixed:
    You can have a complete list of the changes and bug fixes of OCA/bank-payment-alternative on these 2 issues:

    But, for me, the most important of OCA/bank-payment-alternative is the investment made on the quality of the code, not only on the SEPA XML generation but also on the lower-level modules.

    OCA/bank-payment-alternative will continue to focus on code quality and innovation (which involves datamodel changes when needed).
    Now that the modules are merged, the next priority should be on providing migration scripts for v17 to v18 migration.

    So, for v18, you now have the choice between OCA/bank-payment and OCA/bank-payment-alternative. Happy hacking !

    --
    Alexis de Lattre
    Akretion France - 27 rue Henri Rolland - 69100 Villeurbanne - France
    Mail : alexis.delattre@akretion.com


    by Alexis de Lattre - 03:34 - 21 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    Hi Sergio,

    It looks great !

    So you need an odoo instance to upgrade other instances, right ?
    I guess the goal is to let non technical persons to manage migrations... ?

    About external debian dependencies, I think you can manage that with _manifest__.py


    Best regards

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com

    Le ven. 20 juin 2025, 03:21, Sergio Corato <notifications@odoo-community.org> a écrit :
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

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


    by Cyril VINH-TUNG - 03:34 - 21 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    I explained it better in the README:

    This module automates OpenUpgrade to do the migration process from Odoo itself in an easy way.

    Sergio Corato


    Il giorno ven 20 giu 2025 alle ore 15:46 Sergio Corato <sergiocorato@gmail.com> ha scritto:
    I use openupgrade, inside this module in an automated way.
    Sergio Corato


    Il giorno ven 20 giu 2025 alle ore 15:36 Jordi Ballester Alomar <notifications@odoo-community.org> ha scritto:
    Why not use openupgrade?

    Jordi Ballester Alomar 
    CEO & Founder, ForgeFlow
    Spain: (+34) 629530707 | USA: (+1) 646 980 4659 | Denmark: (+45) 78 78 21 89 - Ext. 101


          



    The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

    El vie, 20 jun 2025, 15:22, Sergio Corato <notifications@odoo-community.org> escribió:
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Sergio Corato - 03:34 - 21 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    I use openupgrade, inside this module in an automated way.
    Sergio Corato


    Il giorno ven 20 giu 2025 alle ore 15:36 Jordi Ballester Alomar <notifications@odoo-community.org> ha scritto:
    Why not use openupgrade?

    Jordi Ballester Alomar 
    CEO & Founder, ForgeFlow
    Spain: (+34) 629530707 | USA: (+1) 646 980 4659 | Denmark: (+45) 78 78 21 89 - Ext. 101


          



    The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

    El vie, 20 jun 2025, 15:22, Sergio Corato <notifications@odoo-community.org> escribió:
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Sergio Corato - 03:51 - 20 Jun 2025
  • Re: New module to upgrade Odoo from Odoo itself
    Why not use openupgrade?

    Jordi Ballester Alomar 
    CEO & Founder, ForgeFlow
    Spain: (+34) 629530707 | USA: (+1) 646 980 4659 | Denmark: (+45) 78 78 21 89 - Ext. 101


          



    The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

    El vie, 20 jun 2025, 15:22, Sergio Corato <notifications@odoo-community.org> escribió:
    Hi all!

    I put in a module for Odoo the methods I use to migrate Odoo from v. 7.0 onwards, to migrate to one or more upper versions from inside Odoo itself.

    It works by creating a series of virtualenv, one for each version to migrate, and making some customizable fixes on the process.

    The readme of the module is here https://github.com/efatto/openupgrader/blob/14.0/openupgrader/README.rst and I would like to contribute it to OCA if possible.

    Sergio Corato

    Notes:
    1. The methods need a robust refactoring - I've started to write them when I barely knew Python - but they have worked for several years, migrating more versions like from 8.0 to 12.0.
    2.  This module needs some extra debian package to work in the default OCA container, so it's impossible to make the tests work now.

    Sergio Corato

    _______________________________________________
    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 Ballester Alomar - 03:36 - 20 Jun 2025