Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: OCA/bank-payment-alternative

Archives

Contributors

Re: OCA/bank-payment-alternative

Re: OCA/bank-payment-alternative

Re: OCA/bank-payment-alternative

Alexis,

You removed all history from 17 and part of 16. Some of the fixes that you made were already done by other people.

I am just analyzing https://github.com/OCA/bank-payment-alternative/pull/5. The same might happen with all other modules of your alternative, but I don't have the energy or time to do it...

Just to start: you didn't rewrite the history. Commits will be lost on next migration (removing people attribution in the next migration, not now...)

We shared with you how to do it here in a non-blocking review (we didn't want to block your job): https://github.com/OCA/bank-payment-alternative/pull/5#pullrequestreview-2931804750

About removing people attribution: I will raise 2 small examples because it takes time to compare.

- https://github.com/OCA/bank-payment/commit/1d37132360fae0d8b6d3204e63007862f3325922 was lost. It improved how it was handled the tests but you ignored it...

Do you need more examples?

My recomendation would be: "check the history of branch 17"

El lun, 23 jun 2025 a las 23:52, Alexis de Lattre (<notifications@odoo-community.org>) escribió:
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

_______________________________________________
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:23 - 27 Jun 2025

Reference

  • 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