Tuesday, February 24, 2026
23 changes · saas-19.2
Enhancements to existing features
This update enhances the depreciation schedule reports within the Enterprise edition of Odoo by automatically including an analytic filter. This allows for more granular tracking of depreciation costs by specific projects or departments, providing better financial insights. The change improves reporting accuracy and supports more detailed cost analysis.
Original PR description
Forward-Port-Of: odoo/enterprise#108334
This update enables OAuth and tokenization for Mercado Pago payments, enhancing security and payment processing capabilities. It also addresses a critical issue by explicitly excluding unsupported countries, preventing errors for users in those regions. The changes include required data for recurring payments to meet Mercado Pago's homologation requirements.
Original PR description
OAuth is enabled for Mercado Pago, which also allows enabling tokenization. Not supported countries were added to the list of countries which would result in an error when user in one of the unsupported countries would try to go through OAuth. Forward-Port-Of: odoo/odoo#234747
Resolved issues and error corrections
This update fixes a problem where the earliest contract start date for employees wasn't consistently tracked. Now, the system automatically updates this key field whenever a new contract is created or an existing contract's start date changes, guaranteeing accurate historical data for payroll and reporting.
Original PR description
Version-19.0 **Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late. We need that information at other places too. ### What This PR Does This PR restores…
Version-19.0
**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
We need that information at other places too.
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
1. A new contract is created
2. an existing version changes it start date, or
3. an existing version is deleted for the employee.
### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
`contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
1. fetches all the active versions of employee
2. filter those having `contract_date_start`
3. Computes the earliest start date.
4. Updates `employee.first_contract_in_company` accordingly.
**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.
Forward-Port-Of: odoo/enterprise#107971
Forward-Port-Of: odoo/enterprise#102198This update resolves an issue where consolidated invoices were incorrectly linking orders due to a bug in how the system processed POS orders. The fix ensures that all orders associated with a consolidated invoice are accurately reflected, improving invoice accuracy and reporting. This change was made to enhance the reliability of our invoicing process.
Original PR description
Step to Reproduce: * Install l10n_my_edi_pos and switch to that company * Configure two POS sessions (POS 1 and POS 2) * Create orders as follows: POS 1: * 2 uninvoiced orders * 1 invoiced order *…
Step to Reproduce: * Install l10n_my_edi_pos and switch to that company * Configure two POS sessions (POS 1 and POS 2) * Create orders as follows: POS 1: * 2 uninvoiced orders * 1 invoiced order * Close POS 1 POS 2: * 1 uninvoiced order * 1 invoiced order * Close POS 2 Reopen POS 1: * 1 uninvoiced order * Close POS 1 Reopen POS 2: * 1 uninvoiced order Close POS 2 * Go to Orders → Consolidated Invoice * Create a consolidated invoice using the correct date range Observation: * Two documents are created * No. of orders linked to each document are incorrect Cause: * `_split_pos_orders_in_lines` overwrites entries in the `lines_per_config` dictionary * Previous orders for the same config are lost Fix: * Extend the existing recordset in `lines_per_config` instead of overwriting it Before <img width="1230" height="231" alt="order consolidation bug" src="https://github.com/user-attachments/assets/26657f34-998e-41c4-a68a-0939cbe6de1d" /> After <img width="1265" height="206" alt="consolidated order fixed" src="https://github.com/user-attachments/assets/7c703416-ac3b-412e-bb28-0d6f73fa25f2" /> opw-5904420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248402
This update corrects a problem in the payment dashboard query that was causing errors and slowing down performance. The change ensures the query behaves consistently with previous versions by disabling record rules, which reduces unnecessary joins and avoids ambiguous column errors. This improves the dashboard's speed and reliability.
Original PR description
In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior. The dashboard query for payments to check was executed with the default…
In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior.
The dashboard query for payments to check was executed with the default `bypass_access=False`, causing record rules to be applied. This introduced extra joins (e.g. on `res_company`) and resulted in ambiguous column errors during aggregation.
```py
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 414, in _get_journal_dashboard_data_batched
self._fill_sale_purchase_dashboard_data(dashboard_data)
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 600, in _fill_sale_purchase_dashboard_data
self.env.cr.execute(sql)
File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "currency_id" is ambiguous
LINE 1: SELECT journal_id, company_id, currency_id AS currency, invo...
^
```
Set `bypass_access=True` to match the original `_where_calc` behavior and avoid unnecessary joins.
opw-5951694
upg-3902613
[^1]: https://github.com/odoo/odoo/commit/6f95152b00df75f503f445e3b77b891b5f83c055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250003This update resolves an issue preventing the correct display of an employee's SSN when generating CFDI reports in the payroll module. The fix updates a template reference to directly access the SSN from the employee record, ensuring accurate reporting. This improves the functionality of a key payroll reporting feature.
Original PR description
Steps to reproduce the issue: 1. Install the module `l10n_mx_hr_payroll_account_edi`. 2. Generate a payslip for an employee. 3. The following traceback is raised at the moment to click on "Generate…
Steps to reproduce the issue:
1. Install the module `l10n_mx_hr_payroll_account_edi`.
2. Generate a payslip for an employee.
3. The following traceback is raised at the moment to click on "Generate CFDI" button:
```py
File "/data/build/odoo/odoo/addons/base/models/ir_qweb.py", line 858, in _render_iterall raise
QWebError(qweb_error_info) from error odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the
template: KeyError: 'l10n_mx_ssn' Template: l10n_mx_hr_payroll_account_edi.report_payslip_mx_cfdi Reference:
8166 Path: /t/t/div/t[2]/div[4]/table[2]/tbody/tr/td/div[5]/span[1]
Element: <span class="ms-1" t-field="o.version_id.l10n_mx_ssn"/>
```
---
To avoid moving the `l10n_mx_ssn` field from the `hr.employee` model to `hr.version`, the `t-field` in the template is updated to `o.employee_id.l10n_mx_ssn`.
This approach is valid because an employee's SSN rarely changes. If a modification is ever needed, it can be updated directly on the employee form, where the field is already tracked.
target: saas-19.2
task-5962423This update significantly speeds up the salary simulation process within the HR system. By adding an index and avoiding unnecessary image calculations, the simulation now completes much faster – nearly five times quicker. This improves user experience and efficiency when configuring employee salaries.
Original PR description
Description ----------- Add missing index on `hr.expense.employee_id` as it's used in a few places as a transitive dependency. Avoid computing images for new employee versions during simulation, as it's loading external dependencies, incurring a performance cost. Benchmark --------- On a staging database, opening the salary configurator and clicking on 'Simulation' when selecting a new car took: | Timings for | Before | After | Speed up | |--------------------|--------|--------|----------| | `onchange_benefit` | ~750ms | ~160ms | 4.6x | | `update_salary` | 2.3s | 1.1s | 1.9x | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249160 Forward-Port-Of: odoo/odoo#241901
This update streamlines the process of generating salary simulations by introducing a standardized context manager. This ensures consistent setup and teardown of necessary operations, reducing potential errors and improving the reliability of the simulation results. It also enforces the correct configuration for these critical calculations.
Original PR description
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose…
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose and error-prone, as it's done at each call site of `hr.contract.salary.offer._get_version` and `hr.version._generate_salary_simulation_payslip` (or any other future method that may require such a savepoint). These methods have a comment that mentions *requiring* a savepoint to be called, but nothing is enforcing it, so a bug due to oversight is bound to happen. Context keys are also injected a bit everywhere like `salary_simulation` and `tracking_disable`, without much consistency, and adding to the visual clutter. This commit introduces a little context manager called `hr_version_context` that manages the creation of the savepoint, the setup and teardown necessary, and the setting of the keys in the context. It's accompanied by a decorator `@requires_hr_version_context` that will fail if the caller didn't use `hr_version_context` before invoking the marked method. This ensures: - Correct creation of the savepoint and its related pre-/post-operations - Apply context keys consistently - Ensure methods that require such setup *cannot* be called without it. Forward-Port-Of: odoo/enterprise#107743 Forward-Port-Of: odoo/enterprise#103187
This update ensures payslips display the employee's actual start date with the company, rather than the contract's start date. This correction addresses inconsistencies when employees change jobs internally, guaranteeing accurate historical pay information and preventing outdated dates from appearing on payslips.
Original PR description
In the paysplip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Here we create a new function, similar to _get_first_version_date() which returns the beginning of the contract tied to the first version of the period, instead of the beginning of the version itself, which might be before or after the actual date of the start of the contract. We call this function _get_first_contract_date(). Task: 5909637 Enterprise PR: https://github.com/odoo/enterprise/pull/106692 Forward-Port-Of: odoo/odoo#249347 Forward-Port-Of: odoo/odoo#248598
This update corrects a previous issue where payslips incorrectly used the current contract start date. Now, payslips display the employee's actual entry date with the company, ensuring accurate payroll calculations and historical records, especially for internal job changes. This change impacts payroll processing in Switzerland and the UAE.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#107854 Forward-Port-Of: odoo/enterprise#106692
This update ensures that invoices generated with the `l10n_it_edi` module correctly display the total amount in EUR, as required by Italian tax regulations. Previously, the total was incorrectly formatted in the invoice currency, leading to potential compliance issues. This change ensures accurate reporting for Italian businesses.
Original PR description
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to…
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency. `ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document: https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b > L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che > “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”. > Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>` > deve essere obbligatoriamente “EUR”. > Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that > “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.” > Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>` > field must mandatorily be “EUR”. As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field (assuming the company currency is always EUR for `l10n_it`). Ticket [link](https://www.odoo.com/odoo/project.task/5913088) opw-5913088 Forward-Port-Of: odoo/odoo#249272 Forward-Port-Of: odoo/odoo#247537
This update resolves an issue where Odoo incorrectly defaulted to USD as the Stripe currency, causing potential blocking for European companies where EUR is the correct currency. The change switches to EUR as the default, ensuring accurate Stripe integration and preventing disruptions for EU users. This resolves previous support tickets opw-5393508, opw-5913327, and opw-5953025.
Original PR description
Right now, we need to guess the correct stripe currency for the stripe account depending on the country, we used the USD as an ultimate fallback But, the USD currency is easy to guess, where the EUR is way harder (it may not be the company currency). So, it is too error-prone to set the USD as the default fallback, and it can lead to EU companies being blocked as their stripe currency is the wrong one. We therefore switch it to EUR. opw-5393508 opw-5913327 opw-5953025 Forward-Port-Of: odoo/enterprise#108293
This update corrects a critical issue in the generation of Belgian UBL invoices by ensuring the required ‘schemeID’ is included. This ID, part of the ISO 6523 ICD list, is now correctly applied, ensuring compliance with regulatory standards for company registries. This fix improves the accuracy and reliability of invoice processing for Belgian businesses.
Original PR description
1) This commit adds the new generic methods to build an UBL file. The big objective is to remove the hierarchy of UBL later on and make BIS3 completely standalone. In this commit, BIS3 is not independent of UBL 2.1 & 2.0. 2) Missing schemeID for Belgium Company registry Since https://github.com/odoo/odoo/commit/d40652c17b43b6a9fd4d19ce84b943b2a51fad9c, in Belgium, we set by default the company registry. However the schemeID is missing and should be part of the ISO 6523 ICD list: https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/ 3) Fix PartyLegalEntity when the country is NL and there is no company registry/EAS/Endpoint That case was raising a traceback before this commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249093 Forward-Port-Of: odoo/odoo#246377
This update fixes a calculation error in the Belgian payroll module, ensuring that meal vouchers and private car expenses are accurately reflected on payslips. Previously, these amounts were displayed as zero. This change ensures accurate reporting and compliance for Belgian employees.
Original PR description
In this commit, we fixed the data of the existing Belgian structure types by setting the right work entry type as default_work_entry_type_id. Belgian's structure types should have the correct attendance work entry type to consider the meal vouchers and the private car in the benefits and payslip lines Before this change, the belgian payslips will have quantity 0 for meal vouchers and private car. After this change, the belgian payslips will have the correct quantity for both meal vouchers and private car. task-5946425
This update prevents internal Odoo users without invoicing rights from accessing and downloading invoice data in JSON/XML format. Previously, a vulnerability allowed internal users to view these sensitive files, posing a potential security risk. This change ensures that access to this data is restricted to authorized invoicing users, improving data security and compliance.
Original PR description
Steps to reproduce: 1. Create an Invoice 2. Send for EDI (should in error, easy way to do it in local turn off the internet) 3. Turn Debug mode 4. Click Download (A new window with URL with will be open) showing the JSON/XML 5. Change Marc Demo (or any user) being internal user without Invoicing rights 6. That user can access the JSON/XML with that particular URL After this commit- We make sure only Invoicing Users can download the JSON/Export task-5481114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243257
This update resolves a bug where users without access to a company were unable to view organization charts for employees in that company. The fix ensures that access checks are performed correctly, allowing users to see the full organizational structure regardless of company permissions. This improves usability and prevents data access errors.
Original PR description
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't…
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't have access, the employee A will see an AccessError, even if employee A can have access to the page of employee B. ## Reproduction Steps 1. Create a second company to your database. Let's call these companies Company A and Company B. 2. Select Company A as your main company, but make sure Company B is also selected. 3. Create an Employee A. 4. Select Company B as tour main company; but make sure Company A is also selected. 5. Create an Employee B who has A as manager. 6. Create Employee C who has B as manager. 7. With a user only having access to Company B, log in and try to access Employee C's page. ### Expected behavior Employee's C page loads correctly. ### Unexpected behavior An access error occurs. ## Origin of the issue A sudo() was missing. __ opw-5910036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248819 Forward-Port-Of: odoo/odoo#247817
This update restores a key feature in the Point of Sale system – the ability to mark orders as 'trusted.' Previously, this functionality was removed, causing potential issues with order management. This fix ensures that users can correctly designate trusted orders, streamlining the sales process.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240883 Forward-Port-Of: odoo/odoo#200567
This update removes a problematic printing library to significantly improve the stability and reliability of printer functionality within Odoo. While features like QR codes and low-paper warnings are being removed, this change prioritizes a more robust and dependable printing experience.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as…
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as letting us query the status of the printer to check if it was e.g. out of paper. However, using this library has complicated the code and caused many reliability problems when using USB printers. In particular, the printer could print garbage and then become stuck until it was restarted. This seems to be due to a multi-threading issue, as the print is interrupted half-way through when the `USBInterface` checks for devices. Since the added value is small compared to the extra maintenance and reliability costs, the `python-escpos` library is being removed in favour just using CUPS for all print jobs, as was the case in 18.0. This means we will no longer have a QR code on the status receipt or a warning when the paper is running low, but these are unimportant compared to reliability. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250141 Forward-Port-Of: odoo/odoo#249819
This update resolves an issue where Invoicing and Banks users were unable to access key financial reports. The change restores access rights, allowing these users to view essential reports without encountering errors. This ensures accurate reporting and analysis for these user groups.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#108054 Forward-Port-Of: odoo/enterprise#107654
This update resolves an issue that prevented the correct download of XML invoices for Italian companies using the l10n_it_edi module. The fix corrects a mismatch in how invoice data is structured, ensuring the XML FatturaPA file can be generated without errors. This ensures Italian businesses can continue to comply with local tax regulations.
Original PR description
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company…
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company - Create a new invoice > Customer: IT Company > Add a product > Confirm > Send > Send - Actions > Print > XML FatturaPA Traceback: ```py TypeError: string indices must be integers, not 'str' ``` In commit [1], ``_get_invoice_legal_documents`` was updated to return a list instead of a dictionary. However, the ``l10n_it_edi`` module was not adapted accordingly and still returns a dictionary at [2]. If ``_get_invoice_legal_documents`` returns a dictionary instead of a list, the following logic incorrectly iterates over dictionary key which leads to the above traceback. https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/account/controllers/download_docs.py#L24-L26 [1]: https://github.com/odoo/odoo/commit/90dcd6cfe904974dfa077c2d8d9e168a09eeecf9 [2]: https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/l10n_it_edi/models/account_move.py#L399-L403 sentry-7272542156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249408
This update resolves an issue where Spanish e-Facturae invoices were generating XML files with excessive decimal places (up to 8), causing validation errors with the Spanish tax authority. The fix ensures that currency amounts are rounded to two decimal places as required by Spanish regulations, improving compliance and preventing invoice rejection.
Original PR description
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit…
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost. When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)." According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places. This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies. [1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844 Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf) opw-5927356 Forward-Port-Of: odoo/odoo#249674 Forward-Port-Of: odoo/odoo#248882
This update resolves an issue that caused duplicate move entries to appear in the shop floor view when creating work orders without a Bill of Materials. The fix clarifies how work orders and operations are linked, ensuring accurate display of components and preventing errors that could disrupt production workflows. This improves the reliability of the shop floor interface.
Original PR description
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation…
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation to be performed in a workcenter - Confirm the MO and open the Shop Floor - Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display - Click on `Add component` and add any valid component via the catalog #### > Traceback: `OwlError: Got duplicate key in t-foreach` ### Cause of the issue: The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72 Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188 However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47 Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected. In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error. opw-5417887 Forward-Port-Of: odoo/enterprise#106200
This change reverses a previous update that was incorrectly removing accented characters from legal names used for Mexican VAT (EDI) processing. The SAT now allows all characters, so Odoo will now accept the user-entered, accented names as they are, giving users full control and preventing issues. This simplifies the process and ensures accurate VAT compliance.
Original PR description
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least…
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]). This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues. The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them. This reverts the whole accent sanitization saga: - Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4. This also removes the unused frozendict import to make "Check Style" happy. opw-5915515 [1] https://github.com/odoo/enterprise/pull/95207 [2] https://github.com/odoo/enterprise/pull/107960 [3] https://github.com/odoo/enterprise/pull/96043 [4] https://github.com/odoo/enterprise/pull/106557 [5] https://github.com/odoo/enterprise/pull/107677 Closes odoo/enterprise#107960 Forward-Port-Of: odoo/enterprise#108425 Forward-Port-Of: odoo/enterprise#108189