Daily updates from Odoo
Monday, May 11, 2026
234 changes
6 changes
Resolved issues and error corrections
This update fixes an issue where Egyptian VAT invoices were not including the full street address information. The system now correctly combines street and street2 fields, ensuring accurate data is sent to tax authorities. A new test has been added to guarantee this fix.
Original PR description
## Description of the issue/feature this PR addresses: ETA receiver address was only using partner.street field, causing street2 information to be dropped in generated JSON payloads. ## Current behavior before PR: When generating ETA invoices, the receiver address street field only includes partner.street, ignoring partner.street2 field. ## Desired behavior after PR is merged: Street and street2 fields are concatenated with a single space in the receiver address. A regression test has been added to ensure the concatenated street value is correctly generated. task-6133587 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where user avatars appeared stretched on user profile pages after adapting the Odoo code to the m3.1 version. The fix ensures that user avatars display correctly, providing a consistent and professional user experience. This improves the visual quality of user profiles.
Original PR description
Before this commit, the user's displayed avatar was unexpectedly stretched after adapting the code to m3.1. Steps to reproduce: - Go to Settings > Users & Companies > Users - Select a user from the list -> The user's avatar appears stretched (bug) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue that prevented users from leaving live chat channels without triggering an error. The fix ensures the system only removes a user's access once when they leave a channel, improving stability and the user experience. This resolves a previous access problem.
Original PR description
When a non-livechat user leaves a livechat channel after being invited, an access error occurs. This is due to `leaveChannelRpc` being called twice: once in `_onClose`and again in `leaveChannelProcess`. The first call removes the membership, while the second attempts to access the channel without proper rights, triggering the error. This commit fixes the issue by ensuring that `leaveChannelRpc` is only called once when leaving the channel. Task-[6072247](https://www.odoo.com/odoo/project/1519/tasks/6072247) Forward-Port-Of: odoo/odoo#262020 Forward-Port-Of: odoo/odoo#257328
This update fixes an issue where payment methods weren't correctly displayed for branch companies within Odoo. Previously, the 'Payment Method' field in partner and account move forms didn't show options from the parent company. Now, payment methods from the parent company are consistently available when working with branch companies, ensuring accurate financial processing.
Original PR description
**Steps to reproduce:** - Install Contacts and Accounting - Create a branch company - Switch to the branch company **Issue:** In the partner form, "Payment Method" field doesn't propose the methods coming from the parent company. Same issue on the account move form. However, in the payment wizard opened from an invoice, the payment methods from the parent company are available. The behavior should be consistent. The payment methods from the parent company should be available from a branch company opw-6001573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260168
This update resolves a crash issue that occurred when installing the `sale_project` module on empty runbot instances. The problem stemmed from shared database configurations causing incorrect selections to be imported. The fix ensures selections are handled safely without impacting other databases, improving stability and installation success.
Original PR description
## Description of the issue this commit addresses: When a user attempted to install `sale_project` on an empty runbot instance, the entire runbot would crash. ## Root Cause: The global variable…
## Description of the issue this commit addresses: When a user attempted to install `sale_project` on an empty runbot instance, the entire runbot would crash. ## Root Cause: The global variable storing the available `billable_type` selections in `sale_project` (`BILLABLE_TYPES`) was being modified by `sale_timesheet`. Since runbot workers are shared across multiple databases, these modified selection values leaked from one database to another. When these values appeared in databases that did not have `sale_timesheet` installed, the installation of `sale_project` would fail. ## Desired behavior after this commit: The global variable storing `billable_type` is no longer imported or modified within `sale_timesheet`. Instead, the `selection_add` attribute is used to extend `billable_type` safely and without cross‑database side effects. task[-6178239](https://www.odoo.com/odoo/project/4105/tasks/6178239) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where a project's warning status was incorrectly calculated due to an outdated data format. The fix ensures all projects display a default 'false' warning status, streamlining the system. This change is considered low impact and will be addressed in the main Odoo release.
Original PR description
Prior to this commit, the `compute` method was getting all the projects that had missing employee sale order line mappings through an SQL query. The result of the query is supposed to be a tuple but was treated as an array of `Integer` ids causing trouble while browsing and then later writing the value for the field. Since the field `warning_employee_rate` is not used in the views we can assume that the warning will be `False` for all projects and remove this field later on Master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263866
5 changes
Resolved issues and error corrections
This update resolves an error that occurred when installing the Saudi Arabia EDI module, specifically related to demo data setup. The issue stemmed from deleting demo invoices, which caused a problem when the system attempted to update related records. The fix ensures the system handles missing records gracefully during the demo data update process.
Original PR description
Currently, error occurs when user tries to install Saudi Arabia EDI module. Steps to replicate: - Install `l10n_sa` with demo and switch to SA company. - Open Invoices > `INV/2026/00001` > Reset to…
Currently, error occurs when user tries to install Saudi Arabia EDI module.
Steps to replicate:
- Install `l10n_sa` with demo and switch to SA company.
- Open Invoices > `INV/2026/00001` > Reset to draft > Delete.
- Open Invoices > `INV/2026/00002` > Reset to draft > Delete.
- Install `l10n_sa_edi`.
Error:
```
File '/home/odoo/src/odoo/saas-19.2/addons/l10n_sa_edi/demo/account_demo.py', line 16, in _l10n_sa_edi_onboard_sa_sale_demo
self.ref('demo_sa_invoice_1', raise_if_not_found=False)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'
```
Cause:
- As the user deleted `INV/2026/00001` (linked to `demo_sa_invoice_1`) and `INV/2026/00002` (linked to `demo_sa_invoice_2`), [here] when we try to create a recordlist to update we get this error.
Solution:
- Avoided direct concatenation of `self.ref(...)`, which may return None.
- Iterated over the expected IDs, fetched records safely, and skipped missing ones before processing.
[here]: https://github.com/odoo/odoo/blob/b8bcaa6af2531f49654d804231942b6af2261933/addons/l10n_sa_edi/demo/account_demo.py#L15-L20
sentry-7458234787
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where the 'Import records' option was missing from the Journals list view. The change was caused by a setting that unintentionally restricted importing. The fix removes this restriction, restoring the previously available functionality.
Original PR description
**Steps to reproduce:** * Go to Accounting App. * Open the Journals list view (Configuration > Accounting > Journals). * Click on the "Action" (cog) menu. **Observed behavior:** * The "Import…
**Steps to reproduce:**
* Go to Accounting App.
* Open the Journals list view (Configuration > Accounting > Journals).
* Click on the "Action" (cog) menu.
**Observed behavior:**
* The "Import records" option is completely missing.
**Cause:**
* In [commit](https://github.com/odoo/odoo/commit/082c70e6d411afd28efffbaf437d8b56d8351e38), `create="False"` was added to the `account.journal` list view to hide the "New" button, intentionally redirecting users to use the journal creation wizard instead.
* However, Odoo's standard `base_import` framework evaluates the XML architecture of the view (`config.viewArch.getAttribute("create")`). Because `create="False"` was set on the view, the framework automatically hid the `Import records` action menu item, assuming importing was entirely restricted.
**Fix:**
* Remove `create="False"` from the XML view architecture so the `base_import` framework evaluates it correctly and displays the "Import records" action.
* Introduce a custom `js_class` (`account_journal_list`) for the journal list view. By explicitly setting `this.activeActions.create = false` inside the controller's `setup()` lifecycle method, we can safely hide the inline "New" button on the UI layer without interfering with the backend XML architecture evaluation.
Ticket [link](https://www.odoo.com/odoo/project.task/6132990)
opw-6132990This update corrects a bug where a project warning calculation was incorrectly processing data, leading to potential display issues. The fix ensures all projects will display a 'no warning' status, and the unused field will be removed in a future update. This improves data accuracy and stability.
Original PR description
Prior to this commit, the `compute` method was getting all the projects that had missing employee sale order line mappings through an SQL query. The result of the query is supposed to be a tuple but was treated as an array of `Integer` ids causing trouble while browsing and then later writing the value for the field. Since the field `warning_employee_rate` is not used in the views we can assume that the warning will be `False` for all projects and remove this field later on Master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263866
This update resolves an error that occurred when posting journal entries using accounts shared between companies during an open audit period. The fix prevents an AccessError by ensuring users have the correct permissions to access audit records, allowing for accurate reporting across multiple companies. This improves stability and prevents disruptions to financial processes.
Original PR description
Posting a journal entry using an account shared between multiple companies during an open audit period raises an AccessError. Steps to reproduce: - Configure an account to be shared between Company A and Company B. - Add Company A and Company B in 'Companies' - In the mapping tab, add a code for each company - In Company A, create a tax audit for a specific fiscal period. - Switch to Company B and keep just Company B selected. - Create and post a journal entry using the shared account within the same date period. Issue: An AccessError is raised when posting the move. The system attempts to check the status of the audit records linked to the shared account, to which the user in Company B does not have read access. opw-5993450 Forward-Port-Of: odoo/enterprise#116829 Forward-Port-Of: odoo/enterprise#115454
This update resolves an issue in our testing environment where a key piece of information related to product routes wasn't visible. The change ensures that test setups correctly access this data, preventing errors and allowing for more reliable testing of the manufacturing process. This improves the accuracy of our test results.
Original PR description
The setup in `TestMultistepManufacturingWarehouse` was failing with: ``` AssertionError: field 'route_ids' is not visible ``` This happens because the `route_ids` field on the product form view is only visible when `has_available_route_ids` is True, which depends on having at least one `product_selectable` route. This commit enables `product_selectable` on those routes in the test setup, so that `route_ids` becomes visible and the Form helper can access it safely. [RB-232576](https://runbot.odoo.com/odoo/error/232576) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237293
1 change
Resolved issues and error corrections
This update corrects a bug where a project field was incorrectly displaying a warning due to an outdated database query. The fix ensures the warning is now consistently set to 'false' for all projects, streamlining the system. This change is considered low impact.
Original PR description
Prior to this commit, the `compute` method was getting all the projects that had missing employee sale order line mappings through an SQL query. The result of the query is supposed to be a tuple but was treated as an array of `Integer` ids causing trouble while browsing and then later writing the value for the field. Since the field `warning_employee_rate` is not used in the views we can assume that the warning will be `False` for all projects and remove this field later on Master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263866
3 changes
Resolved issues and error corrections
This update resolves an issue where Italian EDI bank account imports weren't automatically creating new bank accounts in the system. The fix ensures that bank accounts are now created and properly assigned to the corresponding commercial partner, streamlining the accounting process. This improvement addresses a previous bug impacting Italian business users.
Original PR description
The Italian EDI import didn't create new bank account by itself. IBAN info was just logged in the chatter, leaving it up for the accountant to create the bank account record. The bank account should be created and assigned to the corresponding commercial partner and set to not trusted yet. Enterprise PR: odoo/enterprise#112794 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/odoo#263524 Forward-Port-Of: odoo/odoo#254505
This update resolves a test failure related to importing partner and bank account data for Italian reporting (l10n_it_reports). The change restores the test data to a consistent state, ensuring the tests continue to run successfully. This prevents disruptions to the reporting functionality.
Original PR description
The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#116726 Forward-Port-Of: odoo/enterprise#112794
This update corrects a bug where the total tax amount on purchase bills was incorrectly recalculated and overwritten after manual adjustments. The fix prevents this by temporarily disabling automatic tax synchronization when creating price difference lines, ensuring accurate tax reporting. This improves the reliability of financial data.
Original PR description
**Steps to reproduce:** - On a new company, activate automatic valuation and anglo-saxon accounting. - Create a new product, and set the cost to 5. - On the product category, set the costing method…
**Steps to reproduce:** - On a new company, activate automatic valuation and anglo-saxon accounting. - Create a new product, and set the cost to 5. - On the product category, set the costing method to AVCO and the valuation to automatic. - Create a Purchase Order for the product, confirm it and recieve it, but don't create a Bill yet. - Create a sales order with the same quantity as the purchase order, and deliver it. - Now create a bill for the original Purchase Order, and change the price to 6. - Manually change the total tax amount on the Bill, and then post it. **Issue:** After posting the Bill, the value set manually on the total tax is recomputed and overwritten. This is because the price difference between the bill and the original cost creates two new price difference lines on the bill, and this triggers the move sync to recompute the tax. **Solution:** Set the context `skip_invoice_sync` to True when creating the price difference lines. opw-5478005 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259331
4 changes
Resolved issues and error corrections
This update simplifies how quality points are applied to products and product categories. Previously, users could apply points to multiple categories, but now they must select one. Leaving the field blank now applies the quality point to all products or all product categories, providing a clearer and more streamlined process.
Original PR description
Previously, quality points could apply to products, product categories or both. Now the user has to pick one of the two. Picking one of the two options but leaving the field empty means it applies to all products or all product categories. Task ID: 5380755
This update fixes a rendering issue within Odoo's reporting modules, specifically related to how text fields handle directionality. The change ensures that text fields consistently use the Unicode BiDi algorithm to determine text direction, preventing inconsistencies in reports. This improves the accuracy and visual quality of reports.
Original PR description
`IrQwebFieldText` now injects `dir="auto"` on every rendered element so the Unicode BiDi algorithm can detect the correct base direction from the first strong character, rather than having it overridden by ancestor CSS `direction: ltr`. Since the test verifies actual rendered HTML output, the expected strings must reflect the new attribute the framework now emits for all text widget fields. opw-5884712
This update removes a restriction that previously required Lazada products to be 'storable'. When stock synchronization with Lazada is disabled (as is common), tracking stock levels is unnecessary. This change now allows businesses to list all product types on Lazada, regardless of whether they require stock management.
Original PR description
Lazada items previously required products to be of type 'storable'. This restriction is unnecessary when stock synchronization is disabled, since no stock tracking is performed in that case. opw-6173986 Forward-Port-Of: odoo/enterprise#116833 Forward-Port-Of: odoo/enterprise#116543
This update resolves a test failure caused by an expired document range error when invoice dates are set to 2027 or later. The team applied a temporary fix – freezing the test's time – to ensure the tests pass and the core functionality remains stable. This prevents potential disruptions during development.
Original PR description
Problem: Tests are failing from a ValidationError, signaling that the document range expired, when the invoice date is 2027 and onwards. To resolve the bug, freeze_time needs to be applied on the tests. Related PR: https://github.com/odoo/enterprise/pull/112814 runbot-build-error-243527 Forward-Port-Of: odoo/enterprise#116099
4 changes
Resolved issues and error corrections
This update resolves a problem preventing the import of Simplified Invoices (invoices without partner addresses). The issue stemmed from a change in the XML structure and was temporarily addressed in a separate branch. This fix ensures simplified invoices can now be correctly imported into the system.
Original PR description
After PR odoo/odoo#254505, support for Simplified Invoice (no address of the partner, different XML structure and XSD) is broken up to `saas-18.2`. Fixing it with a more relaxed reading of the XML structure, finding the nodes where they actually are. In `saas-18.3`, a newer test using a simplified invoice was breaking, so I'm backporting part of that. I've made the code more similar to the one in [`saas-18.3`](https://github.com/odoo/odoo/pull/263831) in the process. (See the `postal_address` required by the `_import_partner` function there)
This update eliminates redundant logging messages within the account_edi_ubl_cii module. Previously, similar log entries were repeated multiple times, which didn't provide valuable insights. Removing these duplicates streamlines logging and improves overall system performance.
Original PR description
Before this commit, we had repeated logs (n-times if we had similar lines) but this doesn't help too much. To avoid this we decided to remove duplicated messages Task-None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that the General Ledger export aligns with the search filters applied in the user interface. Previously, the export displayed a different set of accounts due to a mismatch in how search terms were processed. This change corrects the export functionality to accurately reflect the user's search criteria.
Original PR description
When applying a search filter in the General Ledger, the lines displayed in the UI differ from the ones exported. The discrepancy comes from the fact that the UI search bar filters lines using a simple "contains" logic on the displayed line name, while the backend export relies on the account model’s `_name_search` behavior, just as in the chart of accounts. For example, searching for "40" displays the accounts 400000, 400010, and 124000 but the last one (124000) is not is in the export results. task: 5917435 Forward-Port-Of: odoo/enterprise#107928
This update resolves a bug where invoices created from timesheeted sales orders incorrectly displayed product quantities. The fix ensures that invoiceable quantities are recalculated each time an invoice is created, regardless of provided dates, resulting in accurate invoicing for service-based sales.
Original PR description
Steps --------- 1. Install Accounting, Sale and Timesheet 2. Create 2 product a. Product A - storable - invoiced on Ordered Quantity b. Product B - service - create a task on order - invoice on…
Steps
---------
1. Install Accounting, Sale and Timesheet
2. Create 2 product
a. Product A - storable - invoiced on Ordered Quantity
b. Product B - service - create a task on order - invoice on
timesheeted
3. Create an SO with 3 product A and 3 product B
4. Add a timesheet line for 1 hour of product A - can be done thanks to
the button appearing on the SO at confirmation
5. Create Invoice
6. Don't add dates to the wizard and confirm -> Both product appear
7. Add date range that do NOT include the timesheeted lines -> Only the
storable product appear
8. Repeat step 6 -> Only the storable product appear
Problem
---------
During the creation of the invoice, the invoiceable lines would get
computed dates where provided to the wizard
(`sale.order.line.qty_to_invoice`). When no dates were provided, we
would not manually trigger the invoiceable lines recomputation and were
relying one the data store in cache.
Solution
---------
Force the invoiceable quantity recomputation upon each invoice creation.
opw-6001094
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr11 changes
Resolved issues and error corrections
This update resolves an issue where Swedish financial data files were not importing correctly due to encoding differences. The fix ensures that account names with special characters (like 'Ö') are accurately imported, preventing data loss and ensuring correct financial reporting for Swedish customers. This improves data integrity and accuracy.
Original PR description
Issue: Non-ASCII charatcter from sie file were lost on import. Steps to reproduce: - in a Swedish company - import the SIE4 exemple file from sie website: https://sie.se/wp-content/uploads/2024/01/SIE4-Exempelfil-Sample-file-1.zip Current behavior: - The account 1090 is imported as "vriga imm anl tillg" instead of "Övriga imm anl tillg" Expected behavior: - The account 1090 is imported as "Övriga imm anl tillg" Cause: CP437 uses 8 bits to represent data. Ö is \x99. However, file was imported using either UTF-8 or ISO-8859-1, where Ö is \xC396 and \x99 doesn't link to anything. This commit update the test file as it was save in cp437 but read as UTF-8. opw-6167408
This update ensures that down payment invoices generated for Mexican EDI (MX EDI) compliance correctly classify clave_unidad and clave_prod_serv as sales transactions, aligning with regulatory requirements. This change, previously implemented in 18.0 and 19.0, is now backported to version 17.0 to maintain accurate reporting and compliance.
Original PR description
When creating down payment invoices for mx edi, clave_unidad and clave_prod_serv (cfdi_line_values) should be considered as sale (ACT - activity and 84111506 code for invoicing services) according to the authorities. This already works for 18.0 and 19.0. Backporting solution for 17.0 task id [6173559](https://www.odoo.com/odoo/project/49/tasks/6173559)
This update corrects a problem where POS invoices created in timezones ahead of Riyadh (like Dubai) would incorrectly set the invoice date, leading to errors. By ensuring the invoice date is always aligned with Riyadh time during POS invoice generation, this fix prevents invoice creation failures for Saudi Arabian businesses and their staff.
Original PR description
Before: - POS orders created by users in timezones ahead of Riyadh (e.g. Dubai, UTC+4) produced an `invoice_date` based on the user's local date, which could be a day ahead of Riyadh. - This caused `_get_normalized_l10n_sa_confirmation_datetime` to raise a UserError blocking POS invoice creation. After: - Overrides `_prepare_invoice_vals` on pos.order to convert date_order (UTC) to Asia/Riyadh and clamp to today's Riyadh date before passing to ZATCA validation. - This override applies only during POS invoice generation, where date_order is the source of truth instead of a manually set invoice_date. Impact: - Fixes UserError on POS invoice creation for SA companies with staff operating in timezones ahead of Riyadh. taskID-6043167
This update fixes a technical issue where Google Calendar attendees with matching email aliases were being silently removed from Odoo events. This meant events would show up with incorrect attendee counts. The change ensures all attendees, even those using aliases, are properly synchronized, maintaining accurate event information.
Original PR description
When a Google attendee's email matches a configured mail alias, the attendee is silently lost during sync — the corresponding partner is excluded from the lookup result, and the event lands in Odoo with one fewer attendee than Google shows. opw-6086240
This update fixes a discrepancy in UBL/CII e-invoice exports caused by rounding differences. The change ensures that line totals accurately match the overall document total, preventing validation failures and ensuring compliance with invoicing standards. It addresses a technical issue related to how the system calculates and distributes rounding errors.
Original PR description
The sum of individual line extension amounts in UBL/CII exports can sometimes differ from the total expected amount due to cumulative rounding differences. Steps to reproduce: - Configure rounding to…
The sum of individual line extension amounts in UBL/CII exports can sometimes differ from the total expected amount due to cumulative rounding differences. Steps to reproduce: - Configure rounding to Round Globally - Have a Belgium company setup - Have a customer with Peppol enabled - Create an invoice with many lines where each line amount have multiple decimals before rounding (product price precision raised to 4, fixed tax with 4 decimals) - Confirm the invoice Issue: Discrepancy between line totals and the document total in the XML, leading to validation failure `[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)` Analysis: When generating e-invoice, we calculate the total line extension amount from unrounded line amounts, after adding the fixed taxes https://github.com/odoo/odoo/blob/b71b51ce8e78970104c97f599b533bdcf36484c0/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L396-L411 However, the sum of line rounded values may not equal the rounded sum of the raw values. This change tracks the expected rounded sum and compares it to the actual accumulated sum. If a delta exists, it is distributed across the lines to ensure the XML is consistent. Minimalistic backport of d66c299cf7fb781bbba6850d0ca17831aed0475d opw-5871638 Forward-Port-Of: odoo/odoo#251155
This update resolves an issue where the stock return wizard incorrectly unreserved items when a product line was left at a zero quantity or a partial quantity. The fix ensures that only the actual returned quantity is unreserved, preventing over-unreserving and improving the accuracy of stock tracking. This change impacts the handling of partial returns.
Original PR description
Steps to reproduce
1. Configure a 2-step delivery (PICK -> OUT).
2. Confirm and reserve a delivery for multiple products, validate the PICK.
3. Open the return wizard on the validated PICK, OUT moves are now reserved.
4. Leave a product line at qty 0 (instead of deleting it), or reduce a line to a partial quantity (e.g. 1 of 8), then click Return.
Issue
`_create_returns()` iterated over every wizard line via `self.product_return_moves.mapped('move_id')` and called `_do_unreserve()` on the chained OUT move unconditionally, without checking whether that line was actually being returned:
https://github.com/odoo/odoo/blob/2fde70e450a36a258bdb67dcb0bd6646b60a26ff/addons/stock/wizard/stock_picking_return.py#L130-L131
A line left at qty 0 caused its OUT move to be fully unreserved even though nothing was being sent back. A partial return (e.g. 1 of 8) also unreserved all 8 units.
opw-6175293This update resolves issues with the UBL invoice export process when early payment discounts are applied. Specifically, it corrects errors related to incorrect tax subtotal calculations and VAT category assignments, ensuring proper compliance with PEPPOL standards. This prevents validation failures during UBL generation.
Original PR description
…d tax subtotal **STEP TO REPRODUCE** 1. Create an invoice with an early payment discount (payment terms) with an invoice line with a 0% tax. 2. Generate the ubl for the invoice by sending it to…
…d tax subtotal **STEP TO REPRODUCE** 1. Create an invoice with an early payment discount (payment terms) with an invoice line with a 0% tax. 2. Generate the ubl for the invoice by sending it to peppol. 3. Validate the generated ubl, you'll get the following errors: [BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT". [BR-S-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Standard rated" shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "Standard rated". [BR-S-06]-In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Standard rated" the Document level allowance VAT rate (BT-96) shall be greater than zero. **CAUSE** - When there is a epd, we append a new tax subtotal. Which means we end up with multiples tax subtotal for the tax category E. We do the same for emptying taxes. The fix add a step that merges all the tax subtotal of the same tax category into one. - When there is a epd, the allowance is generated with with a tax cargory S even with the tax percentage is 0. It should be E for 0% tax. opw-6075910
This update resolves a visual bug where the status bar displayed duplicate information for sub-tasks. The fix ensures that the status bar accurately reflects the task's project association, improving the user experience and data consistency. It corrects a conflict in how the system handles project assignments within sub-tasks.
Original PR description
Steps: - Create a task inside any project. - Create a sub-task under that parent task. - Open the sub-task and remove the project (clear the project field). - Look at the status bar at the top of the form view. Issue: - The status bar is displayed twice (both the Project stages and Personal stages - are visible simultaneously). Cause: - When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: - To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970
This update fixes a visual issue in the project Kanban view where custom colors weren't being applied to task statuses. The fix ensures that task statuses (identified by backend IDs) are correctly mapped to their designated colors, improving the user experience and visual clarity of the Kanban board.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106
This update resolves a confusing user experience where discount codes wouldn't apply after being discarded. Now, users can successfully re-apply discarded codes without creating new reward lines, ensuring a smoother and more intuitive process for applying loyalty discounts. This improves the overall customer experience.
Original PR description
Issue: --- ### Steps to reproduce: 1- Create a `Discount Code` program. 2- In SO, use `Coupon Code` wizard and use the code. 3- After available rewards are shown, discard the wizard. 4- Re-apply the code. Validation Error: The promo code is already applied. As the reward is not applied, this is functionally confusing. At this point We can see the reward only inside the rewards wizard view. If we allow re-apply the code in case no reward line is created for the `rule.program_id`, we can still see the reward by re-applying the same code, without any side effects. opw-6164198
This update resolves an issue where the customer address field in the Point of Sale (POS) for Peru (PE) was not correctly populated, leading to inaccurate shipping address information. The fix ensures the required 'city' field is properly set during customer creation, preventing errors when processing orders and shipments.
Original PR description
Steps to reproduce: ------------------- * Install l10n_pe_pos * Switch to PE company * Create a pos * Enable shipping later for that pos * Open the pos * Make an order * Create a new customer inside the pos, fill in all information * Go to pay the order * Select the ship later option * valdiate > Popup, incorrect address for shipping Why the fix: ------------ The field city_id is a list containing the id of the city and the name string. For the PE loca we were only setting the city_id field when creating a customer and not city. Which is the required field when checking addresses. opw-6070005