Saturday, April 11, 2026
3 changes · saas-18.4
Resolved issues and error corrections
Changing a contact's name no longer overwrites a bank account holder name when that holder name was customized. The holder name still follows the contact name when both previously matched, keeping default behavior while protecting manual edits.
Original PR description
**steps to reproduce:** 1. Create a contact 2. On the accounting tab, add one bank account 3. Change the name of the contact 4. The record's name updates automatically the field "Account Holder Name"…
**steps to reproduce:** 1. Create a contact 2. On the accounting tab, add one bank account 3. Change the name of the contact 4. The record's name updates automatically the field "Account Holder Name" **problem:** When changing a profile's name in the contacts app, the account holder name changes to be the same as the profile's name. **expected behaviour:** "Make the account holder name update if partner.name is changed ONLY if they were the same before the change. Otherwise keep the account holder name as is." - Referenced from the feature ticket: 5222712 That means if contact's name is the same as the account holder name, then any change to the contact's name, should as well update 'account holder name' accordingly, but if you changed the account holder name itself, then you change contact's name (if they're not the same) then the account holder name shouldn't be updated to match the contact's name. **cause:** The account holder name depends on `partner_id.name` https://github.com/odoo/odoo/blob/2394a9a7f0ece2d5a2185fa4e715d943fc044733/odoo/addons/base/models/res_bank.py#L104-L107 So whenever you change the contact's name, the account holder name changes accordingly. **Fix:** Upon creation, the account holder name is set to the partner name if no name is provided. Additionally, when the partner name changes, the account holder name is updated only if it previously matched the partnername; otherwise, it is left unchanged. **NOTE:** This is a backport of this PR: https://github.com/odoo/odoo/pull/233965 opw-5913464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258533 Forward-Port-Of: odoo/odoo#248886
This fixes a problem that blocked Croatian electronic credit notes from being sent to Mojeracun when the recipient had no bank account listed. It also corrects the credit note export format so the generated file is accepted, reducing failed submissions and manual follow-up.
Original PR description
**Steps to reproduce:** * Install `l10n_hr_edi` module. * Generate an invoice and validate it. * Generate a credit note from that invoice. * Without a recipient bank account, try to send the credit…
**Steps to reproduce:**
* Install `l10n_hr_edi` module.
* Generate an invoice and validate it.
* Generate a credit note from that invoice.
* Without a recipient bank account, try to send the credit note to Mojeracun.
**Observed behavior:**
* Two errors are raised before the XML is generated:
1. `AttributeError: 'NoneType' object has no attribute 'get'` in `_invoice_constraints_eracun_new` when checking for whitespace in the bank account number.
2. `ValueError: The following child node is not defined in the template: CreditNote/cac:BillingReference/cbc:IssueDate` during XML serialization.
**Cause:**
* issue 1 : https://github.com/odoo/odoo/commit/96cf6626d2b3e75637b908244cf2fa4da615c16b#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R81
* In the mentioned commit `_invoice_constraints_eracun_new`, `node.get('cac:PayeeFinancialAccount', {})` returns `None` instead of `{}` when the key exists but its value is explicitly set to `None` (which happens when no bank account is set). Chaining `.get()` on `None` raises `AttributeError`.
* issue 2 : https://github.com/odoo/odoo/commit/47ef0c2cb96be9fffdc4985255661807980839c6#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R146
* In the mentioned commit in `_ubl_add_billing_reference_nodes`, `cbc:IssueDate` was added as a direct child of `cac:BillingReference`. The UBL template only allows `cac:InvoiceDocumentReference` as a child of `BillingReference`, while `cbc:IssueDate` belongs inside `cac:InvoiceDocumentReference`.
**Fix:**
* Replace `.get('cac:PayeeFinancialAccount', {})` with `.get('cac:PayeeFinancialAccount')` to safely handle an explicitly `None` value before chaining further calls.
* Move `cbc:IssueDate` inside `cac:InvoiceDocumentReference` in the `BillingReference` node, matching the structure defined in `ubl_21_common.py`.
opw-6088424
Forward-Port-Of: odoo/odoo#258057This update resolves issues with the Fiskaly integration by refining retry logic and ensuring correct SCU usage. Specifically, it now only retries on critical server errors, preventing masking of important API responses. Additionally, the configuration of the cash register is now more robust, improving the connection between the local and Fiskaly systems.
Original PR description
- Retry only on server errors (5xx) instead of client errors (4xx) to avoid masking meaningful API responses with a confusing RetryError. - Reuse the existing active SCU when E_SCU_LIMIT_REACHED is returned, since Fiskaly only allows one active SCU per account. - Pass the pos.config id as metadata when creating a cash register on Fiskaly, making it easier to match Fiskaly register IDs back to their config when the local link is broken. - Hide the test mode toggle once the company is registered with Fiskaly (l10n_at_fiskaly_organization_id is set) to prevent mode changes after registration. opw-5958673 Forward-Port-Of: odoo/enterprise#113496