Friday, April 10, 2026
29 changes · saas-18.3
Resolved issues and error corrections
This update fixes a tax-related issue where invoices displayed multiple company names (like 'X, Y') when using a child contact. This ensured invoices comply with tax regulations by clearly identifying the correct recipient, preventing potential input tax deduction denials. The change updates the display of delivery addresses on invoices.
Original PR description
If two GmbH (Ltd.) names appear in the invoice address field (e.g., "Proveco GmbH, Test GmbH"), the invoice is problematic from a tax perspective, as two GmbH are considered separate legal entities, and it is not clearly identifiable who the actual recipient of the service is. Consequently, the tax office can refuse the input tax deduction if the invoice recipient is not clearly identifiable. Steps: - Create a company contact (X) and a delivery address (Y) - Create an invoice for X, delivery address will be Y - Open preview -> The delivery partner's display name is 'X, Y', it should be only 'Y' Fix: Adding a context key to the invoice document to conditionally display the parent contact name in the display_name Ticket [link](https://www.odoo.com/odoo/project.task/5900567) opw-5900567 Forward-Port-Of: odoo/odoo#258317 Forward-Port-Of: odoo/odoo#257652
This update fixes an issue where the product name displayed in purchase order lines would change when navigating between pages. The fix ensures the product name remains consistent across all purchase order lines, improving clarity and accuracy for users. It corrects a technical problem related to how data is fetched and displayed in the purchase order interface.
Original PR description
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase…
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase Order with the same vendor set as on the product. * Add the configured product to the *Purchase Order Lines*. * Add the same product again on a second line and save the order. * Activate debug mode * Go to the view:Form and add a limit to have only 1 POL per page * Return to your PO * Go to the second page **Observed behavior:** * The *product display name* in the purchase order lines is different on the second page compared to the first page. **Cause:** * On the first page, purchase order lines are fetched via a web_read on the purchase order. * On subsequent pages, lines are fetched via a web_read directly on the purchase order lines. * The client requests both name and product_id.display_name. product field context includes partner_id, causing product_id.display_name to be computed as the vendor name. * As both values resolve to the vendor name, the original product name is lost, leading to inconsistent display across pages. **Note:** A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36 * but its consequence it breaks the search using the vendor code/name in POL. * That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d **Fix:** * This ensures the product name is propagated correctly in the form view while preserving search by vendor code or name. --- opw-5170924 Forward-Port-Of: odoo/odoo#240515
This update corrects a reporting issue where employee leave balances incorrectly displayed outdated department information. The fix ensures that leave balances always reflect the employee's current department, resolving duplicate entries in reports and providing accurate data for payroll and HR analysis. This improvement enhances the reliability of our leave reporting functionality.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Time Off module. 2. Go to Time Off > Management > Allocations, create an allocation for an employee, and approve it. 3. Go to Reporting >…
Steps to reproduce: ------------------------- 1. Install the Time Off module. 2. Go to Time Off > Management > Allocations, create an allocation for an employee, and approve it. 3. Go to Reporting > Balance and apply the filter Department > Employee. 4. Change the employee’s department. 5. Create an allocation for the same employee and approve. 6. Apply the Department > Employee filter again. Observed behaviour: ---------------------------- After a department change: * Existing allocations keep the old department * New allocations use the new department As a result, duplicate employee entries appear in the report Cause: ---------- It is using [allocation.department_id.](https://github.com/odoo/odoo/blob/4c91eb3b2469cd04718005162b4572e9e3d07e72/addons/hr_holidays/report/hr_leave_employee_type_report.py#L62) Allocations store the department at creation time, which may differ from the employee’s current department, causing an incorrect report filtering. Solution: ------------ Fetch department_id from hr_employee instead of hr_leave_allocation in the hr_leave_employee_type_report and hr_leave_report. This ensures: * Leave balances always follow the employee’s current department * Correct aggregation when grouping by Department → Employee **NOTE:** Before this [commit](https://github.com/odoo-dev/odoo/commit/976e0f9a667f4573e73e33737425d370ec1e1452), the issue was resolved starting from version saas-18.4, as the balances were filtered using the employee's department (via `hr_version`). https://github.com/odoo/odoo/blob/104a33f093ca583c91db9705f087c73d8464c173/addons/hr_holidays/report/hr_leave_employee_type_report.py#L65-L74 related commit: https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759 Since `hr_version` is no longer used in the query, this issue needs to be addressed again and forward-ported to all versions up to master. Before: <img width="1238" height="857" alt="image" src="https://github.com/user-attachments/assets/15e1293b-dc50-4067-a12f-079c046c2074" /> After: <img width="1247" height="824" alt="image" src="https://github.com/user-attachments/assets/feea32de-0d9c-4eef-9ae5-639f4658560c" /> opw-5220577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243076
This update fixes an issue where sales invoice email notifications incorrectly displayed a zero amount and a missing record reference. The fix ensures that the correct invoice amount and record details are sent to the salesperson, improving the accuracy of email communications. This impacts sales order processing and reporting.
Original PR description
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue:…
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue: --- - In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00. Root cause: --- - Here at [1], the record name is False because the invoice is still in draft state. - In [18], _sync_invoice sets amount_currency = line.balance for new lines, but balance is precomputed as 0 before the INSERT because _compute_balance returns 0 for invoice lines. In [17] it read price_subtotal directly, which is always correct. - In 17.0 the same mail fires at the same moment, but _sync_invoice had already set balance = −295 and amount_currency = −295 from price_subtotal, so the email reads the correct 295.00. Solution: --- - Use record.display_name instead of record.name, as display_name is always present regardless of the record state. - Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices. [1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478 [18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610 [17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585 Before: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" /> After: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" /> opw-6023827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254862
This update fixes an issue where the Helpdesk return wizard incorrectly displayed receipt operations alongside delivery operations. The fix specifically excludes receipts from the wizard's domain, ensuring users only see eligible deliveries for returns. This improves the accuracy and usability of the return process.
Original PR description
Steps to reproduce: - 1. Create a Sale Order for a customer and fully process the delivery. 2. Create a Helpdesk ticket for that customer. 3. From the ticket, click the 'Return' button to open the wizard. 4. Select the sales order or open the 'Delivery to Return' dropdown. Issue: - The list of available pickings shows both receipts and deliveries operations. Fix: - The domain for the return wizard is updated to explicitly exclude receipts. Note: - This bug is present until saas-18.4. From 19.0 onward it is already fixed in this PR: https://github.com/odoo/enterprise/pull/90371 task-5075205 Forward-Port-Of: odoo/enterprise#95418
This update resolves a technical problem with the formatting of data within the marketing card module. Specifically, a malformed XML tag was causing errors. This fix ensures that marketing campaigns are processed correctly, preventing potential disruptions to email campaigns and data accuracy.
Original PR description
This commit fixes a malformed HTML/XML tag in CardCampaign. Note: before libxml2 v2.14.0, this issue was automagically cleaned up, but not anymore. Forward-Port-Of: odoo/odoo#258388
This update corrects a bug that prevented KPI cards (Billable Hours, etc.) from accurately reflecting timesheet data when global filters were applied. The issue stemmed from a hardcoded filter limiting data to a single user. Removing this restriction ensures KPI cards display correct data based on selected filters.
Original PR description
Steps to reproduce: - 1. Go to the dashboard app > Timesheets. 2. Apply any global filter. Issue: - The main KPI cards (Billable Hours, Non-billable Hours, Billable Rate) do not update correctly when any global filter is applied. Filtering by 'Employee' causes the cards to show zero. Other filters like 'Project' or 'Department' show incomplete and incorrect data, reflecting only the timesheets of a single hardcoded user. Cause: - The pivot tables (`pivot 5` and `pivot 6`) that source the data for the KPI cards contained a hardcoded domain `['user_id', '=', 2]`. This condition changes any selection made in the global filter and shows incorrect data. Fix: - The hardcoded `['user_id', '=', 2]` condition has been removed. task-4782213 Forward-Port-Of: odoo/odoo#258200 Forward-Port-Of: odoo/odoo#224810
This update fixes an issue related to how accounting data is handled for multiple companies within the Odoo system. Specifically, it ensures that company-specific information is correctly used when processing accounts for Danish businesses (l10n_dk). This improves the accuracy and reliability of financial reporting for businesses operating in Denmark.
Original PR description
Fixes https://github.com/odoo/odoo/pull/257623. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257852
This update resolves an issue where Chrome processes weren't completely shutting down, leading to potential disruptions in Odoo's operation. By ensuring all Chrome subprocesses are terminated, we prevent lingering connections and errors that could impact performance and stability. This is a critical fix to maintain a smooth user experience.
Original PR description
It's not clear when it started to happen (possibly forever), but apparently waiting for the main chrome process to terminate does not ensure all subprocesses are also terminated. Depending how long these subprocesses stick around, this can lead to: - remaining http or websocket requests - the inability to delete or re-creation of the user directory - possibly other confusing situations Update the chrome termination flow to make sure every subprocess is gone before proceeding to the next step. Kinda-sorta backport of #258062 Forward-Port-Of: odoo/odoo#258069
This update fixes an issue where archived warehouses were incorrectly included when creating quotations from Contacts. The change ensures that only active warehouses are considered, resolving a potential confusion for users and improving data accuracy. This was caused by a misconfiguration in how the system determines warehouse selection.
Original PR description
Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation. ## Steps to replicate: - Install Sales, CRM, and…
Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.
## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.
## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.
## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.
Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12
## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.
**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
def _get_default_warehouse_id(self):
# !!! Any change to the following search domain should probably
# be also applied in sale_stock/models/sale_order.py/_init_column.
return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717
opw-5999034
Forward-Port-Of: odoo/odoo#252166This update resolves an issue where importing invoices could cause a system crash due to excessive matching of purchase orders. The fix filters out purchase orders with empty vendor references, which were being incorrectly identified during the import process. This improves the stability and performance of the invoice import feature.
Original PR description
Description of the issue/feature this PR addresses:
A Peppol message contains a reference with a trailing comma.
```
<cac:OrderReference>
<cbc:ID> Uw bestelling,</cbc:ID>
</cac:OrderReference>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID> Uw bestelling,</cbc:ID>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
```
Current behavior before PR:
A MemoryError occurs in `_cron_peppol_get_new_documents` because the trailing comma leads to a fetching hundreds of thousands of purchase orders with domain `[('partner_ref', 'in', [('Uw bestelling', '')]`
Desired behavior after PR is merged:
Purchase orders are not matched by empty reference.
opw-6102641
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257851This update fixes a bug that prevented Peppol invoices from importing correctly. Specifically, changing a Peppol journal type to non-purchase caused import errors. This change ensures that Peppol invoices are processed reliably, avoiding disruptions in receiving and accounting.
Original PR description
Prevent changing a Peppol journal to a non-purchase type, to avoid import errors when receiving Peppol invoices. Step to reproduce: - Setup a company with Peppol - Change the Peppol reception journal type to non-purchase - Try to run Peppol cron to import invoice, it fails with "Cannot create a purchase document in a non purchase journal" opw-6071992 opw-6064502 Forward-Port-Of: odoo/odoo#258274 Forward-Port-Of: odoo/odoo#256823
This update significantly speeds up the process of retrieving sale order information linked to stock lots. Previously, searching through millions of stock records took 20-40 seconds. By adding an index to the lot ID field, the lookup time has been reduced to just 1-4 seconds, improving overall sales efficiency.
Original PR description
Issue: -- The query created by the function '_compute_sale_order_ids' takes around 20-40 seconds since its doing "WHERE" searches on millions of stock.picking records Fix: -- Added an index to the…
Issue: -- The query created by the function '_compute_sale_order_ids' takes around 20-40 seconds since its doing "WHERE" searches on millions of stock.picking records Fix: -- Added an index to the "lot_id" field of the stock.move.line model. (Already existing databases can be fixed by using the webshell) Steps to recreate the issue: -- 1. Have around a million stock.picking records 2. Go to "Inventory/Products/Lots/Serial Numbers" 3. Select any existing record or create and save a new one 4. These actions will take around 20-40 seconds to complete Before this commit: -- Selecting or saving any 'stock.lot' takes around 20 seconds After this commit: -- Selecting or saving any 'stock.lot' takes around 1-4 second Benchmark: -- Benchmark test was done one a database with ~4000 stock.move records and 1.74 million stock.picking records Opw-5459842 | Before this Commit | ~20 seconds | After this Commit | **~1-4 seconds & Memory usage just a little bit higher --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255255
This update fixes a bug where a new Sale Order was incorrectly created when adding lines to a sale order. The fix ensures that existing Sale Orders are reused, streamlining the process and preventing duplicate orders. This improves order management efficiency.
Original PR description
_*= sale_project **Issue:** When a new sale order line is created on the fly, a new Sale Order is being created instead of reusing an existing one. **Root Cause:** This happens when the project_sale_order is not being passed correctly in the context, causing a new Sale Order to be created. **Fix:** Explicitly pass the default_order_id in the context. If an existing Sale Order is found, it will be reused instead of creating a new one. **Technical Details:** Updated the `default_order_id` to use sale_order_id instead of `project_sale_order_id` in `sale_project`. This ensures that the field functions correctly even when `project_sale_order_id` is empty. **task-4276677** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258201 Forward-Port-Of: odoo/odoo#203230
This update corrects a bug where the product count in the stat button on Sale Order Lines created from tasks would incorrectly show '0 products' until the task was saved. Now, the count accurately reflects the products in the order line, improving the accuracy of sales reporting and order management.
Original PR description
Previously, when creating a Sale Order Line on the fly from a task, the product count in the stat button showed '0 products' until the task was saved. Now, the counter no longer drops to 0 when the record is not saved. task-4276677 Forward-Port-Of: odoo/enterprise#113334 Forward-Port-Of: odoo/enterprise#95100
This update corrects a bug where material resources with assigned roles were incorrectly displayed when filtering by employees in the Planning app. The fix ensures that only employee-type resources and those without assigned roles are shown, improving data accuracy and usability. This resolves a previous issue where the employee filter wasn't functioning as intended.
Original PR description
Steps to Reproduce: 1. Open the Planning app. 2. Go to Configuration -> Materials. 3. Set a role on either the demo material resource laptop or toolkit. 4. Go back to the Planning view. 5. Apply the view filter employee (filter by Employees). Issue: The material resource with a role should not be visible, but it is still present. Current behaviour: When filtering the Planning view by Employees, material resources with an assigned role remain visible. Expected behaviour: Material resources with an assigned role should be excluded from the Planning view when filtered by Employees — only employee-type resources and resources on which role is not set should appear. Fix: Improved the filter domain so unnecessary data are excluded. Task-4526989 Forward-Port-Of: odoo/enterprise#92816
This update ensures Odoo correctly handles tax exemption reasons related to Peppol standards. Previously, some tax exemption reasons were missing, and this change adds all required reasons to improve compliance and accuracy in tax calculations. This impacts how Odoo processes and reports on tax exemptions.
Original PR description
Some tax exemption reasons were missing, This commit ensures having all the tax exemption reasons introduced by Peppol task-6048561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257174 Forward-Port-Of: odoo/odoo#254841
This update ensures that supported documents are only generated for Odoo partners who are correctly identified as participating in Nemhandel. Previously, the process would incorrectly generate documents for invalid partners, leading to test failures. This change improves the reliability of document generation and prevents unnecessary processing.
Original PR description
The method to fill the supported documents of a partner was called even if it was not a valid Nemhandel participant. This would cause some test to fail as the call was unexpectedly done on tests without any setup for it.
This update resolves an issue where the import of invoices through the Peppol integration was not correctly returning the newly created invoice record. The change was previously implemented in a related system update, but wasn't fully integrated into the documents_account_peppol module. This ensures accurate tracking of invoices within the Peppol system.
Original PR description
Due to 271d6f2af4eea1ac2a79850069118c00dd97db97, the import invoice method in Peppol should return the created move and not just True. With the documents_account_peppol module, that change was not fully merged. opw-6102218 Forward-Port-Of: odoo/enterprise#113291
This update resolves a technical problem in the account_edi_ubl_cii module that prevented it from correctly processing UBL invoices. The fix ensures the module receives the expected single record, improving the reliability of invoice processing. This change ensures invoices are processed correctly.
Original PR description
`_need_ubl_cii_xml` requires a single record to be passed. However, it is currently called with `self`, which could be a recordset. Call with the `move` of the current iteration instead. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the core spreadsheet library used in Odoo. The changes include bug fixes related to number formatting and rendering, as well as improvements to testing and browser compatibility. These updates ensure the spreadsheet functionality continues to operate correctly and reliably.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4836743b29 [REL] 18.3.42 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4836743b29 [REL] 18.3.42 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8dea05219d [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834) https://github.com/odoo/o-spreadsheet/commit/f805024e56 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/29ff649f02 [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/eefd1535f5 [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/66bda8d726 [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092) https://github.com/odoo/o-spreadsheet/commit/e33b14cf0c [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0226237dd2 [FIX] xlsx: export formula that returns an error [Task: 6008904](https://www.odoo.com/odoo/2328/tasks/6008904) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects a previous restriction in the Spanish tax module that prevented "Comunidades de Bienes" (CBs) – entities taxed as freelancers – from being correctly identified. The change broadens the regex to include VATs starting with 'E', ensuring accurate fiscal categorization and reporting for these businesses. This improves compliance with Spanish tax regulations.
Original PR description
In Spain, "Comunidades de Bienes" (VAT starting with 'E') are entities without legal personality that tax via income attribution to their members. For accounting and tax reporting purposes, they must be treated as individuals/freelancers rather than corporations. The current _l10n_es_freelancer logic was too restrictive, only matching standard DNI (8 digits + letter) or NIE (starting with X, Y, Z). This caused CBs to be excluded from freelancer-specific logic, leading to incorrect fiscal categorization in reports and tax modules. The regex has been updated to optionally allow the 'E' prefix while ensuring the rest of the string maintains a valid format, effectively broadening the scope of what the system considers a Spanish freelancer. task-6014192 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253087
This update corrects a technical issue where data transmission related to payroll calculations was unintentionally active in non-production (test) environments. This change ensures that test data remains isolated and accurate, preventing potential discrepancies during development and testing of the l10n_ch_hr_payroll module. It improves the reliability of our testing process.
Original PR description
Forward-Port-Of: odoo/enterprise#113504
A recent update resolved an issue where the annual tax report would crash when comparing data with a previous period. This was caused by an incorrect check for numeric values within the report, specifically when handling string data. The fix ensures the report functions correctly under various data conditions.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#112619
This update resolves an issue where QR codes generated for Swiss invoices were being rejected by banks. The fix filters out unauthorized Unicode characters from the QR-Bill, ensuring compliance with the specific character set allowed by Swiss banking regulations. This prevents invoice rejections and ensures smooth payment processing.
Original PR description
**Description of the issue/feature this PR addresses:** QR code is rejected by the bank, when it contains an invalid character `U+202F`. **Current behavior before PR:** Unauthorized Unicode characters are encoded in the QR-Bill, and it is rejected on the receiving part. **Desired behavior after PR is merged:** Any Unicode codepoint which is not in the subset of 324 allowed codepoints has to be filtered out. > spec of QR-bill allows only a subset of characters, a precise list of 324 Unicode codepoints (section 4.1.1, page 30 of the Swiss Implementation Guidelines for the QR-bill) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257961 Forward-Port-Of: odoo/odoo#254980
This update fixes an issue where attachment overviews (the blue boxes showing attachment names) weren't appearing in the chatter after uploading files. This change ensures that users can always see the overview of attached files when creating activities within the Odoo chatter. This resolves a visual inconsistency and improves the user experience.
Original PR description
--- When in the chatter, we can create an activity. If we add an attachment to the notes of this activity and save it, the overview of the attachment won't show in the chatter. 1. Open an app that…
--- When in the chatter, we can create an activity. If we add an attachment to the notes of this activity and save it, the overview of the attachment won't show in the chatter. 1. Open an app that gives you access to the chatter, for instance, an invoice in Accounting. 2. Click on Activity. Click on Log a Note... and on the button Upload a file. Upload an attachment and save. The overview of the file (blue box with the name of the attachment) should appear. The overview doesn't appear Since 19.0, we want to replace static rendering with embedded components everywhere for rendering attachments, but this creates issues for the rendering of the overview in the chatter. Therefore, after internal discussion, we agreed to keep rendering overviews statically. Backport of: https://github.com/odoo-dev/odoo/commit/4a2412b93bcac9e71826f7c0101243cdb882ddf6 opw-6035026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254814
This update enhances the stability of the Odoo integration with Fiskaly, the French point-of-sale system. Specifically, it fixes issues with retry logic, ensures correct SCU usage, and simplifies configuration tracking, leading to a more reliable and manageable connection.
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
This update prevents a bug where changing a child company's ZATCA API mode would inadvertently reset and unboard the parent company's related sales journal. The fix ensures that changes are applied only to the intended company, maintaining data integrity and preventing unexpected journal removals.
Original PR description
**Steps to reproduce:** * Install `l10n_sa_edi` module. * Create a parent company and a child company, both with the same VAT number. * Onboard the parent company's Sales journal with ZATCA. *…
**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.
**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.
**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.
**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.
opw-6099340
Forward-Port-Of: odoo/odoo#258006This update fixes an issue where changing a contact's name automatically updated the associated account holder name, regardless of whether they were originally the same. Now, the account holder name only updates if the contact's name changes and it was previously the same, ensuring data consistency and accuracy in bank account information.
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#256439 Forward-Port-Of: odoo/odoo#248886