Daily updates from Odoo
Friday, May 29, 2026
14 changes · 18.0
New functionality added to Odoo
This update adds the ability to group analytic reports by product category. Previously, reports were limited to grouping by other fields. This enhancement provides more granular insights into spending by product type, improving financial analysis and reporting accuracy.
Original PR description
Add the related (non-stored) 'product_category' field on the account.analytic.line model to make it available in the Analytic Reporting "Group By" task-6219418
This update implements a new system for French businesses to electronically report transactions (B2C and international B2B) to tax authorities. It addresses a legal requirement for structured data reporting via ‘Flux 10’, enhancing compliance and data accuracy. Security enhancements, including 2FA and KYC, have also been added to protect sensitive financial information.
Original PR description
France’s electronic invoicing reform : The tax administration needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B…
France’s electronic invoicing reform : The tax administration needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C. This creates two complementary obligations: - **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow. - **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based). ## Scope Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information. Flux 10 is introduced for transactions that must be reported separately: - B2C transactions, where there is no buyer-side e-invoice exchange. - International B2B transactions, where the counterparty is outside the French domestic B2B mandate. - Payment reporting when VAT exigibility depends on collection. The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines. ## Corrections and Lifecycle Flux 10 supports both: - **Initial reports**, for the first declaration of a period. - **Rectificative reports**, when already reported data must be corrected or completed. This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted. ## Security and Eligibility This PR also enforces stronger safeguards before using PDP/PA services. - **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app. - **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure. Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform. Task-4603708
Resolved issues and error corrections
This update fixes an issue where check amounts weren't being properly rounded when generating the check amount in words for Philippine companies. Previously, the check displayed an incorrect decimal format with 'ONLY' appended. The fix rounds the payment amount to ensure accurate check formatting, improving the user experience for Philippine vendors.
Original PR description
Current behaviour: --- When paying with checks, the amount is not rounded in the check amount in words string. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. Create a new vendor bill 4. Add a product with a specific price like 91490.15 5. Confirm the bill, click on Register Payment 6. Select Payment Method "Checks", Create Payment 7. Go to the payment, Amount in Words is wrong 8. Ninety-One Thousand Four Hundred Ninety And 15000000001/100 ONLY Expected behaviour: --- The decimal amount should be rounded, and "ONLY" shouldn't appear. Fix: --- Rounded the pay amount And backported: https://github.com/odoo/enterprise/commit/bb6c9848665709c14c5113b2c98976f869cd473b opw-6058344 Forward-Port-Of: odoo/enterprise#116717
This update fixes a crash during Odoo 18 upgrades when archiving incoming operation types. The issue stemmed from a requirement for a specific picking type, which wasn't being met for archived types. The fix ensures that archived picking types are considered, allowing the upgrade process to complete successfully.
Original PR description
### Steps to Reproduce: 1) Create a database on v17.4 or earlier with purchase_requisition_stock installed. 2) Archive the incoming operation type of root company (i.e. base.main_company). 3) Upgrade…
### Steps to Reproduce:
1) Create a database on v17.4 or earlier with purchase_requisition_stock
installed.
2) Archive the incoming operation type of root company (i.e. base.main_company).
3) Upgrade to v18.
### Issue:
Upgrade crashes with RedirectWarning, aborting the process entirely.
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 485, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 605, in init_models
model._auto_init()
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3474, in _auto_init
new = field.update_db(self, columns)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3269, in update_db
return super(Many2one, self).update_db(model, columns)
File "/tmp/tmpy3l3l_un/migrations/base/0.0.0/pre-models-no-orm-table-change.py", line 170, in update_db
return orig_update_db(self, model, columns)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1098, in update_db
self.update_db_notnull(model, column)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1150, in update_db_notnull
model._init_column(self.name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3390, in _init_column
value = field.default(self)
File "/home/odoo/src/odoo/18.0/addons/purchase_requisition_stock/models/purchase_requisition.py", line 13, in _default_picking_type_id
self.env['stock.warehouse']._warehouse_redirect_warning()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_warehouse.py", line 172, in _warehouse_redirect_warning
raise RedirectWarning(msg, warehouse_action.id, _('Go to Warehouses'))
odoo.exceptions.RedirectWarning: ('Cree un almacén para la empresa Navieras Internacionales, S.A. (Navinter).', 464, 'Ir a los almacenes', None)
```
### Cause:
picking_type_id is required=True on purchase.requisition. In 18.0, warehouses are no longer auto-created for every company https://github.com/odoo/odoo/commit/6516ab61927a63e3f2d804cf1b5baa43a151ca19#diff-e018fe59e11c4e0078e9bc19879f9e98c731bb84c71766ef360ccc482c59d2d8R167 If the root company (base.main_company) had its incoming operation type archived and the upgrade, _default_picking_type_id returns nothing and falls through to _warehouse_redirect_warning, raising a RedirectWarning that aborts the upgrade entirely.
### Fix:
Add active_test=False to the search in _default_picking_type_id so archived picking types are also matched, allowing the upgrade to complete successfully.
opw-6245256
upg-4310650
tbg-2758
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where the pension fund tax was incorrectly applied to all invoice lines with the same VAT rate, leading to inaccurate accounting. The fix now correctly identifies the tax exemption reason from the bill data, ensuring the pension fund tax is applied accurately to the first invoice line. This improves tax compliance and financial reporting.
Original PR description
In `l10n_it_edi` vendor bill import, the pension fund tax was incorrectly applied to all invoice lines sharing the same VAT rate, even though they have different `l10n_it_tax_exemption_reason`s, resulting in wrong entries and document total. We now extract the Tax Exemption reason from the `DatiCassaPrevidenziale` node, and use it to search the correct tax. Steps to reproduce: 1. Install `account` and `l10n_edi_it` 2. In the `4% INPS` tax, set `TC22` in pension fund type and `N2.2` in exoneration 3. Import bill from the ticket 4. See the pension fund tax is applied to all the lines. It should only be applied only to the first one. Ticket [link](https://www.odoo.com/odoo/project.task/6212975) opw-6212975 Forward-Port-Of: odoo/odoo#265821
This update resolves an issue where Odoo couldn't correctly import Peppol optional fields due to a limitation in field type support. The change now allows for both 'char' and 'text' field types, ensuring accurate import of these critical data elements. Additionally, unnecessary PDF attachments from the test files have been removed.
Original PR description
_Context :_ Users might confuse the `char` with the `text` field types when creating Peppol optional fields. Currently, only the `char` type is supported, which prevents `text` fields from being recognized and imported correctly. To avoid this issue, we support multiple types for the same field when necessary. Also, the test files of this PR : https://github.com/odoo/odoo/pull/262065 included PDF attachments, which is useless. This commit removes them. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where a quality check failure incorrectly reduced the quantity of components used in a subcontracting production. Now, the system accurately reflects the reduced component consumption, preventing incorrect stock levels. This ensures accurate tracking of materials and avoids over-ordering components.
Original PR description
*:mrp_subcontracting{,_quality}, quality_control **Issue**: In subcontracting, if a quality check of type quantity failed, the associated mo quantity produced is reduced. This is an issue since it…
*:mrp_subcontracting{,_quality}, quality_control
**Issue**:
In subcontracting, if a quality check of type quantity failed, the associated mo quantity produced is reduced. This is an issue since it will, by extension, reduce the consumption of the component. Therefore, the stock of the component become incorrect.
**Steps to reproduce**:
- Create two tracked products (final and component)
- Create a BoM for the final product using the component (1:1 ratio), with subcontracting
- Create a quality check for that product:
- Control per quantity
- Operations type: receipts
- Create a PO for the final product:
- With a quantity of 10
- With the associated partner be the one mentioned in the subcontracting BOM
- Confirm it
- Open the associated receipt
- Perform the quality check and fail 4 products
- Validate the receipt by creating a backorder
- Confirm the backorder
- Check move history -> The move associated to the component will have a quantity of 6 instead of 10.
**Cause**:
While failing a quality check:
https://github.com/odoo/enterprise/blob/8cd7fffde3c9e73fa95080a82c5750d1a74370cb/quality_mrp/models/quality.py#L56 https://github.com/odoo/enterprise/blob/8cd7fffde3c9e73fa95080a82c5750d1a74370cb/quality_control/models/quality.py#L471
The `product_uom_qty` of the move of the po will be reduced. Therefore, the subcontracting mo quantity is reduced too: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp_subcontracting/models/stock_move.py#L140-L143 https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp_subcontracting/models/stock_move.py#L116-L119
And ultimately reduces the raw move quantity:
https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp/wizard/change_production_qty.py#L65
**Additional note**:
This commit also reverts the fix of 05ebbc27e37eaeff13dd0af2a8cdd7fa28209595 since it ensured the correct production was reduced. However, this commit ensures that production is not reduced at all, making the previous fix obsolete.
opw-5427873This update fixes an issue where a quality check failure in subcontracting incorrectly reduced the quantity of components used. This prevented accurate stock levels from being maintained, leading to incorrect consumption. The change ensures the correct production quantity is reduced, maintaining accurate component stock.
Original PR description
*:mrp_subcontracting{,_quality}, quality_control **Issue**: In subcontracting, if a quality check of type quantity failed, the associated mo quantity produced is reduced. This is an issue since it…
*:mrp_subcontracting{,_quality}, quality_control
**Issue**:
In subcontracting, if a quality check of type quantity failed, the associated mo quantity produced is reduced. This is an issue since it will, by extension, reduce the consumption of the component. Therefore, the stock of the component become incorrect.
**Steps to reproduce**:
- Create two tracked products (final and component)
- Create a BoM for the final product using the component (1:1 ratio), with subcontracting
- Create a quality check for that product:
- Control per quantity
- Operations type: receipts
- Create a PO for the final product:
- With a quantity of 10
- With the associated partner be the one mentioned in the subcontracting BOM
- Confirm it
- Open the associated receipt
- Perform the quality check and fail 4 products
- Validate the receipt by creating a backorder
- Confirm the backorder
- Check move history -> The move associated to the component will have a quantity of 6 instead of 10.
**Cause**:
While failing a quality check:
https://github.com/odoo/enterprise/blob/8cd7fffde3c9e73fa95080a82c5750d1a74370cb/quality_mrp/models/quality.py#L56 https://github.com/odoo/enterprise/blob/8cd7fffde3c9e73fa95080a82c5750d1a74370cb/quality_control/models/quality.py#L471
The `product_uom_qty` of the move of the po will be reduced. Therefore, the subcontracting mo quantity is reduced too: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp_subcontracting/models/stock_move.py#L140-L143 https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp_subcontracting/models/stock_move.py#L116-L119
And ultimately reduces the raw move quantity:
https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp/wizard/change_production_qty.py#L65
**Additional note**:
This commit also reverts the fix of c4e10e9fa90562b16d515f62910e094f77497f66 since it ensured the correct production was reduced. However, this commit ensures that production is not reduced at all, making the previous fix obsolete.
opw-5427873This update fixes a confusing error message that occurred when payments were processed with incorrect account settings. Now, users receive a clear error indicating a receivable or payable account wasn't found, guiding them to correct their partner's account configuration. This prevents payment processing failures and improves user experience.
Original PR description
Description of the issue/feature this PR addresses: When a payment's destination account is not of type receivable or payable (e.g. a partner has a misconfigured account), _synchronize_to_moves fails with an unhandled IndexError when trying to access counterpart_line_vals[0]. Current behavior before PR: Accessing a payment with an invalid counterpart account raises a cryptic IndexError: list index out of range, giving the user no actionable information about what went wrong or how to fix it. Desired behavior after PR is merged: A descriptive UserError is raised indicating that no receivable or payable account could be found for the payment counterpart, and pointing to the partner's account configuration as the likely cause. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where invoices with mixed taxes caused import errors, leading to inaccurate data processing. The fix prioritizes importing invoices without taxes when multiple tax configurations are present, and also corrects a parser selection problem that resulted in incorrect data extraction. This ensures more reliable invoice import and data accuracy.
Original PR description
Before this commit we had the following error when we imported a invoice that matches with taxes from two or more fiscal positions: ```python Error importing attachment '__name__.xml' as invoice (decoder=_import_invoice_ubl_cii) This specific error occurred during the import: This entry contains taxes that are not compatible with your fiscal position. Check the country set in fiscal position and in your tax configuration. ``` The prediction of the taxes continue being improved, meanwhile is better to import the invoice without taxes if there is a mix of taxes on the invoice. A second issue affected parser selection: UBLVersionID was checked before customization_id, so an invoice carrying both UBLVersionID=2.1 and the BIS3 customization ID was parsed by the generic ubl_21 parser instead of ubl_bis3, leading to incorrect field extraction. OPW-6022540
This update resolves a problem where users authenticating with company certificates (PESEL) were incorrectly rejected by KSeF, leading to errors. The change expands the certificate matching logic to correctly identify certificate types and restore functionality for existing users. No new UI changes are required.
Original PR description
### Description of the issue/feature this PR addresses: **Issue:** A recent update to support `certificateFingerprint` introduced a regression for existing users authenticating with standard…
### Description of the issue/feature this PR addresses: **Issue:** A recent update to support `certificateFingerprint` introduced a regression for existing users authenticating with standard certificates (AKA `certificateSubject`). Because the matching logic strictly checked for the company NIP within the certificate subject, it failed for users using personal PESEL certificates to act on a company's behalf. **Previous PR:** https://github.com/odoo/odoo/pull/264851 **Solution:** Expanded the string-matching heuristic in the XML signer to strip formatting characters from the NIP and explicitly checks for standard Polish qualified certificate prefixes (VATPL and PNOPL) to accurately get the identifier type. ### Current behavior before PR: When a user logs in via a personal PESEL certificate for a company context, the NIP check fails and miscategorizes the payload as a `certificateFingerprint`. KSeF rejects this mismatch, causing a 400 error for previously working setups. ### Desired behavior after PR is merged: The authentication flow distinguishes between `certificateSubject` and `certificateFingerprint` by checking for valid Polish prefixes or exact cleaned NIP matches. Existing customers are restored to working order natively, and new customers using manual fingerprints are still supported without requiring any database or UI changes. opw-6251153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue in the Italian annual tax report where both positive and negative values for VL3/VL4 and VL32/VL33 were displayed simultaneously. The fix ensures that only the positive balance is shown for each pair, aligning with tax reporting logic and improving report accuracy. This change impacts the Italian tax reporting process.
Original PR description
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for…
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for each pair: - VL3 (Tax Due) or VL4 (Tax Credit) - VL32 (Tax Due) or VL33 (Tax Credit) The other one should stay 0 If the global balance is null, both can be 0 ### Cause The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))` As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values ### Steps to reproduce - Install `l10n_it` and `accountant` and switch to IT Company - Create a balanced Journal Entry for any account - Add the Tax Grid v20 on one of the lines to impact the annual report - Open the `Annual Tax Report (IT)` - Go to the `VL` section - Check the value of VL3/VL4 and VL32/VL33 After the fix, only one value can be positive and the other 0 Ticket [link](https://www.odoo.com/odoo/project.task/6212694) opw-6212694 Forward-Port-Of: odoo/odoo#264294
This update resolves an issue where clicking outside a table while in transfer mode incorrectly canceled order transfers. Previously, the system would silently transfer orders after a misclick, leading to a confusing user experience. Now, the transfer listener is removed immediately when transfer mode ends, ensuring clicks outside a table truly cancel the action.
Original PR description
Description of the issue/feature this PR addresses: In pos_restaurant, the document click listener used for table transfer is only removed on the success path, leaking on misclick. Regression from [29d06d76889c](https://github.com/odoo/odoo/commit/29d06d76889c) Current behavior before PR: Cashier hits Transfer / Merge, clicks somewhere that isn't a table: the "transfer ongoing" banner disappears, so the action looks cancelled. Any later click on a table silently transfers the order to it. Nasty on floorplans with many tables. Desired behavior after PR is merged: removeEventListener fires as soon as transfer mode exits, regardless of whether the click hit a table. Misclick truly cancels; cross-floor transfer (via .button-floor) still works --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the inventory counting barcode app would fail when using archived units of measure. The fix ensures that archived UOMs are correctly loaded into the inventory count cache, allowing accurate barcode scanning and count operations. This improves the reliability of physical inventory processes.
Original PR description
### Steps to reproduce: - In the settings enable: "Units of Measure & Packagings", "Storage Locations" - Create a product in units and register 1 unit in stock - Inventory > Operations > Adjustments…
### Steps to reproduce: - In the settings enable: "Units of Measure & Packagings", "Storage Locations" - Create a product in units and register 1 unit in stock - Inventory > Operations > Adjustments > Physical Inventory - Select your line and request a count > Set Current Value - Inventory > Configurations > units of measures > UOM categories - Select unit and archive it - Go to the barcode app > Click Count inventory ### > Owl error: Uncaught promise ### Cause of the issue: Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache: https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error: https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110 opw-6250090