Daily updates from Odoo
Thursday, February 12, 2026
57 changes · saas-19.1
New functionality added to Odoo
This update ensures Odoo's Point of Sale system in Guatemala complies with local regulations. It automatically sets a default customer and prevents invoices from being generated for unidentified customers exceeding a defined threshold, avoiding rejection by the Guatemalan tax authority (SAT).
Original PR description
Purpose: This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation. Before this commit: - POS orders…
Purpose: This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation. Before this commit: - POS orders had no default customer. - Invoices generated for unidentified customers exceeding the legal threshold, leading to SAT rejections after submission. - GT Phrases configured on company were missing on the invoices generated through POS causing the electronic document to be rejected by SAT. After this commit: - Consumidor Final is set as the default customer on POS orders. - POS invoices cannot be generated for unidentified customers when the total exceeds the legal threshold (currently Q2500). - GT phrases configured on the company are now applied to POS invoices, ensuring valid electronic document submission to SAT. Technical Details: - Added a configurable legal threshold field on POS configuration. - Added validation to block invoicing when an unidentified customer exceeds the configured threshold. - Added a missing `super()` call in `l10n_mx_edi_pos` to ensure proper method chaining when multiple POS localizations are installed. related PR https://github.com/odoo/odoo/pull/242985 task-4393614 Forward-Port-Of: odoo/enterprise#103767
Enhancements to existing features
This update ensures Odoo's Spanish tax reporting (l10n_es_report) complies with the latest requirements from the BOE (Agencia Tributaria) regarding the Modelo 347. A change was made to the export format to align with recent regulations, specifically addressing a lack of subsidy number data by adding placeholder zeros. This update is crucial for accurate tax reporting in Spain.
Original PR description
reference: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-25390 considering the modelo 347 As we do not have anything for the subsidy number, we just put 6 0s. opw-5926624 Forward-Port-Of: odoo/enterprise#107125
Resolved issues and error corrections
A previous issue caused a timeout error in the website builder when adding elements like images, specifically when the system waited for user input after a dialog appeared. This update removes the timeout for these actions, preventing the error and ensuring a smoother user experience. It resolves a frustrating bug that prevented users from adding elements to their websites.
Original PR description
In [0] was added a timeout on operations, as an heuristic to detect when an operation is stuck. Unfortunately, when an action opens a dialog, waiting for the user to choose may go over the timeout limit, thus triggering the timeout. The timeout should be deactivated for those type of actions. This commit sets `canTimeout = false` on actions that open a dialog and wait for user choice in the `apply` method. Steps to reproduce: - Open website builder - Drop `s_sidegrid` snippet - Click on "Add Elements" option: Image - Wait 10sec - Bug: It show the error message "A technical issue occurred..." [0]: https://github.com/odoo/odoo/commit/6df83abb35c95ab42e55d9a08cf6c411efa64b3e Forward-Port-Of: odoo/odoo#248258
This update corrects a recent accidental removal of tests related to self-billing XML generation within the account_edi_ubl_cii module. These tests are crucial for ensuring invoices are correctly formatted for electronic billing, particularly in compliance with industry standards. The fix ensures continued accurate invoice export functionality.
Original PR description
Accidentally removed by 4247eac4a84c. task-none Forward-Port-Of: odoo/odoo#245954
This pull request fixes a minor typo in the Italian electronic invoice (EDI) system. The title ‘Fattura Electronica’ was incorrectly displayed; it has been corrected to ‘Fattura Elettornica’. This ensures accurate invoice processing and compliance with Italian tax regulations, preventing potential errors.
Original PR description
The title Fattura Electronica is wrong it should be Fattura Elettornica Asked by TSB 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-pr Forward-Port-Of: odoo/odoo#248153
This update fixes an issue where using the down arrow key within a table in the Powerbox interface caused the cursor to jump unexpectedly. The fix ensures that the Powerbox navigation continues correctly within the table, providing a smoother and more reliable user experience. This improves the usability of the To-Do module and other applications utilizing the table editor.
Original PR description
### Steps to Reproduce: - Go to To-Do & create a table (e.g.: /table). - Place the cursor in the last cell of the table. - Press / to open the command dialog (focus is on Heading 1). - Press Arrow Down. - Notice that cursor comes out of table and focus is as at Heading 2. ### Description of the issue/feature this PR addresses: - ArrowDown first triggers table cell navigation & cursor moves out of table. - Powerbox keydown handler runs afterward & focus moves to the next item. ### Desired behavior after PR is merged: - Powerbox keydown listener runs before table navigation (capture phase) stopImmediatePropagation() prevents table navigate cell. Cursor stays inside table cell & powerbox focus moves to the next item. task - 5895390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248064 Forward-Port-Of: odoo/odoo#247121
This update resolves an issue where the Stock Forecasted report incorrectly displayed stock quantities after a draft repair order was deleted. The fix ensures that related stock moves are properly cancelled when a draft repair order is removed, providing accurate stock reporting.
Original PR description
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in…
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in *draft* state (do not confirm). * In the **Parts** tab, add the storable product with the operation type set to *Add*. * Open the **Stock Forecasted** report for the added product. Note the quantity shown under *Outgoing Draft Transfer*. * Delete the **Repair Order**. * Open the **Stock Forecasted** report for the same product again. **Observed behavior:** * The quantity still appears in the **Stock Forecasted** report under *Outgoing Draft Transfer* even after the repair order is deleted. **Cause:** * Deleting a draft repair order triggers `_unlink_except_confirmed`. * This method prevents related stock moves from changing their state to cancel when the repair order is deleted. * The *Outgoing Draft Transfer* value is calculated as the sum of quantities of stock moves in draft state at draft state. https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49 https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90 * As a result, deleting a draft repair order leaves related stock moves in draft state, causing them to appear under *Outgoing Draft Transfer* https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335 **Fix:** * Ensure that related stock moves are properly cancelled when a draft repair order is deleted. --- opw-5449323 Forward-Port-Of: odoo/odoo#248155 Forward-Port-Of: odoo/odoo#241970
This update resolves an issue where the HTML editor would incorrectly retain selections of tables and separators after the user clicked outside the editor. Now, when you click outside the editor, all selected content – including text, tables, and separators – is properly deselected, providing a more consistent and intuitive user experience.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In Todo, Type some text. - Insert a table and a separator. - Select text along with table and separator. - Click outside the editor. The text is deselected but table and separator are still selected. **Desired behavior after PR is merged:** Custom selection such as table and separator is deselected along with browser selection when clicking outside the editor. task-5479981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247962 Forward-Port-Of: odoo/odoo#243484
This update resolves a sporadic error related to image loading in the Odoo web interface. The change ensures the system waits longer for image updates, preventing a common issue caused by the time it takes to encode image data. This improves the overall responsiveness and reliability of image display.
Original PR description
Encoding the data to base64 can take some times. Before this commit we used this code: ```js await runAllTimers(); await animationFrame(); ``` Now we explicitly wait for the change to happen as awaiting an animation frame can't be enough. runbot-error-237568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248166
This update fixes an error that occurred in the Point of Sale module when a unit of measure (like 'Pack of 6') was deleted. Previously, the POS module would fail to load if this UoM record was no longer present. This change ensures the POS module functions correctly even after users manage their UoM records.
Original PR description
Currently, an error is produced when loading the pos module when a referenced UoM record (e.g., Pack of 6) has been deleted by the user.
**Steps to Reproduce:**
- Install Sales Module.
- Enable **"Units of Measure & Packaging"**.
- Delete the **"Pack of 6"** Units.
- Install POS.
**Error:**
```
ParseError:
while parsing /home/odoo/src/odoo/saas-19.1/addons/point_of_sale/data/point_of_sale_data.xml:38, somewhere inside <record id="uom.product_uom_pack_6" model="uom.uom">
<field name="is_pos_groupable">True</field>
</record>
Exception:
Cannot update missing record 'uom.product_uom_pack_6'
```
The POS module overrides `uom.product_uom_*` records. If the original UoM record has been deleted, the override fails because the record no longer exists.
sentry-7237815280
Forward-Port-Of: odoo/odoo#246940This update resolves an issue where event tickets with unlimited seats (seats_max=0) incorrectly showed as 'sold out' when the event itself had a limited number of seats. The fix ensures that these tickets accurately reflect the event's availability, providing a more reliable POS experience for customers.
Original PR description
We had a bug when selling event tickets in POS where tickets with seats_max set to 0 (which should mean unlimited) appeared as sold out when the event had seats_limited enabled. Steps to reproduce:…
We had a bug when selling event tickets in POS where tickets with seats_max set to 0 (which should mean unlimited) appeared as sold out when the event had seats_limited enabled. Steps to reproduce: ------------------- * Create an event with seats_limited=True and seats_max > 0 * Create a ticket for that event with seats_max=0 (unlimited) * Open POS and view the event product > Observation: Ticket appears as "Sold out" instead of showing available seats Why the fix: ------------ The frontend logic only treated tickets with seats_max=0 as unlimited when the event itself was not limited (!event.seats_limited). However, according to the backend logic, seats_max=0 means the ticket is unlimited regardless of the event's limitation status. When the event is limited, unlimited tickets should still respect the event's seats_available limit, not show as sold out. We now check for seats_max=0 independently of event limitation. If the event is not limited, tickets with seats_max=0 are fully unlimited. If the event is limited, we use the event's seats_available value (since the ticket doesn't constrain availability but the event does), ensuring correct display of availability status. opw-5475803 Forward-Port-Of: odoo/odoo#246102
This update fixes an issue where the channel invitation dialog was not taking up the full width of the modal window. Previously, it was limited, causing it to appear smaller than intended. This change ensures the dialog displays correctly and provides a consistent user experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/244777 Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Open "General" in…
Backport of https://github.com/odoo/odoo/pull/244777 Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Open "General" in discuss app - Click on Sidebar "Channel Actions" - Click on "Invite People" => Invitation dialog takes about half of the width of modal. This happens because the channel invitation was wrongly assumed to be inside a resizable panel, and thus the size was limited by the max width when in resizable panel. The rule to determine whether the action is in a resizable panel was poor: any action panel in discuss app was considered as resizable. This commit fixes the issue by limiting the responsive sizing, intended only for resizable panel, only when the action panel has the `.o_resizable_panel`, which is specific to when action panel is being used inside resizable panel. Task-5804100 Before / After <img width="625" height="231" alt="Screenshot 2026-01-20 at 16 12 31" src="https://github.com/user-attachments/assets/10c02939-c4c1-47fa-82f8-4d8d037d3f0c" /> <img width="621" height="231" alt="Screenshot 2026-01-20 at 16 12 18" src="https://github.com/user-attachments/assets/eec1447c-cb42-4751-b17a-ff7b2e70b8e9" /> Forward-Port-Of: odoo/odoo#247636
This update resolves a technical issue that caused tracebacks when creating invoices for kit products using AVCO or FIFO valuation methods. The fix addresses a problem where the system incorrectly assumed a single product cost method for multi-component kits, leading to calculation errors. This ensures accurate cost of goods valuation for kit sales.
Original PR description
**Issue**: The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback **Steps to reproduce**: - Create a kit product with 2 components: - Inventory…
**Issue**:
The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback
**Steps to reproduce**:
- Create a kit product with 2 components:
- Inventory tracking enabled
- Use a category configured with AVCO and Perpetual (at invoicing) valuation
- Create a SO for the kit product and confirm it
- Go to the associated delivery and validate it
- Create and post the invoice on the so -> A traceback occurs
**Cause**:
In `_get_cogs_price_unit`, the code accesses `self.product_id.cost_method` assuming a singleton: https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/stock_move.py#L245 but `self.product_id` can be a multi-recordset when the sale line corresponds to a kit with multiple components https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/account_move_line.py#L67-L68 https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/sale_stock/models/account_move.py#L155-L156
which causes the traceback.
**solution**
The solution has been inspired by this:
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228
opw-5880383
Forward-Port-Of: odoo/odoo#247775This update resolves an issue preventing custom JavaScript code added to the website from functioning properly. A recent change removed a key identifier, causing the system to misinterpret custom scripts. This fix ensures that developers can reliably add and use their own JavaScript to enhance the website's functionality.
Original PR description
[FIX] website: enable custom javascript on website Steps to reproduce the problem: - Go to the "HTML/ CSS Editor". - Go to the JS tab. - Uncomment the example and save. -> Problem: the confirmation…
[FIX] website: enable custom javascript on website Steps to reproduce the problem: - Go to the "HTML/ CSS Editor". - Go to the JS tab. - Uncomment the example and save. -> Problem: the confirmation dialog does not appear. The problem is that since [1], `/* @odoo-module */` has been removed from the file as since [2], js files in `/static/src` and `/static/tests` are considered as odoo module without the need of the annotation `odoo-module`. In order to understand the problem, here is a summary of what happens when a custom js code is saved; - An attachment is created with the custom js code. - An asset is created to replace the user custom rules of `user_custom_javascript.js` by the one of the newly created attachment. Because the url of the newly created attachment looks like `/_custom/web.assets_frontend_lazy/website/static/src/js/user_custom_javascript.js`, the transpiler does not recognize it as an odoo module. task-5925607 [1]: https://github.com/odoo/odoo/commit/6d2fda172ec9cc7642abe9625ca486c7769e8297 [2]: https://github.com/odoo/odoo/commit/5f2c505836002ac7851c29c28d612f721d467bc4 Forward-Port-Of: odoo/odoo#247959
This update fixes an issue where duplicate GS1 serial or lot numbers could be created when using the 'Default GS1 Nomenclature'. The change allows for the creation of multiple serial numbers with the same name, ensuring data integrity and preventing errors in inventory tracking. This improves the reliability of our stock management system.
Original PR description
## Issue When using the *Default GS1 Nomenclature*, it is possible to create multiple lots/serial numbers with a same name if that name matches a barcode rule pattern. ## Steps to reproduce 1.…
## Issue
When using the *Default GS1 Nomenclature*, it is possible to create multiple lots/serial numbers with a same name if that name matches a barcode rule pattern.
## Steps to reproduce
1. Install *Inventory* (`stock`)
2. In Settings, enable *Lots & Serial Numbers* and set *Barcode Nomenclature* to *"Default GS1 Nomenclature"*
3. Create a product tracked *By Unique Serial Number* or *By Lots*
4. In Inventory > Products > Lots / Serial Numbers, create a lot/serial number named *"101"* and set the product to the one created in the previous step
- The name *"101"* matches the pattern of the rule *"Batch or lot number"* (`(10)([!"%-/0-9:-?A-Z_a-z]{0,20})`)
5. Create a second lot/serial number with the same name and the same product
6. **The second lot/serial number is succesfully created**
## Cause
When comparing a (new) `stock_lot.name` to existing `stock_lot`s, the potential rules at the start of the name are removed by the `gs1_decompose_extended` method [here](https://github.com/odoo-dev/odoo/blob/e06282df3a7482cc327d3124e6c2b1c8bc55c2f0/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L116-L125). This results in comparing **the end** of the new lot/serial number with **the entire** name of existings serials.
## Solution
Commit https://github.com/odoo/odoo/commit/3513b189a225ca52fc9fae94693f00f43ded71aa introduced the `skip_preprocess_gs1` context flag. This flag allows to skip the step that removes the start of the new lot/serial number before comparing it to existing serials.
## Test
The test for this commit is added in `stock_barcode` by [this PR](https://github.com/odoo/enterprise/pull/104720)
opw-5477003
Forward-Port-Of: odoo/odoo#244427This update resolves a problem that prevented users from sending invoices via PEPPOL, resulting in an error message. The fix ensures that attachments are correctly processed during the PEPPOL invoice sending process, allowing invoices to be sent without interruption. This improves the reliability of the accounting module for businesses using PEPPOL.
Original PR description
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an…
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an invoice: * Customer: [a Belgian customer with VAT] * Invoice Lines: [a line with a tax] - Confirm the invoice - Send the invoice via PEPPOL **Issue:** A UserError is raised: "You cannot remove parts of the audit trail.". **Cause:** The audit trail prevent modifying an attachment. When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment. During the process, "res_model" and "res_id" fields of the attachments are set to the message record. Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error. However, it fails because the value is still in cache. **Solution:** Invalidate these fields as it is done when sending the invoice without PEPPOL. https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20 opw-5916696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248220 Forward-Port-Of: odoo/odoo#247949
This update addresses a minor visual issue with the account partner warning message. The change improves the appearance of the warning line, making it more user-friendly. This ensures a cleaner and more professional experience for users managing their accounts.
Original PR description
Adjusting the warning line to look better. task-5909566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247342
This update resolves an issue where pressing the Tab key in the Live Chat interface would trigger an error. A safeguard has been added to the system to prevent this, ensuring a smoother and more reliable user experience when navigating messages with the Tab key.
Original PR description
**Steps to Reproduce:** Install 'Live Chat' Open any record with a chatter Click Send Message to focus the composer Press the 'Tab' key on the keyboard **Current behavior before PR:** A traceback occurs because the code attempts to read 'channel_type' from a channel field that is undefined in standard threads. **Desired behavior after PR is merged:** A guard is added to the channel field. Pressing Tab no longer causes an error. task-5925393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where serial numbers assigned to products during repair orders would disappear from the system. The fix ensures that serial numbers are correctly associated with stock movements, even when starting with generic stock, improving accuracy and traceability in repair processes. This prevents data discrepancies and ensures proper tracking of serialized items.
Original PR description
Steps to reproduce: 1. Create a storable product with tracking set to 'By Quantity'. 2. Update the Quantity on Hand (e.g., 100 units). 3. Change the product tracking to 'By Serial Number'. 4. Create…
Steps to reproduce: 1. Create a storable product with tracking set to 'By Quantity'. 2. Update the Quantity on Hand (e.g., 100 units). 3. Change the product tracking to 'By Serial Number'. 4. Create a Repair Order for this product. 5. Add a line, select a specific Serial Number, and click Save. 6. Observe that the serial number disappears. Cause: When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation. Solution: In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid. opw-5156267 Forward-Port-Of: odoo/odoo#248094 Forward-Port-Of: odoo/odoo#247150
This update corrects and enhances the tax descriptions and names used in the Belgian localization for Odoo's point-of-sale restaurant module. The changes include accurate translations, German translations, and a fix to ensure the 21% S.INC tax is correctly applied as an included tax. This ensures accurate reporting and compliance for Belgian businesses.
Original PR description
In this commit[^1] the tax descriptions and names for the Belgian localization were added/updated. However, some names or descriptions were either not fully correct, poorly translated, or not translated at all. In this commit, we revised them all and added German translations for everything as well. [^1]: https://github.com/odoo/odoo/commit/c7b39c5ad4afba7e61265773b87f500469ace91b Forward-Port-Of: odoo/odoo#248060 Forward-Port-Of: odoo/odoo#247036
This update fixes a technical issue that could have caused errors in the Point of Sale system. Specifically, it addressed a situation where accessing product information could lead to an endless loop if the same data was defined in multiple product models. This change ensures data is accessed reliably, improving system stability.
Original PR description
Before this commit, if a getter was defined in both product.product and product.template models, and the getter returned a falsy value (like false or an empty string), it could lead to infinite recursion when accessing the property. This was due to the way the models fell back to each other to retrieve the property value. opw-5886320 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246272
This update fixes a potential issue where invoices generated from Point of Sale (PoS) orders would incorrectly round amounts when cash rounding wasn't properly configured. Previously, if cash rounding was disabled or only applied to cash payments, the invoice would still be linked to the rounding method, leading to inaccurate invoice line totals. This change ensures invoices are only rounded when cash rounding is enabled, maintaining accurate financial reporting.
Original PR description
Before this commit, when a rounding method was set in the PoS, but the cash rounding was not enabled, or only enabled for cash payments and the order did not contain any cash payment, the generated invoice would still be linked to the rounding method. This could lead to unwanted rounding on the invoice lines. opw-5864642 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247223
This update resolves a bug that caused Odoo module updates to fail when encountering certain field types (like 'Char') during the update process. The fix adds a check to ensure fields are of the correct type ('selection' or 'reference') before attempting to access their 'ondelete' attribute, improving update stability.
Original PR description
Description of the issue/feature this PR addresses: Fix AttributeError that occurs during module updates when processing selection field deletions. Current behavior before PR: When updating modules, an `AttributeError` occurs when trying to access the `ondelete` attribute on fields that are not Selection fields: AttributeError: 'Char' object has no attribute 'ondelete' Desired behavior after PR is merged: Add validation to check if the field type is 'selection' or 'reference' before attempting to access field.ondelete as a dictionary. Skip processing for incompatible field types to prevent AttributeError. @moduon MT-13588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247971
A recent test failure was caused by a timing issue in the point-of-sale system. This update adds a brief pause to ensure that all necessary steps are completed before finalizing an order, particularly in scenarios involving local accounting (L10n). This prevents errors related to orders being marked as finalized prematurely.
Original PR description
The `test_point_of_sale_custom_tax_with_extra_product_field` test does a `PaymentScreen.clickInvoiceButton()` and then directly after that a `PaymentScreen.clickValidate()`. In l10n scenarios, the logic behind triggering the `toInvoice` field can take longer. This would cause the validation to execute before the `toggleIsToInvoice` finishes executing and then it would throw an error that the order was already finalized. This PR ads an extra wait on the `Invoice` button to make sure that the toggle is executed properly before finalizing the order. Runbot Error: [233024](https://runbot.odoo.com/odoo/runbot.build.error/233024) Task: [5897371](https://www.odoo.com/odoo/project/1737/tasks/5897371) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248191
This update corrects a reporting issue where refund orders were incorrectly displayed with positive amounts. Now, refund reports accurately show the negative value of the refund, ensuring accurate financial reporting and reconciliation. This change improves the reliability of our point-of-sale data.
Original PR description
Before this commit, the refund orders had positive amount in the report, which is not correct. opw-5821547 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248237
This update fixes a display issue where the kitchen printer incorrectly printed "Order" alongside self-order items and resolves a bug where the 'Send To Kitchen' button remained visible after orders were already processed. The changes ensure accurate order transmission and a smoother user experience for self-order operations.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table (Online Payment)…
Configuration:
-------------------------
- Restaurant Mode
- Self-Order Mode: “QR + Ordering”
- Service At: Table (Online Payment)
--------------------------------------------------------------------------------
Issue 1: Extra Order word print in KOT
---------------------
Steps to Reproduce:
1. Make an order using Self Order (QR).
2. Configure and enable the Kitchen Printer.
3. Check the KOT print it shows “Order Self-Order T2”.
Cause:
- The QWeb template always prefixed “Order” regardless of order type.
Fix:
- Added a condition to skip the “Order” label for self-order references:
--------------------------------------------------------------------------------
Issue 2: “Send To Kitchen” Button Visible even order in kitchen
---------------
Steps to Reproduce:
1. Open the Restaurant
2. Place a order from mobile menu and select a table.
3. In the Restaurant UI:
- Open that table. The "Send To Kitchen" button is still visible even
though the order was already sent to the kitchen and printed.
Cause:
- In self-order mode the order is not automatically synced after being sent to
the kitchen and print.
- As a result, the system still treats it as unsent, leaving the Order button
visible.
Fix:
- Synced the order state after sending it to the kitchen.
----------------------------------------------------
Task-5106704
Forward-Port-Of: odoo/odoo#246867
Forward-Port-Of: odoo/odoo#231005This update fixes an issue where keyboard navigation within the search bar would get stuck, preventing users from moving through other parts of the application. Now, keyboard navigation will correctly move forward from the search bar filter, ensuring a smoother and more intuitive user experience. This resolves a reported usability problem.
Original PR description
When navigating any view using keyboard navigation, the focus gets stuck on the search bar filter and cannot move forward. After this commit keyboard navigation will move forward from the search bar filter. Issue introduced by https://github.com/odoo/odoo/pull/208862 Task-5421313 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243000
This update fixes an issue where the user role wasn't properly set in the Point of Sale system when the 'pos_hr' module wasn't installed. This prevented errors when accessing user roles through the cashier interface, ensuring consistent and reliable functionality. This change improves stability and prevents potential issues related to user permissions within Point of Sale.
Original PR description
When the pos_hr was not installed, the user role was not set, and if the role was accessed with cashier._role, it was undefined. opw-5479742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243057
This update fixes an issue where combo product refunds weren't correctly handling orderlines with quantities exceeding the combo's total. Now, the POS accurately refunds the full quantity of each item within a combo, regardless of the individual orderline quantities. This ensures accurate refunds for complex combo orders.
Original PR description
When refunding a combo item, the 'To Refund' text would always show the same quantity for all the orerlines as for the combo. But combos could have orderlines with a higher quantity than the combo itself (i.e. 3 menus with 2 burgers each - 6 burgers in total. Now the POS would only let us refund up to the limit qty of the combo, so 3 instead of all 6 burgers) After the fix, we check the quantity of each line in the combo and we refund the full quantity (i.e. if you have a 3 menus with 2 burgers each - 6 burgers in total. The burgers will be divided per combo, so each menu refund will automatically refund 2 burgers.) Task-[5503962](https://www.odoo.com/odoo/project/1737/tasks/5503962) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244702
This update resolves an issue that occurred when users attempted to onboard ZATCA journals without a company street address. The fix corrects a data type error that prevented the system from processing OTP requests. This ensures smoother operation for users utilizing the l10n_sa_edi module.
Original PR description
This error occurs when attempting to set the "OTP" received from "ZATCA". Steps to reproduce: - Install `l10n_sa_edi` module > Switch to `SA Company` - Go to `SA Company` and remove `Street` - Journals > Open journal with type 'Sale' > ZATCA > Onboard Journal > Enter any OTP > Request Traceback: `TypeError- value argument must be a str` At [1], the error occurs because the company has an empty street field, causing the value argument to be a `boolean` instead of the expected `string`. [1]- https://github.com/odoo/odoo/blob/40a0b44231fd9a725ccf3667c4992e691e24cde7/addons/l10n_sa_edi/models/certificate.py#L71 sentry-7185302332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248035 Forward-Port-Of: odoo/odoo#243525
This update corrects a technical issue in our Latin American Point of Sale (POS) localization modules (ar_pos, pe_pos) that prevented new features from loading correctly. The fix ensures that all localization modules, including those used with other Odoo modules, function as expected. This resolves a potential compatibility problem.
Original PR description
Problem: - In the `l10n_ar_pos` and `l10n_pe_pos` modules, the `_load_pos_data_fields` method of the `l10n_latam.identification.type` model was missing a `super()` call. - Due to the missing…
Problem: - In the `l10n_ar_pos` and `l10n_pe_pos` modules, the `_load_pos_data_fields` method of the `l10n_latam.identification.type` model was missing a `super()` call. - Due to the missing `super()`, the method chain was broken, preventing other modules extending the same method from being executed. - This issue affected `l10n_gt_edi_pos` when installed together with these modules (see related PR). Context: - The issue was not faced earlier because existing localizations extending this method were loading the same field `name`, so the missing `super()` did not cause functional differences and tests continued to pass. - The problem became visible when `l10n_gt_edi_pos` needed to load an additional field `country_id`, which was skipped due to the broken method chain. Solution: - Added the missing `super()` calls in both modules to restore proper method chaining. related PR https://github.com/odoo/enterprise/pull/103767 task-4393614 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242985
This update resolves an issue where the rental scheduling feature incorrectly limited the number of products grouped together. Previously, it only considered groups if the number of expanded products was strictly less than a set limit. Now, the system correctly includes all products in the grouping, ensuring accurate rental scheduling for all product quantities. This improves the usability of the rental module.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Create exactly 19 rental products. 2. Go to the rental schedule, and group by products. 3. Observe that all 19 product are used as groups. 4. Create one more product. Total: 20. 5. Go to the rental schedule, and group by products. Issue ----- Only the products with actual order line linked to them are used as groups, even if there isn't more products than the hard limit set on the gantt view (`sale_renting.sale_order_line_gantt_schedule`). Cause ----- In d5a6e97abab04282c7a69093cd790b539a958241, the expanded groups are taken into account only if `len(expand_groups) < limit`. However, this should be a less than _or equal_ condition. https://github.com/odoo/odoo/blob/d5a6e97abab04282c7a69093cd790b539a958241/addons/web/models/models.py#L345-L349 Solution -------- Use `<=` as the condition. opw-5887837 Forward-Port-Of: odoo/odoo#248001
This update corrects a validation error that appeared when users deleted all content blocks from a product description. The issue stemmed from leftover whitespace in the HTML structure, which triggered an 'empty document' notification. The fix ensures that empty elements are cleaned up after content removal, preventing this error and maintaining proper product description formatting.
Original PR description
Steps to reproduce: =================== 1- Go to Website > eCommerce > Products 2- Open any product and click "Edit website" 3- Add a lot of content blocks (contact form etc..) & save 4- In the…
Steps to reproduce: =================== 1- Go to Website > eCommerce > Products 2- Open any product and click "Edit website" 3- Add a lot of content blocks (contact form etc..) & save 4- In the product description, delete all content blocks and keep the last one 5- Click Save ->"Document is empty" validation error appears Cause: ====== When saving an HTML field after deleting all content, whitespace text nodes (like newlines) may remain in the DOM element. The _copy_custom_snippet_translations lang_value might have this whitespace as the content, which will cause "Document is empty" error when the content is parsed by fromstring(). This didn't occur before the migration because the previous implementation called _onSnippetRemoved after a content block was deleted, and that handler removed any empty elements. https://github.com/odoo/odoo/blob/8d66c79ecf74900af1c5b003723363be3d52cbc8/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L1370 Solution: ========= After removing the content block, we should also do a cleanup. opw-5263743 Forward-Port-Of: odoo/odoo#241291
This update fixes a potential issue with how Odoo handles translations, specifically when translating fields. Previously, Odoo could sometimes receive translation values with inconsistent numbers of terms, leading to display problems. This change ensures that Odoo always checks for the correct number of translations, resulting in more accurate and reliable translations across the system.
Original PR description
Add missing ``check_translations`` context when translating fields. This prevents fetching dalay translation values that may have a different number of terms and cause inconsistencies. 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-pr Forward-Port-Of: odoo/odoo#248223
This update fixes an issue where the barcode scanning process wasn't correctly creating quality checks for products tracked by lot. The change ensures that each unique lot within a receipt generates a separate quality check point, improving inventory accuracy and quality control. This ensures that all products are properly assessed when using the barcode scanning feature.
Original PR description
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking…
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking enabled and set a barcode reference. * Create a quality control point for this product with following configuration: * Operation: *Receipts* * Control per: *Quantity* * Control Frequency: *All* * Product: the previously created lot-tracked product. * Create a receipt for this product with a quantity of 6 and `mark as todo`. * Open the *Barcode* app and process the receipt. * Scan the product barcode. * Scan some quantity of the product with lot *LOT01* and put those units into a package(Put-In-Pack). * Scan the remaining quantity with lot *LOT02* and put those units into a different package(Put-In-Pack). * Click on **Quality Checks**. **Observed behavior:** * Only one quality check is created, even though the receipt contains two different lots that should each generate a quality check. **Cause:** * In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is equal to quantity(Demand). * During the `write` operation, quality checks are created only for move lines that are not picked, which prevents creating a quality check for each lot. * Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71 **Fix:** * Ensure that quality check points are generated correctly when validating products through the Barcode app using the Put in Pack option. --- opw-5405221 Forward-Port-Of: odoo/enterprise#105930 Forward-Port-Of: odoo/enterprise#102714
A technical error in the Chinese (zh_CN) language installation for the account_reports module was causing installation problems. This update manually corrected a corrupted PO file, resolving the issue and ensuring proper localization functionality for Chinese users.
Original PR description
Currently error is occurs when the user tries to install the`Chinese (zh_CN)` language after installing the `account_reports` module. Error: `Syntax error in po file (line 430): unescaped double quote found` This issue is caused by a bug in Weblate that incorrectly escapes quotation marks (\"). As a result, the PO file becomes corrupt because the quotation mark that should terminate the string is improperly escaped. This commit resolves the issue described above by manually correcting the affected PO file. sentry-6976676644
This update resolves a problem where the ICP report generation failed due to a missing link between return types and the ICP report. The fix now searches for VAT report returns instead, ensuring the report generation process completes successfully. This improves the reliability of the ICP report for Dutch businesses.
Original PR description
Since no return type has a link to ICP report, the tax return check will fail each time. This commit changes this by looking for VAT report returns. opw-5491728 Forward-Port-Of: odoo/enterprise#106955
This update fixes an issue where a distracting helper message was displayed in the bank reconciliation journal when there were no entries. The change hides this message, creating a cleaner and more user-friendly experience, particularly on mobile devices. This improves the overall usability of the accounting module.
Original PR description
Before this commit, in the bank reconciliation journal, the no-content helper remained visible when the quick-create view was opened and there were 0 entries. This was unexpected behavior and caused overlapping issues, especially on mobile views. With this commit, the no-content helper is hidden whenever the quick-create view is open and there are 0 entries. task-5470591
This update fixes an issue where the Odoo bot was incorrectly linked to statement lines when the partner name was 'ODOO'. This ensured accurate reporting and data processing for OdooBot, preventing potential misinterpretations of financial information. The change improves the reliability of the bot's functionality.
Original PR description
When the partner_name was "ODOO" the retrieve partner was linking the statement line to OdooBot. no task id Forward-Port-Of: odoo/enterprise#106933 Forward-Port-Of: odoo/enterprise#106879
A technical issue causing errors when sending monthly tax returns to HMRC has been resolved. The fix addresses a problem where timezone information was incorrectly being passed between the JavaScript and Python components, leading to a traceback. This ensures accurate tax return submissions.
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_uk_reports_cis. 2. Setup hmrc test environment. 3. Try Sending the a monthly tax return to hmrc. 4. You'll have a traceback of the form `expecting only datetimes with no timezone: '2025-12-05T00:00:00.000+01:00' ` **CAUSE** The send button for monthly return is a js widget, which get data from the monthly_return_wizard models and then pass it to `action_send_montlhy_return`. It creates a Luxon datetime in the js for date_from date_to, with a timezone. When the dates are passed back to the python, the still contains the timezone which leads to the traceback. opw-5783030 Forward-Port-Of: odoo/enterprise#106952
A test for the Shiprocket delivery module failed due to a default pricelist being applied, which incorrectly calculated the total order amount. This fix ensures that the test accurately reflects the expected calculation by forcing an empty pricelist during testing, resolving the discrepancy.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692
Forward-Port-Of: odoo/enterprise#105180This update corrects a bug in the task scheduling feature. Previously, tasks started on specific dates would incorrectly limit their duration, resulting in shorter allocated times. The fix ensures tasks automatically extend to cover the full required hours, even when spanning multiple days, improving scheduling accuracy.
Original PR description
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result,…
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours. Source: When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28). However, these four days are not enough to cover 40 hours. The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December. Solution: Remove already-used intervals before recomputing the schedule. opw-5364327 Forward-Port-Of: odoo/enterprise#107043 Forward-Port-Of: odoo/enterprise#101262
This update resolves an issue where duplicate GS1 serial/lot numbers could cause incorrect stock lot queries. The fix ensures that lot names are correctly processed, regardless of whether the 'stock_barcode' app is installed, preventing inaccurate data retrieval.
Original PR description
## Issue When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern. ## Fix The fix related to this…
## Issue When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern. ## Fix The fix related to this commit is introduced by [this PR](https://github.com/odoo/odoo/pull/244427). ## Problematic flow The problematic flow starts in the `StockLot._check_unique_lot` method when calling `self._read_group`. At that point, the domain is still correct: it contains the product_id and the (correct) name for the lot we try to create. https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/stock/models/stock_lot.py#L104-L111 In the `BaseModel._read_group` method, the query is defined by the `self._search` method. At that point, the domain is the same as in the previous step, so it is still correct. https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/odoo/orm/models.py#L1902-L1904 Now the flow differs depending on whether the `stock_barcode` app is installed or not. If it is, the `stock_barcode/StockLot._search` method is called: https://github.com/odoo/enterprise/blob/24fea3814b95144953fb809d10bf6a62906c06fd/stock_barcode/models/stock_lot.py#L11-L15 This is the method that calls the `BarcodeNomenclature._preprocess_gs1_search_args` which uses the `skip_preprocess_gs1` context flag: https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L149-L151 **This flow makes the query returned by `self._search(domain)` erroneous, as the start of the name of the lot is removed further down the execution of the `preprocess_gs1_search_args` method.** ### If stock_barcode is not installed The `self._search` method called in the BaseModel will not call `stock_barcode/StockLot._search`, but instead it calls `BaseModel._search`. This totally skips the problematic gs1 flow. opw-5477003 Forward-Port-Of: odoo/enterprise#104720
This update resolves a bug where incorrect product quantities were sometimes sent to the kitchen display when using the numpad in the POS. The fix ensures the system waits for quantity updates before submitting orders, preventing errors in order transmission and improving order accuracy. This resolves a failing test and ensures reliable POS operations.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We are waiting for the orderline to be updated with the correct quantity before submitting the order. X-original-commit: 5ebd1ca99dddbbc62aff90202491562114c0c0dc Forward-Port-Of: odoo/enterprise#106600
This update resolves an issue where guest users purchasing subscriptions would experience payment failures due to Odoo attempting to archive their customer records. The fix ensures guest customers are no longer archived when linked to a subscription, allowing successful payment processing. This improves the eCommerce subscription experience for all users.
Original PR description
When purchasing a subscription from the eCommerce as a guest user, the payment fails because Odoo attempts to archive the subscription customer, which causes issues. To fix this, guest customers are no longer archived when they are linked to a subscription. opw-5475479
This update resolves an issue where users designated as 'invoice' within the subscription system were inadvertently able to view invoices. The fix ensures that only authorized users can access invoice information related to subscription orders, improving data security and accuracy. This change impacts the way subscription invoices are handled.
Original PR description
Forward-Port-Of: odoo/enterprise#99410
This update stops OCR (Optical Character Recognition) from being automatically applied to split expense documents. This prevents the system from making redundant requests to external services, which can unexpectedly increase user costs, especially when automatic digitization is enabled. It ensures users are only charged for actual document processing.
Original PR description
OCR should only be performed on the original document. Enabling it on splits leads to redundant OCR requests and unnecessary IAP credit consumption. This is particularly important when automatic digitization is enabled, as it triggers a paid request for every split generated, leading to unexpected costs for the user. opw-[5644869](https://www.odoo.com/odoo/unassigned-tasks/5644869) Forward-Port-Of: odoo/enterprise#105756
This update resolves an error that occurred when grouping accounts by their status in the Chart of Accounts view. The issue stemmed from an incorrect SQL query attempting to order by 'NULL', which caused a technical error. This fix ensures the Chart of Accounts view functions correctly for all users.
Original PR description
When grouping by the ``Status (audit_status)`` field in the Chart of Accounts view, A traceback will appear.
Steps to reproduce the error:
- Install ``Accounting`` module
- Go to Accounting > Configuration > Chart of Accounts
- Group By: Status (audit_status) field
Traceback:
```py
psycopg2.errors.SyntaxError: non-integer constant in ORDER BY
LINE 1: ..."."res_company_id" IN (1)) GROUP BY NULL ORDER BY NULL ASC ...
```
https://github.com/odoo/enterprise/blob/999880daae7495fb049afafe9098bd45ee8c9d4c/account_reports/models/account.py#L164-L168
In the main view of ``acount.account``, ``working_file_id`` is not available in the context,
So, ``working_file`` becomes False and ``status_query`` will be empty, and it returns ``SQL("NULL")``.
So, ordering by NULL leads to the above traceback.
sentry-7250293611This update re-exports several POT files (account_reports, documents, sign) to trigger a new message merge in Odoo. These changes were necessary to address recurring line wrapping issues identified in Weblate, ensuring accurate translations across multiple languages.
Original PR description
*account_reports,documents,sign Several CJK language line wrapping issues popped up again in Weblate. We fixed them there, but Weblate needs the POT file to change in order to trigger a new msgmerge.
This update corrects a minor error in the HR payroll calculations. It replaces a problematic reference with a more reliable variable, ensuring accurate payroll processing. This change enhances the stability and reliability of the payroll system.
This update corrects an issue where payslip calculations were occasionally inaccurate, particularly when recomputing payslips. The fix ensures that net pay computations are consistently correct, improving payroll accuracy and reducing potential discrepancies. This was triggered by a runbot test failure and is a routine maintenance update.
Original PR description
Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/237852 Task-5881260
This update resolves an issue where automated tests were failing due to the SEPA module automatically installing during chart of account loading. The fix disables automatic module installation during testing, preventing database changes and ensuring consistent test results. This improves the reliability of our automated testing process.
Original PR description
**PROBLEM** https://github.com/odoo/enterprise/pull/106033 PR above fixes the auto install of the sepa module when loading a chart of account of some country. However, installing modules during tests is not allowed (it commits real transaction to the db). It didn't occur during the "daily" runbot because they start the tests with all modules installed (sepa module included). **REPRO STEPS** 1. On a db without the sepa module installed, run the test function .test_bank_account_code_prefix (in account module). 2. The test will fail because it load a chart of account and then try to install the sepa module. **FIX** Deactivate the auto install when running tests. runbot-238921 Forward-Port-Of: odoo/enterprise#107102
This update fixes an issue preventing the correct import of Zengin accounting files. The validation process now allows a wider range of characters, including standard hyphens and alphanumeric text, aligning with the Zengin specification. This ensures all valid Zengin files can be imported without errors.
Original PR description
Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text. This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include: - Uppercase alphanumeric characters (A-Z, 0-9) - Standard symbols (e.g., -, ., /, (, ), etc.) Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite task-5928087 Forward-Port-Of: odoo/enterprise#107007
This update corrects a problem where certain characters (like accented letters) were not properly encoded in the XML files generated for DIAN invoices. This prevented invoices from being correctly processed by the DIAN tax authority, leading to potential errors and delays. The fix ensures invoices are transmitted accurately.
Original PR description
Some characters are not well encoded in dian xml Steps: - Activate the DIAN Demo Mode - Create a partner that has a "stress" or a "ñ" in their address - Create and confirm an invoice for partner - Open send and print wizard and select 'email' and 'dian' - Unzip the generated zip file and open the xml file -> Characters are wrongly encoded in the embedded xml opw-5883880 Forward-Port-Of: odoo/enterprise#107009
This update corrects a bug in the l10n_mx_edi_pos module that caused incorrect refund calculations when global discounts were applied. Previously, the system misidentified refunds as exceeding the original order total. Now, refund calculations accurately account for discounts, ensuring proper financial reporting.
Original PR description
Before this commit, when refunding an order with global discounts, the refund total was compared against the original order total without considering the discounts. While the reversed discount line would be added to the refund, the system could incorrectly flag the refund as exceeding the original order total. opw-5492686 Forward-Port-Of: odoo/enterprise#105631
This update resolves an issue where the German tax report export was missing required data due to a recent layout change. The team has restored the necessary values to ensure accurate and compliant tax reporting. This fix is crucial for businesses using Odoo Enterprise to meet German tax regulations.
Original PR description
After the change in the german tax report layout, we incorrectly removed some values from the report export. Add missing values back into the report. original commit: https://github.com/odoo/enterprise/pull/97486/changes/0c579c824b1bf2eb643d2314b38d108cf72139c6 opw-5481368 Forward-Port-Of: odoo/enterprise#106878
Code cleanup and technical improvements
This update optimizes how Odoo calculates employee dates, significantly speeding up processing for large teams. The change avoids multiple database queries, reducing processing time and improving overall HR system performance. This addresses a previous performance bottleneck related to version calculations.
Original PR description
Use batch computation for `_compute_dates`. Getting all values of `hr_presence_state` need that field. Implement `hr_presence_state` using *compute_sql* to have one implementation and add a limit for big databases because "Ugly hack". Related task that should be batched: #248045 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr