Daily updates from Odoo
Wednesday, February 25, 2026
95 changes
27 changes
Resolved issues and error corrections
This update resolves a bug preventing users from saving invoices in the Mexico (MX) edition of Odoo Enterprise. The issue stemmed from a requirement for a payment method when the payment policy was set to 'PUE,' which blocked saving functionality. The fix allows payment methods to be edited until the invoice is sent to the SAT, maintaining user flexibility.
Original PR description
After this commit 1e702a5, a bug in the invoice form view appeared that made it difficult (to not say impossible) to reset an invoice or do any operation that involves to save the invoice. How to reproduce (there are multiple ways but this is the easiest): 1.- Using mx demo company INNOVACION y DESARROLLO SA de CV 2.- Create an invoice with INMOBILIARIA CVA as contact 3.- Post the invoice 4.- Try to send or do a modification and save 5.- Missing required fields notification will appear. This error happens since the payment way is required if the payment policy is PUE but is not editable when not in draft, causing this deadlock. There multiple ways to fix this, but the simplest way and maintaining the flexibilty on the user to decide what value to use, we keep the logic on the view but make the payment method editable until the invoice is sent to the SAT just like with the payment policy. target: saas-19.2 -> master task-5962060
This update corrects an error that occurred when moving leads from a previous year to a 'won' stage in the CRM. The fix ensures the system handles leads with dates spanning multiple years correctly, preventing a technical error. This improves the reliability of lead management.
Original PR description
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year. ### **Steps to Reproduce:** 1) Install CRM without demo data. 2) From the…
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year.
### **Steps to Reproduce:**
1) Install CRM without demo data.
2) From the `CRM>Configuration>Stages` make `new` stage as **'won'** stage.
3) Create a lead with dated in the past (e.g., 30-12-2025 by changing system date)
and with some expected_revenue.
4) Change the system date to today and move the lead to the Won stage.
Ref Video: https://drive.google.com/file/d/18OCQ4Tl6Co_oh28XNag3qjxMkXJNSMOh/view?usp=sharing
### **Error:**
`TypeError: '<' not supported between instances of 'NoneType' and 'float'`
### **Root Cause:**
When a lead is moved to a won stage, `_get_rainbowman_message` is called and computes the values for `max_{team,user}_{31,7}`. However, when the lead spans different years, the condition of SQL query at [1] fails(because 2025 != 2026) due to which SQL query return null from the MAX() Function. As a result, subsequent comparisons at [2] fail, raising an Error.
### **FIX:**
Introduce small helper method(`_is_lower_than_expected_revenue`) to ensure comparisons
across different years only happen when we have meaningful numeric values.
[1]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1218
[2]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1232
**opw-5484887**
**sentry-7026119584**
Forward-Port-Of: odoo/odoo#244938This update allows branch companies to see and use contacts belonging to their parent company when creating invoices or vendor bills. Previously, branch companies were restricted from selecting these contacts. This change ensures seamless multi-company operations and improves workflow efficiency.
Original PR description
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills. ### **Steps to reproduce:** 1) Create a…
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.
### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B).
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.
### **Current/Buggy Behavior:**
The contact does not appear in the search results.
### **Expected Behavior:**
The contact should be selectable.
### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.
However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].
This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.
### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.
[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896
**opw-5484611**
Forward-Port-Of: odoo/odoo#244671This update resolves a visual issue affecting course cards on the website. Previously, descriptions containing links caused layout problems due to an incorrect assumption about HTML structure. This fix restores the original card design and ensures course cards display correctly, even when users include links in their descriptions.
Original PR description
This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the…
This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the description. | 19.0 and above | This PR | |--------|--------| | <img width="333" height="392" alt="image" src="https://github.com/user-attachments/assets/3dce73b3-0ce9-486e-b1de-f88a74e52e05" /> | <img width="313" height="381" alt="image" src="https://github.com/user-attachments/assets/25d75970-7f55-4967-87ba-3ecf5710835d" /> | #### Steps to reproduce: 1. Go to `website_slides` 2. Create a new course 3. Go to the description tab 4. Insert a link in the description and save 5. Go to the frontend to see the courses list 6. Course cards with a description containing a link are visually broken. While this looked like an improvement because it simplified the DOM, it was done with the assumption that the course card could not contain another link. This is, of course, not the case, as the description field is editable by the user and can therefore contain a link. Because this is not valid HTML, the layout removes all nested links and renders them separately. Since all the classes related to the card design are applied to that `<a>` tag, all links are rendered with a border and other styling. This PR fixes the issue by reassigning all the card styles to the card container. We then reassign each property to the corresponding element, adapt the styles to mimic the original card design, and hide extra links that are rendered empty. This should at least fix the layout for users. [^1]: https://github.com/odoo/odoo/commit/f632b8a9e74a050288e3ec75a4f49ae3ecb551d6 task-5957910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249969
This update resolves an issue where the HTML editor component was crashing due to aggressive sanitization by DOMPurify. The fix involves temporarily encoding and decoding values within the editor's data attributes to avoid conflicts with the sanitization process. This ensures the editor functions correctly without compromising security.
Original PR description
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for…
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for security reasons (see [1]). However `html_editor` embedded components use `data-attributes` (`data-embedded-props` and `data-embedded-state`) to store various kind of data as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex and these attributes are therefore removed, which results in an Editor crash. There are multiple reasons why such values are acceptable as is for the `html_editor` usage: - only `HTMLElement` instances are sanitized, never a string, therefore there is no `DOMParser` to trick with invalid HTML. - values in these attributes are always/exclusively parsed as JSON strings, and the editor will crash if the value is not a legit JSON. - values in these attributes are HTML escaped by the python sanitizer when the serialized html is sent to the server. - values in the JSON parsed object are at worst rendered as plain text (never as HTML or other parsed formats). - values in the JSON parsed object are never executed as JS (only serializable primitives are stored). Therefore, the suggested solution is to encode the values during sanitization, and decode just after, to keep the rest of the codebase simple and explicit. [1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml task-5960707 Forward-Port-Of: odoo/odoo#250475 Forward-Port-Of: odoo/odoo#250210
This update fixes a problem where subcontracting production orders weren't correctly displaying all associated move lines. By ensuring each move line is linked to the receipt picking, the 'Move' detail operations button now accurately shows all serial/lot numbers, improving traceability and reducing confusion for users.
Original PR description
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New…
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New Production" action, only the `first serial number line` appears in the "Move" detail operations smart button. Although all move lines are correctly created on the move, this behaviour is confusing for the user. Steps to reproduce: --------------------------------- 1. Install the `mrp_subcontracting_purchase` module. 2. Create a serial-tracked product and its subcontracting BoM. 3. Create a PO with a subcontracting vendor and a product quantity greater than 1. 4. Confirm the PO and validate the resupply. 5. Open the receipt and click on the "Subcontracting Production" smart button. 6. Generate serial numbers for the product. 7. Validate the receipt and open the "Move" detail operations smart button. 8. Only one line (the first serial number) is shown, while the move actually contains all move lines. Cause: --------------------------------- When serial numbers are generated from the subcontracting MO view, or when a new MO is created using the "Create New Production" action introduced in [PR](https://github.com/odoo/odoo/pull/218377), new move lines are created without setting the `picking_id`. As a result, these move lines are linked to the stock move but not directly to the picking. Since the "Move" detail operations smart button relies on the picking’s `move_line_ids`, the newly created move lines are not displayed. With this commit: --------------------------------- The `picking_id` is now set on newly created move lines. This ensures that all move lines are directly linked to the picking, allowing the "Move" detail operations smart button to display all serial/lot lines correctly and improving traceability for the user. And also When working with a subcontracting order, if the user opens the lot/serial number generation wizard from the subcontracting production and directly clicks 'Apply' without creating or assigning any lot/serial number, Odoo raises the following traceback: `IndexError: tuple index out of range` This issue has also been fixed here. Forward-Port-Of: odoo/odoo#243988
This update resolves issues preventing early bill printing with the Italian fiscal printer. The fix addresses a traceback caused by incorrect data handling and ensures the receipt prints correctly, improving the restaurant's order fulfillment process.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#108161
Forward-Port-Of: odoo/enterprise#105511This update fixes a potential issue where special products used in point-of-sale (like those with discounts or tips) could be accidentally deleted or archived. This change adds a safeguard to ensure these products remain available in the POS, minimizing errors and maintaining accurate sales data. It's a critical fix to prevent disruptions to the point-of-sale system.
Original PR description
Before this commit, it was possible to delete or archive some products even if they were special for the pos (discount, tips, settle, etc.). This commit adds a mechanism to prevent this and reduce the risk of errors linked to missing products in the pos. Enterprise PR: https://github.com/odoo/enterprise/pull/95789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230865 Forward-Port-Of: odoo/odoo#229074
This update fixes a problem where users attempting to print resumes with incorrect templates received a generic error message. Now, when an invalid template is used, a detailed traceback is displayed, making it easier for support teams to diagnose and resolve the issue. This improves the user experience and streamlines troubleshooting.
Original PR description
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view…
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view `report_employee_cv` by adding `<div t-if=o.no/>` * Print resume of any employee **Observed Behavior:** Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" /> **After:** <img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related: https://github.com/odoo/enterprise/pull/100142 opw-5167898 Forward-Port-Of: odoo/odoo#250286 Forward-Port-Of: odoo/odoo#237262
This update fixes a problem where users wouldn't receive helpful information when trying to print PDF payroll reports with incorrect document layouts. Now, when an invalid layout is used, a detailed traceback is displayed, making it easier to identify and correct the issue. This improves the user experience and troubleshooting of payroll reports.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#108438 Forward-Port-Of: odoo/enterprise#100142
This update fixes a bug in the Odoo 19.0 version where the 'Copy Existing Operations' button was missing from BoM operation tabs. This prevents users from easily copying operations from other bills of materials, impacting efficiency. The fix backports functionality previously introduced in 19.1 to ensure consistent user experience.
Original PR description
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy…
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy existing operations' button appears if at least one operation is already created ### The problem: In version 19.0, the "Copy Existing Operations" button is missing from the BoM operations tab when no operations have been defined yet for the current BoM. While this feature was fully functional in version 18.4, it became inaccessible in 19.0 to users due to a UI reorganization introduced in commit https://github.com/odoo/odoo/commit/80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 that accidentally omitted the "Copy Existing Operations" button. Currently, users are forced to manually create at least one operation before they can see the option to copy from other BoMs. ### The reason to introduce the fix: The ability to copy operations is useful also when starting with an empty BoM if operations in other BoM's have been already created. Since this fix has already been implemented in version 19.1 via commit https://github.com/odoo/odoo/commit/02e837c959381523170c653da099328e9855a4e4, this PR backports that changes to 19.0 to restore feature parity and improve the user experience. opw-5906667 Forward-Port-Of: odoo/odoo#250411 Forward-Port-Of: odoo/odoo#248225
This update fixes a bug where navigating to pages with breadcrumbs caused a crash when the website header was disabled. The change ensures the website interaction safely handles pages without a header, improving stability and user experience. This resolves a technical issue that could disrupt customer journeys.
Original PR description
When the header is disabled globally via the Theme tab in edit mode, navigating to a page containing a breadcrumb caused a crash. The PageBreadcrumb interaction did not handle the case where no header was present on the page. This commit updates the interaction to safely handle pages without a header. Task-ID: 5927177 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#248080
This update fixes a bug where shifts crossing midnight were incorrectly flagged as overtime for employees in timezones like India. The change ensures accurate overtime calculations regardless of the employee's timezone, improving payroll accuracy. It also includes updates to internal code and added testing for reliability.
Original PR description
**Description of the issue/feature this PR addresses:** Fix the overtime calculation logic for resources in timezones ahead of UTC (specifically Asia/Kolkata +05:30) where shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Current behavior before PR:** shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Desired behavior after PR is merged:** . Fix version_periods_by_employee interval . Update get_dates() method to return date objects . Add corresponding tests coverage task-5949757 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249410
This update adapts the MRP module to a new time display format (e.g., '1h 23m 45s') introduced with recent changes. It replaces outdated formatting functions and removes confusing references to 'minutes' to ensure consistent and intuitive reporting within the MRP system. This improves clarity and usability for users.
Original PR description
With the changes made to float_time, every display is now showing `1h 23m 45s` instead of `83:45` (for example). This PR aims to adapt the MRP module to the new display. We're also replacing all uses `formatFloatTime` by `formatDuration` since the former is being depreciated. Finally, we're removing mentions of `minutes` in MRP since it is now counter-intuitive with the new display. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that time-related data within the MRP modules (like production planning) is consistently recorded and displayed in minutes. The change replaces an older formatting method with a new one, improving the accuracy and reliability of time-based reports and calculations. This update affects how production schedules and work orders are managed.
Original PR description
Make sure that time fields in mrp modules are in minutes. Add a new widget in mrp_plm for updates on time data types. Replace formatFloatTime by formatDuration.
This update fixes an issue where CABA taxes were incorrectly included in tax reports when part of a tax group. The change ensures that CABA taxes are properly excluded from reports, preventing duplicate amounts and improving the accuracy of financial reporting. This resolves a bug impacting invoice and reconciliation processes.
Original PR description
How to reproduce: - Create one CABA tax and one normal tax. - Create a tax group containing both taxes. - Create an invoice using this tax group. - In the tax report, the CABA tax appears even when the invoice is unpaid. - After reconciliation, the CABA tax amount is duplicated in the report. When the CABA tax is part of a tax group, it is selected in _read_generic_tax_report_amounts_no_tax_details. Since the tax group has tax_exigibility = 'on_invoice', the CABA tax inside the group is incorrectly included by the query. opw-5468074 Forward-Port-Of: odoo/enterprise#105888
This update resolves an issue causing errors when editing addresses within the customer portal. The fix ensures accurate address validation by correctly comparing data, preventing form errors and improving the user experience. This was triggered by a recent code change.
Original PR description
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for…
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package - Create a website, and a portal user - Add a main and a secondary address to the user using the website form in 'My Account' - Go to the secondary address and change any field - Click on Save Address - Multiple errors will appear on the form (reproducible with other similar config) (and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`) **Issue:** In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms. This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]` which try to compare recordsets with the given ids. **Fix:** Cast relational field to their id values to ensure they can be properly compared to the website form values. related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252 opw-5247171 Forward-Port-Of: odoo/odoo#244532
This update fixes an issue where pasting content into the website editor, particularly within iframes, would unexpectedly remove unremovable elements. The change adjusts how the editor handles inline elements, ensuring that elements are preserved during the paste process. This improves the user experience and prevents data loss.
Original PR description
*: website Before this commit: when a editable container is wrapped inside a non-contenteditable, which could happen inside an iframe, pasting on a selection including an unremovable element will remove the element. This is because the config parameter `allowInlineAtRoot` is false by default, the editable container of Contact us button is considered as the edition boundary, and then `wrapInlinesInBlocks` is called on it at insert, which removes invisible nodes in the wrapping process. After this commit: we now use predicates to decide areInlinesAllowedAtRoot We add a predicate specifically for the container of Contact Us button, to allow inline element in the root. The `wrapInlinesInBlocks` won't be called on the container on paste anymore. task-5109662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246987 Forward-Port-Of: odoo/odoo#241836
This update fixes a bug where canceled POS orders with future dates weren't fully removed from the system. Now, cancellations are correctly applied in both the POS interface and the backend, ensuring accurate order tracking and preventing phantom orders. This improves the reliability of our self-checkout process.
Original PR description
Before this fix, when we placed an order from the self-checkout with a preset slot for a future date, we weren't able to cancel it from the POS. The UI showed it as canceled, but after refreshing, the order was still there. Now, when we cancel an order scheduled for the future, it is correctly canceled both in the UI and in the POS. task : 5246089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248616 Forward-Port-Of: odoo/odoo#235775
This update corrects a technical issue preventing the successful submission of GİB e-Dispatch documents through the Nilvera integration. The previous system incorrectly passed the stock picking company, leading to an error. Now, the correct company environment is passed, ensuring smooth document submission.
Original PR description
# Description of the issue this PR addresses - When sending a GİB e-Dispatch document using l10n_tr_nilvera_edispatch, an error is raised during document submission. - The issue occurs in StockPicking._l10n_tr_nilvera_submit_document when sending request with Nilvera client. - The signature of _get_nilvera_client was updated but the params were not # Current behavior before PR - When attempting to send a GİB e-Dispatch document, the system raises an error. - The method _l10n_tr_nilvera_submit_document calls _get_nilvera_client with self.company. - stock.picking does not have a company field. - This results in an attribute error during client initialization and prevents document submission. # Desired behavior after PR is merged - The correct field self.env.company is passed to _get_nilvera_client. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where validating purchase receipts for kits with different unit of measure categories caused errors. The fix ensures accurate quantity calculations when a purchase order is placed in a foreign currency, preventing receipt validation failures. This improves the reliability of purchase order processing.
Original PR description
Steps to reproduce ------------------ 1. Enable Units of Measure and Automatic Valuation. 2. Create: Product KIT, stockable, UoM category Unit, UoM = Units. BoM for KIT with at least one component…
Steps to reproduce
------------------
1. Enable Units of Measure and Automatic Valuation.
2. Create:
Product KIT, stockable, UoM category Unit, UoM = Units.
BoM for KIT with at least one component whose UoM is in a different
category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.
Issue
-----
Validating the receipt raises:
> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…
If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.
Cause of the issue
------------------
Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108
Fix
---
The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.
https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126
For kits, `qty_received` must be calculated by aggregating component
moves to accurately determine this status. Since the standard logic
crashes due to UoM mismatch, the override in `purchase_mrp` is
necessary to provide the correct quantity for this date selection.
opw-5030761
Forward-Port-Of: odoo/odoo#248883
Forward-Port-Of: odoo/odoo#236276This update fixes an issue where shift start and end times weren't correctly reflecting the assigned shift template, even when employees had fixed schedules. The change ensures shift times align with the template, providing accurate scheduling for employees with varying working hours. This improves the reliability of shift planning.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#108187 Forward-Port-Of: odoo/enterprise#107018
This update fixes an issue where Verifactu invoices were incorrectly generating an 'F1' type instead of the required 'F3' type when fully invoicing. The change ensures the correct invoice type is used, aligning with Spanish tax regulations and preventing potential compliance problems. This update ensures accurate VAT reporting for Spanish customers.
Original PR description
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then…
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then go to PoS > Orders, and select the previously made order 4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order. 5. Click invoice to invoice the order; the invoice is no longer simplified. Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead. The fix ------- When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1. Sources: -------- Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD opw-5343973 Forward-Port-Of: odoo/odoo#242274
This update resolves an issue affecting the Gantt view of work orders, specifically related to planning and display. The changes include a revised calendar structure and the ability to exclude 'blocked by' workorders, improving workflow clarity and accuracy. This ensures a more reliable and user-friendly experience for managing production schedules.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267
This update resolves an issue impacting the Gantt view used to manage work orders. The changes enhance the visual representation of work orders and improve the functionality of the Gantt chart, specifically regarding planning and scheduling. It corrects a display issue and ensures accurate planning capabilities.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267
This update fixes an issue where selling kit products through Point of Sale (POS) would incorrectly calculate stock valuation lines. The fix ensures that the UoM of kit components is properly considered when determining the cost of goods sold and stock levels. This ensures accurate inventory tracking and financial reporting for kit sales.
Original PR description
When selling a kit product in POS, if the component of the kit use a different UoM than the UoM defined on the product, the stock valuation lines are wrong. Steps to reproduce: ------------------- * Create a storable product A with a UoM "Dozen" and a cost price of 10€ * Create a kit product B with a BoM of 1 unit of product A * Sell 1 unit of product B in POS > Observation: The valuation lines have the wrong value Why the fix: ------------ The product qty was not considering the UoM when computing the expense and stock valuation lines. opw-5471923 Forward-Port-Of: odoo/odoo#249583 Forward-Port-Of: odoo/odoo#248694
This update ensures that freight charges for international UPS deliveries are accurately reflected on the commercial invoices used for customs clearance. Previously, invoices were set to $0, but the fix now correctly includes freight charges based on the UPS API parameters. This improves accuracy and compliance for international shipments.
Original PR description
Issue ----- For international deliveries, the commercial invoice used for customs does not include the freight charges (it is set to 0). Steps to reproduce ----- - Create an international UPS sale - Confirm the delivery - Open the "UPSCommercialInvoice.pdf" file > In the price breakdown, freight is set to 0.0 Cause ----- It has to be specified in the `ship` request as `ShipmentServiceOptions.InternationalForms.FreightCharges.MonetaryValue` (source https://docs.rocketshipit.com/rs/docs/ups-api-parameters.html#shipment) Expected result ----- <img width="1912" height="963" alt="image" src="https://github.com/user-attachments/assets/170e49f7-6575-4524-b186-3829f4c20430" /> ----- Ticket: opw-5135494 Forward-Port-Of: odoo/enterprise#108465 Forward-Port-Of: odoo/enterprise#105505
19 changes
Resolved issues and error corrections
This update resolves an issue that prevented users from moving leads won in previous years to current-year 'won' stages. The fix ensures accurate calculations when leads span multiple years, preventing a technical error. This improves the reliability of lead management within the CRM.
Original PR description
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year. ### **Steps to Reproduce:** 1) Install CRM without demo data. 2) From the…
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year.
### **Steps to Reproduce:**
1) Install CRM without demo data.
2) From the `CRM>Configuration>Stages` make `new` stage as **'won'** stage.
3) Create a lead with dated in the past (e.g., 30-12-2025 by changing system date)
and with some expected_revenue.
4) Change the system date to today and move the lead to the Won stage.
Ref Video: https://drive.google.com/file/d/18OCQ4Tl6Co_oh28XNag3qjxMkXJNSMOh/view?usp=sharing
### **Error:**
`TypeError: '<' not supported between instances of 'NoneType' and 'float'`
### **Root Cause:**
When a lead is moved to a won stage, `_get_rainbowman_message` is called and computes the values for `max_{team,user}_{31,7}`. However, when the lead spans different years, the condition of SQL query at [1] fails(because 2025 != 2026) due to which SQL query return null from the MAX() Function. As a result, subsequent comparisons at [2] fail, raising an Error.
### **FIX:**
Introduce small helper method(`_is_lower_than_expected_revenue`) to ensure comparisons
across different years only happen when we have meaningful numeric values.
[1]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1218
[2]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1232
**opw-5484887**
**sentry-7026119584**
Forward-Port-Of: odoo/odoo#244938This update allows branch companies to see and use contacts belonging to their parent company when creating invoices or vendor bills. Previously, branch companies were restricted from selecting these contacts. This change resolves a technical issue related to how company affiliations were handled within the accounting module.
Original PR description
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills. ### **Steps to reproduce:** 1) Create a…
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.
### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B).
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.
### **Current/Buggy Behavior:**
The contact does not appear in the search results.
### **Expected Behavior:**
The contact should be selectable.
### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.
However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].
This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.
### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.
[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896
**opw-5484611**
Forward-Port-Of: odoo/odoo#244671This update resolves a visual problem with course cards on the website. Previously, descriptions containing links caused the card layout to break. The fix reassigns styling to the card container, ensuring correct rendering of course cards with links in the description.
Original PR description
This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the…
This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the description. | 19.0 and above | This PR | |--------|--------| | <img width="333" height="392" alt="image" src="https://github.com/user-attachments/assets/3dce73b3-0ce9-486e-b1de-f88a74e52e05" /> | <img width="313" height="381" alt="image" src="https://github.com/user-attachments/assets/25d75970-7f55-4967-87ba-3ecf5710835d" /> | #### Steps to reproduce: 1. Go to `website_slides` 2. Create a new course 3. Go to the description tab 4. Insert a link in the description and save 5. Go to the frontend to see the courses list 6. Course cards with a description containing a link are visually broken. While this looked like an improvement because it simplified the DOM, it was done with the assumption that the course card could not contain another link. This is, of course, not the case, as the description field is editable by the user and can therefore contain a link. Because this is not valid HTML, the layout removes all nested links and renders them separately. Since all the classes related to the card design are applied to that `<a>` tag, all links are rendered with a border and other styling. This PR fixes the issue by reassigning all the card styles to the card container. We then reassign each property to the corresponding element, adapt the styles to mimic the original card design, and hide extra links that are rendered empty. This should at least fix the layout for users. [^1]: https://github.com/odoo/odoo/commit/f632b8a9e74a050288e3ec75a4f49ae3ecb551d6 task-5957910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249969
This update resolves a crash in the HTML Editor component caused by overly aggressive sanitization of data attributes. The fix involves temporarily encoding and decoding these attributes during sanitization to prevent removal, ensuring the editor functions correctly. This improves stability and prevents disruptions to users.
Original PR description
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for…
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for security reasons (see [1]). However `html_editor` embedded components use `data-attributes` (`data-embedded-props` and `data-embedded-state`) to store various kind of data as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex and these attributes are therefore removed, which results in an Editor crash. There are multiple reasons why such values are acceptable as is for the `html_editor` usage: - only `HTMLElement` instances are sanitized, never a string, therefore there is no `DOMParser` to trick with invalid HTML. - values in these attributes are always/exclusively parsed as JSON strings, and the editor will crash if the value is not a legit JSON. - values in these attributes are HTML escaped by the python sanitizer when the serialized html is sent to the server. - values in the JSON parsed object are at worst rendered as plain text (never as HTML or other parsed formats). - values in the JSON parsed object are never executed as JS (only serializable primitives are stored). Therefore, the suggested solution is to encode the values during sanitization, and decode just after, to keep the rest of the codebase simple and explicit. [1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml task-5960707 Forward-Port-Of: odoo/odoo#250475 Forward-Port-Of: odoo/odoo#250210
This update fixes a problem where multiple serial numbers generated during subcontracting weren't correctly displayed in the 'Move' detail operations. By ensuring each move line is linked to the receipt picking, the system now accurately shows all produced items, improving transparency and traceability for users. This enhances the overall efficiency of subcontracting processes.
Original PR description
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New…
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New Production" action, only the `first serial number line` appears in the "Move" detail operations smart button. Although all move lines are correctly created on the move, this behaviour is confusing for the user. Steps to reproduce: --------------------------------- 1. Install the `mrp_subcontracting_purchase` module. 2. Create a serial-tracked product and its subcontracting BoM. 3. Create a PO with a subcontracting vendor and a product quantity greater than 1. 4. Confirm the PO and validate the resupply. 5. Open the receipt and click on the "Subcontracting Production" smart button. 6. Generate serial numbers for the product. 7. Validate the receipt and open the "Move" detail operations smart button. 8. Only one line (the first serial number) is shown, while the move actually contains all move lines. Cause: --------------------------------- When serial numbers are generated from the subcontracting MO view, or when a new MO is created using the "Create New Production" action introduced in [PR](https://github.com/odoo/odoo/pull/218377), new move lines are created without setting the `picking_id`. As a result, these move lines are linked to the stock move but not directly to the picking. Since the "Move" detail operations smart button relies on the picking’s `move_line_ids`, the newly created move lines are not displayed. With this commit: --------------------------------- The `picking_id` is now set on newly created move lines. This ensures that all move lines are directly linked to the picking, allowing the "Move" detail operations smart button to display all serial/lot lines correctly and improving traceability for the user. And also When working with a subcontracting order, if the user opens the lot/serial number generation wizard from the subcontracting production and directly clicks 'Apply' without creating or assigning any lot/serial number, Odoo raises the following traceback: `IndexError: tuple index out of range` This issue has also been fixed here. Forward-Port-Of: odoo/odoo#243988
This update fixes an issue where the 'Total' hours displayed in the Gantt view were incorrect for employees with calendars in non-UTC timezones. The change ensures that working hours are accurately calculated and displayed, regardless of the employee's timezone, improving planning accuracy.
Original PR description
### Issue: Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong. ### Steps to reproduce: - Have an employee…
### Issue: Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong. ### Steps to reproduce: - Have an employee with a calendar in "Europe/Brussels" and working from 8 to 17 - In planning add a line for this employee - Display the gantt view on a day - Create a shift for this employee from 8 to 17 - In the "Total" row, the first hour is not counted ### Cause: To compute the values displayed in the Total row, we take the intersection of the shift and the working hours from the calendar. ([src](https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L318)) But the working hours from the calendar are given in UTC for this computation (without conversion), this result in a discrepancy between the actual hours of the calendar (with timezone conversion) and the one given to compute the total row. ### Solution: `resource_work_intervals()` returns the work intervals with the calendar hours and the resource timezone. In our case, only the hours are interesting (the previous code replaced the timezone by UTC). We need to convert them from the calendar timezone to UTC. So the first thing to do is remove the timezone from `resource_work_interval` then we localize it in the calendar timezone and to finish we convert it to UTC. opw-5564749 Forward-Port-Of: odoo/enterprise#106891
This update corrects a bug where internal users were incorrectly added as vendors when supplier invoices were received via email forwarding. This issue was causing problems with our OCR (Optical Character Recognition) process, which relies on accurate partner information. The fix ensures that invoices are correctly associated with the actual supplier, maintaining the integrity of the OCR workflow.
Original PR description
Currently we have an issue with OCR flow, where if internal users forward an email from an internal email address, the internal user is added as vendor Steps to reproduce: - Setup email alias for journal "Purchases" - From an internal user email, forward a supplier bill to the vendor bill alias Issue: If the supplier is not already a registered partner, the bill will be created with the internal user set as partner. This will break OCR flow where the missing document fields will be auto populated from the bill opw-5487368 Forward-Port-Of: odoo/odoo#246352
This update fixes a problem where users attempting to print resumes with incorrect templates received a generic error message. Now, when an invalid template is used, a detailed traceback is displayed, making it easier to identify and resolve the issue. This improves the user experience and streamlines troubleshooting.
Original PR description
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view…
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view `report_employee_cv` by adding `<div t-if=o.no/>` * Print resume of any employee **Observed Behavior:** Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" /> **After:** <img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related: https://github.com/odoo/enterprise/pull/100142 opw-5167898 Forward-Port-Of: odoo/odoo#250286 Forward-Port-Of: odoo/odoo#237262
This update fixes a problem where users received a generic error message when trying to print invalid PDF reports. Now, when an error occurs, a detailed traceback is displayed, making it easier to identify and resolve the issue with the document layout. This improves the user experience and troubleshooting process.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#108438 Forward-Port-Of: odoo/enterprise#100142
This update corrects a bug where the total hours displayed in the planning Gantt view were inaccurate due to timezone discrepancies. The fix ensures that shift durations are calculated correctly, regardless of the employee's timezone, providing more reliable planning data. This improves the accuracy of time tracking and scheduling.
Original PR description
Description: ----------- When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone misalignment in work interval calculations. Steps to reproduce:…
Description: ----------- When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone misalignment in work interval calculations. Steps to reproduce: ------------------- 1. Create an employee with a fixed working schedule (e.g., 8am-12pm, 1pm-5pm with 1-hour lunch break) 2. Ensure the employee's timezone differs from UTC (e.g., Europe/Brussels UTC+1) 3. Create a shift for this employee covering their full working day (8am-5pm) 4. Open the planning gantt view and check the total hours column for that day 5. Expected: 8 hours total | Actual: 7 hours total (with hours misaligned by timezone offset) Root Cause: ----------- In version 19.0, `_gantt_progress_bar_resource_id` used `.replace(tzinfo=pytz.UTC)` when building work intervals, which only changes the timezone label without converting the actual time values. This caused a timezone offset mismatch in the frontend's hour-by-hour comparison. Solution: --------- Replace `.replace(tzinfo=pytz.UTC)` with `.astimezone(pytz.UTC)` to properly convert datetime values to UTC before sending to the frontend. opw-5190244 Forward-Port-Of: odoo/enterprise#104185
This update resolves an issue causing errors when editing addresses within the customer portal. The fix ensures accurate address validation by correctly comparing form values with related data, preventing unexpected errors and improving the user experience. This was triggered by a recent change in how address fields were handled.
Original PR description
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for…
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package - Create a website, and a portal user - Add a main and a secondary address to the user using the website form in 'My Account' - Go to the secondary address and change any field - Click on Save Address - Multiple errors will appear on the form (reproducible with other similar config) (and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`) **Issue:** In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms. This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]` which try to compare recordsets with the given ids. **Fix:** Cast relational field to their id values to ensure they can be properly compared to the website form values. related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252 opw-5247171 Forward-Port-Of: odoo/odoo#244532
This update fixes an issue where kits with multiple components were incorrectly showing a zero cost when using FIFO or average costing methods. Now, the system accurately calculates the total cost of a kit based on its individual components, ensuring accurate inventory and sales reporting. This improves the reliability of kit costing within the Odoo system.
Original PR description
Before this commit, if a kit had multiple components, the cost of the line was counted as zero if the product cost method was FIFO or average. opw-5911338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247833
A recent update to the Odoo mailing builder caused a crash when using company team snippets. This fix corrects a renaming issue within the system, ensuring the builder functions correctly and avoids unexpected errors. The change updates a component name to resolve a compatibility problem.
Original PR description
The `Img` component was renamed `Image` in commit [1]. In the forward port [2], a template with usage of `Img` was not updated to use `Image` instead, resulting in an issue when using the company teams snippet. How to reproduce: - create a new mailing using the builder - add the s_company_team_shapes snippet - click on an `<img>` element Issue: - crash (Img component is missing) Solution: - rename Img to Image [1]: https://github.com/odoo/odoo/commit/a22e22acacc9d54f39d0f07acc3054cd2a33f61e [2]: https://github.com/odoo/odoo/commit/d2b56435736e8d507434c1378cb68fae23e8511f task-5963711
This update fixes an issue where Verifactu invoices generated for Spanish businesses were incorrectly using an 'F1' invoice type. The change ensures that when replacing a simplified Verifactu document, the new invoice uses the correct 'F3' type, aligning with Spanish tax regulations. This ensures accurate VAT reporting.
Original PR description
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then…
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then go to PoS > Orders, and select the previously made order 4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order. 5. Click invoice to invoice the order; the invoice is no longer simplified. Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead. The fix ------- When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1. Sources: -------- Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD opw-5343973 Forward-Port-Of: odoo/odoo#242274
This update fixes an issue where loyalty discounts weren't accurately applied when products used tax-included prices. Previously, discounts were calculated on the price *before* tax, leading to incorrect discount amounts. This change ensures discounts are correctly applied to the cheapest product's price, including tax, resulting in accurate loyalty rewards.
Original PR description
When applyin a discount by percentage on the cheapest product if the product was using a tax included price, the discount was wrongly calculated on the tax excluded price. Steps to reproduce: ------------------- * Create a tax of 15% included in price * Create a product with a price of 10€ and assign the tax created before * Create a loyalty program with a reward of 100% discount on the cheapest product * In POS, add the product to the order > Observation: The discount applied is of 8.7€ instead of 10€ Why the fix: ------------ We make a similar fix to this one : https://github.com/odoo/odoo/pull/240289 opw-5260067 Forward-Port-Of: odoo/odoo#244734
This update fixes an issue where international UPS shipments didn't accurately include freight charges on the commercial invoice used for customs. The fix ensures that freight costs are now correctly reflected, streamlining the customs clearance process for international deliveries. This improves accuracy and reduces potential delays.
Original PR description
Issue ----- For international deliveries, the commercial invoice used for customs does not include the freight charges (it is set to 0). Steps to reproduce ----- - Create an international UPS sale - Confirm the delivery - Open the "UPSCommercialInvoice.pdf" file > In the price breakdown, freight is set to 0.0 Cause ----- It has to be specified in the `ship` request as `ShipmentServiceOptions.InternationalForms.FreightCharges.MonetaryValue` (source https://docs.rocketshipit.com/rs/docs/ups-api-parameters.html#shipment) Expected result ----- <img width="1912" height="963" alt="image" src="https://github.com/user-attachments/assets/170e49f7-6575-4524-b186-3829f4c20430" /> ----- Ticket: opw-5135494 Forward-Port-Of: odoo/enterprise#108465 Forward-Port-Of: odoo/enterprise#105505
This update fixes an issue where project billing amounts weren't being correctly calculated when using purchase orders and vendor bills with analytic distributions. The fix ensures the system accurately identifies and applies the correct analytic account, leading to accurate project profitability reporting. This improves the reliability of financial data.
Original PR description
### Steps to reproduce: - Create a billable Project - Navigate to Accounting > Configuration > Analytic Accounting > Analytic Plans - Change the order of the project plan - Create a Purchase order and set the created project and a department in analytic distribution - Create a Vendor Bill with the same analytic distribution and match with the PO - Confirm the Vendor Bill - Check the project dashboard - Notice the amount is under To Bill not Billed ### Cause: In this commit https://github.com/odoo/odoo/pull/241571/changes/ef080f94609f1057c6d86af68bee605dcaeb287b we introduced a fix to search for the analytic account in purchase lines' analytic distribution when we have multiple accounts for the same purchase line if it is shown as the first number of the key but since it is not mandatory to have the project account id at the start of the key ### Fix: We now search for the id in the whole not only the start of it. opw-5350246 Forward-Port-Of: odoo/odoo#245793
This update fixes an issue where payroll reports and payment exports incorrectly displayed employee names instead of the actual account holder's information. The change ensures payment records accurately reflect the bank account partner, improving data accuracy and compliance across various localized payroll modules (AU, BE, CH, IN, SA, US).
Original PR description
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip…
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV). 4. Observe that the employee's name is displayed instead of the account holder's information. Issue: Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder. Solution: Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner: - Updated QWeb templates to display bank.partner_id.name for account allocations. - Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID. - Ensured a fallback to the employee's legal name remains in place. opw-5357652 Forward-Port-Of: odoo/enterprise#106718
This update resolves an issue preventing portal users and internal users from uploading documents to newly created requests. The fix addresses a technical error caused by sending incorrect data to the document upload controller. Now, users can successfully upload documents, improving the functionality of the Documents module.
Original PR description
Portal users and internal users cannot upload a document in a requested document Steps to reproduce: 1. Install Documents 2. Go to Documents and create a new request for user Joel Willis 3. Connect as portal user and go to Documents 4. Try to upload the requested document 5. An error occurs The same problem occurs for user Marc Demo Problem: Sending both an access_token and a user_folder_id to the controller raises an error 400 https://github.com/odoo/enterprise/blob/519862bf9b708d756478d4d81787f8a1999bc574/documents/controllers/documents.py#L608-L609 Solution: Do not send a user_folder_id when we have an access_token opw-5439104 Forward-Port-Of: odoo/enterprise#106583
8 changes
Resolved issues and error corrections
This update fixes an issue where the names of Ecuadorian invoicing regimes didn't comply with government regulations. The changes ensure that all invoice data sent to the Ecuadorian tax authority (SRI) uses the correct, officially mandated terminology. This ensures compliance and avoids potential delays or errors in invoice processing.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update fixes an issue in the barcode picking interface where adding multiple extra products triggered a disruptive confirmation dialog repeatedly. Now, the dialog opens only once and allows users to easily select and deselect extra products before confirming, streamlining the process and reducing user frustration.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269) Forward-Port-Of: odoo/enterprise#107932 Forward-Port-Of: odoo/enterprise#104932
This update fixes a bug where deleting a partially signed offer would incorrectly delete the associated employee. The fix ensures the employee is only deleted when archived and without other active offers, preventing data loss and maintaining accurate employee records. This improves data integrity and user experience.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109
This update resolves a bug where the booking view wouldn't load after refreshing the Manage Booking page in our POS system. The fix ensures the booking view renders correctly, improving the user experience for managing appointments. This change was made to maintain a smooth and reliable booking process.
Original PR description
Steps: ----- - Install pos_appointment and pos_urban_piper modules. - Open a session for an UrbanPiper-configured POS. - Open the Manage Booking page. - Refresh the page. Issue: ----- - The booking view is not rendered after a page refresh. Cause: ----- - An awaited request in the posStore setup caused the `ActionComponent` not to be rendered yet when the `doAction` was called. Fix: ----- - First render the `ActionComponent`, then fetch the action data, and finally call `doAction`, so the action is executed seamlessly without interruption. Task-5713125
This update fixes an issue where worked days were incorrectly calculated for employees without contracts or when contracts didn't fully align with payslip periods. The change adjusts date boundaries to accurately reflect attendance and out-of-contract days, ensuring payroll accuracy. Thorough testing has been implemented to validate these fixes.
Original PR description
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an…
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an employee without a contract - Create a payslip for this employee for the current month: You'll see X days of attendance (= today until the end of the payslip period) and Y days of out of contract (= number of days from the start of the payslip period until today) - Create a payslip for this employee for the previous month: you'll see ( Z_prev + Y ) days out of contract ( Z_prev = number of working days in the previous month) - Create a payslip for this employee for the next month: you'll see Z_next days of attendance (Z_next = number of working days in the next month) Case 2: - Create a new employee with a contract starting during the current month - Create a payslip for this employee for the previous month - Out-of-Contract days are incorrectly computed as: contract_start_date - previous_month_start. Case 3: - Create an employee with a contract ending during this month - Create a payslip for this employee for the next month - Out-of-Contract days are incorrectly computed as: next_month_end - contract_end_date. Solution: -------- When generating work days lines: - Explicitly handle employees without a contract. - Use adjusted date bounds when the contract does not overlap the payslip period. Several tests were added to cover these scenarios, as well as the tests the corresponding commit in odoo/odoo (PR odoo: 241978) task-5430759
This update resolves an issue where scanning packaging barcodes didn't correctly associate with related lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes accurately link to the correct lots during scanning, improving the accuracy of stock management.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#108214 Forward-Port-Of: odoo/enterprise#98701
This update fixes an error in how holiday pay recovery is calculated for employees with non-standard working schedules (e.g., 40 hours/week). Previously, the calculation used a default 38-hour week, leading to incorrect deductions. This change ensures accurate recovery amounts based on the employee's actual working hours.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#107941 Forward-Port-Of: odoo/enterprise#106205
This update resolves an issue preventing users from exporting BOE reports when using multi-company mode with companies having different VAT numbers. The fix ensures the report options correctly consider all companies in the branch hierarchy, allowing for successful export.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_reports** module. * Create a parent company with two branch companies with all has different VATs. * Enable **multi-company mode** with all companies selected. * Go to tax report `Mod 390` * From gear icon clck on `BOE`. **Observed behavior:** * A warning appears: Please select the main company and its branches in the company selector to proceed. * Not able to export BOE. **Cause:** * This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierachy are in the options => they're not => error. **Fix:** * Added the `'branch_allowed': True` to the `BOE` button options. opw-5891472 Forward-Port-Of: odoo/enterprise#107252
3 changes
Resolved issues and error corrections
This update allows branch companies to correctly see and use contacts belonging to their parent company when creating invoices or vendor bills. Previously, a branch company couldn't access these contacts due to a technical restriction. This fix ensures seamless multi-company operations.
Original PR description
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills. ### **Steps to reproduce:** 1) Create a…
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.
### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B).
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.
### **Current/Buggy Behavior:**
The contact does not appear in the search results.
### **Expected Behavior:**
The contact should be selectable.
### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.
However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].
This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.
### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.
[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896
**opw-5484611**
Forward-Port-Of: odoo/odoo#244671This update resolves an issue preventing the export of BOE reports when using multi-company mode with companies having different VATs. The fix ensures the report options correctly recognize all branch companies, allowing users to proceed with the export functionality. This improves the reliability of tax reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_reports** module. * Create a parent company with two branch companies with all has different VATs. * Enable **multi-company mode** with all companies selected. * Go to tax report `Mod 390` * From gear icon clck on `BOE`. **Observed behavior:** * A warning appears: Please select the main company and its branches in the company selector to proceed. * Not able to export BOE. **Cause:** * This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierachy are in the options => they're not => error. **Fix:** * Added the `'branch_allowed': True` to the `BOE` button options. opw-5891472
This update fixes an issue where salary calculations for employees on attendance-based contracts were incorrect. The system now accurately determines hourly rates for various allowances by using the employee's planned working schedule instead of their recorded attendance hours, ensuring accurate payroll processing for this contract type.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#103282
2 changes
Resolved issues and error corrections
This update fixes a problem where users received a generic error message when printing invalid PDF reports. Now, when an error occurs, a detailed traceback is displayed, making it easier to identify and resolve the issue with the report template. This ensures a smoother user experience when generating payroll reports.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#100142
A bug was preventing users from correctly saving approval domain rules within the web studio feature. This was caused by a mismatch in how domain data was formatted between Python and JavaScript. The fix ensures that domain rules are saved accurately, allowing users to properly configure email approvals.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#107558 Forward-Port-Of: odoo/enterprise#107432
10 changes
Resolved issues and error corrections
This update simplifies how Odoo identifies part-time workers. Previously, a worker exceeding their contract hours was incorrectly categorized as part-time. This change clarifies the definition by using 'work_time_rate' to accurately reflect actual hours worked, improving payroll accuracy and reporting.
Original PR description
Previously , 'is_full_time' indicated just if the worker , has worked the exact amount in his contract or less , but it has a problem, for workers who worked more than there legal contract, They were also considered on Part Time. For the sake of simplicity and clarity, instead of adding a new field like "excess Time", it would be better to just precise the work_time_rate.
This update resolves a previous issue where automation flows involving moving documents and triggering subsequent actions often failed due to security restrictions. The change now allows actions to run seamlessly even after a document is moved, simplifying automation setup for users. The fix also removes a redundant security override, streamlining the system.
Original PR description
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security…
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security check required the sub-action to be explicitly embedded (pinned) on the *destination* folder. Since the record was moved during the process, the subsequent action failed the security check on the new folder where it wasn't pinned. This limitation caused confusion for users setting up automation flows, as the intent of the sequence (Move -> Action) was clear and initiated from a valid context (the source folder), but strict per-action security rules blocked execution. This commit improves the `ir.actions.server` execution logic to support this pattern by introducing a context-based security sentinel: 1. Entry Point Validation: When a Documents action (root) is triggered, the system enforces strict security: the action must be explicitly embedded on the record's current folder. 2. Context Inheritance: Once the root action is authorized and begins execution, it sets a secure sentinel in the context. 3. Trusted Execution: Any subsequent sub-actions (children) detect this sentinel and are allowed to run, regardless of the record's current folder location. This ensures that if a user has the right to start the process (the root action), they have the right to complete the defined sequence, even if intermediate steps move the record to a folder where the sub-actions are not explicitly pinned. As a result, the `_can_execute_action_on_records` override in `documents_account` is no longer necessary and has been removed. Tests have been extended in the `documents` and `documents_account` modules to cover these scenarios (using Tags in the `documents` module instead of Accounting-specific models to make the tests generic). A new test file `test_documents_ir_actions_server.py` was created to maintain a clean testing environment, covering nesting, move sequences, and RPC spoofing attempts. Task-5916630 Forward-Port-Of: odoo/enterprise#108204 Forward-Port-Of: odoo/enterprise#106702
This update resolves an issue where Odoo incorrectly defaulted to USD as the Stripe currency, causing potential blocking for EU companies with non-USD currencies. We've switched to EUR as the default, ensuring accurate Stripe integration and preventing disruptions for our European users. This change addresses previous support tickets (opw-5393508, opw-5913327, opw-5953025).
Original PR description
Right now, we need to guess the correct stripe currency for the stripe account depending on the country, we used the USD as an ultimate fallback But, the USD currency is easy to guess, where the EUR is way harder (it may not be the company currency). So, it is too error-prone to set the USD as the default fallback, and it can lead to EU companies being blocked as their stripe currency is the wrong one. We therefore switch it to EUR. opw-5393508 opw-5913327 opw-5953025 Forward-Port-Of: odoo/enterprise#108293
This update improves the speed of changing order stages in the Point of Sale system. By separating customer display calculations and optimizing database queries, the process is now significantly faster, especially when multiple orders are being prepared. This enhances the user experience and overall system performance.
Original PR description
Before this commit when a lot of orders were in the preparation display and when clicking on an order to change its stage, it was very slow because we were doing the customer display computation directly. Now we compute customer display data in a separate RPC call, and we only call it when the customer display receives a notification of new orders, which makes the stage change much faster. The `_get_pos_orders` is updated to avoid an O(n²) loop; The `_get_open_orderlines_in_display` is updated to avoid deep joins. Forward-Port-Of: odoo/enterprise#108233 Forward-Port-Of: odoo/enterprise#107727
This update enhances how Odoo extracts amounts from bank statements (like CODA files). It now supports regex patterns that identify integer and fractional parts, allowing for accurate decimal amount recognition. This resolves an issue where amounts in cents were not correctly processed, improving the reliability of reconciliation processes.
Original PR description
Update the reconciliation logic of reco models to support regex patterns using named capture groups 'integer' and 'fraction'. This is specifically designed for cases where bank statement labels (like CODA files) provide amounts in cents i.e continuous string of digits without a decimal separator. The logic now: - Prioritizes 'integer' and 'fraction' named groups if present in the match. - Concatenates these groups with a decimal point to form a valid float. - Falls back to the standard digit extraction logic if named groups are not found. So now if user wants the amount to be extracted in decimal values from label then user needs to add regex which supports two groups 'integer' and 'fraction'. Community PR: odoo/odoo#242750 Task [link](https://www.odoo.com/odoo/project.task/5449413) Task-5449413 Forward-Port-Of: odoo/enterprise#108328 Forward-Port-Of: odoo/enterprise#103630
This update fixes an issue where the names of Ecuadorian invoicing regimes didn't comply with government regulations. The changes ensure that all invoice data sent to the Ecuadorian tax authority (SRI) uses the correct, officially mandated terminology. This ensures compliance and avoids potential processing delays.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update reverses a recent change that was incorrectly removing accented characters from partner names used for Mexican VAT (EDI) processing. The system now correctly accepts the accented characters the user inputs, aligning with current SAT regulations. This ensures accurate processing and avoids blocking users from entering legally required name information.
Original PR description
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least…
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]). This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues. The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them. This reverts the whole accent sanitization saga: - Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4. This also removes the unused frozendict import to make "Check Style" happy. opw-5915515 [1] https://github.com/odoo/enterprise/pull/95207 [2] https://github.com/odoo/enterprise/pull/107960 [3] https://github.com/odoo/enterprise/pull/96043 [4] https://github.com/odoo/enterprise/pull/106557 [5] https://github.com/odoo/enterprise/pull/107677 Closes odoo/enterprise#107960 Forward-Port-Of: odoo/enterprise#108425 Forward-Port-Of: odoo/enterprise#108189
This update corrects a recent issue that prevented Invoicing and Banks users from accessing basic financial reports. The change restores the necessary permissions, ensuring these users can view critical reporting data without errors. This resolves a disruption to key business reporting functionality.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#108174 Forward-Port-Of: odoo/enterprise#107654
This update fixes a critical issue where mandatory fields were incorrectly included in signature validation, forcing users to sign them. Now, automatic completion is enabled for these fields, and a clear placeholder is used when the auto-field is empty, improving the user experience and data accuracy.
Original PR description
Before this commit, constant required sign fields with auto_fieldwere incorrectly included in signature validation, forcing users to sign them. Additionally, when auto_field had no value, these fields remained empty instead of using placeholder text as fallback. After this commit, constant required fields are excluded from signature validation, allowing automatic completion. When auto_field returns no value, the placeholder or item type name is used, providing a more clear and informative fallback content for users. task-5886200
This update ensures payslips accurately reflect an employee's actual start date with the company, regardless of internal job changes. Previously, payslips used the contract start date, which wasn't ideal for employees with multiple periods of employment. This change improves payroll accuracy and reporting, particularly in Switzerland and the UAE.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#108145 Forward-Port-Of: odoo/enterprise#106692
9 changes
Resolved issues and error corrections
This update fixes a bug where the planning report generated through the standard print menu produced blank PDFs. The fix ensures users are directed to the correct Print button in the calendar view to generate the report, preventing errors and ensuring accurate report output.
Original PR description
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.…
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report. **Steps to reproduce:** 1. Go to Settings app and enable debug mode 2. Navigate to Technical → Reports 3. Search for "slot_report" 4. Click "Add to print menu" button 5. Refresh the browser 6. Go to Planning app and switch to list view 7. Select a few planning.slot records 8. Click Print → Planning **Current behavior:** A blank or invalid PDF is generated. **Expected behavior:** Users should receive a clear error message directing them to use the correct print method from the calendar view. **Cause of the issue:** The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports. **Fix:** Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data. opw-5477184
This update fixes a bug where accounts without a code in the consolidating company were being excluded from reports, leading to inaccurate totals. Now, the system will automatically find a matching code on other companies to ensure accurate report consolidation and consistent financial data.
Original PR description
Description of the issue this commit addresses: When consolidating reports, any account that doesn't have a code on the consolidating company is filtered out of the consolidation. This will lead to amounts that do not match which should not happen. --- Desired behavior after this commit is merged: When an account should be used but is filtered out because of not having a code in the per company mapping, we try to find its code on any of the other companies he is and use that one as anchor in the consolidation. --- task-5911409
This update corrects a formatting issue in the Eco Voucher export file generated by the payroll module, ensuring it aligns with the requirements of the Monizze system. This resolves a potential export error, guaranteeing accurate data transmission for payroll reporting to Monizze.
Original PR description
This commit realigns the xlsx header with what's expected by Monizze for the eco voucher export.
This update fixes an issue where the Journal Audit report displayed incorrectly with large monetary amounts, causing tables to overflow. The fix adjusts the report's layout to handle these amounts properly, ensuring data is presented clearly and without errors. This improves the user experience when reviewing financial reports.
Original PR description
[FIX] account_reports: journal audit tax display **Problem:** The tax summary tables in the Journal Audit report overflow and collide when displaying large monetary amounts (9+ digits). **Steps to…
[FIX] account_reports: journal audit tax display **Problem:** The tax summary tables in the Journal Audit report overflow and collide when displaying large monetary amounts (9+ digits). **Steps to reproduce:** 1. Create and post invoices/bills with large amounts (e.g. 999,999,999) 2. Go to Accounting > Reporting > Audit Reports > Journal Audit 3. Observe the tax summary tables overflow their columns **Current behavior:** Large numbers overflow and collide because the sub-tables use `table-layout: fixed` and are placed in separate `<td>` elements with hardcoded `colspan`, preventing them from adapting to content width. **Expected behavior:** The tax summary tables should adapt their widths to accommodate large monetary amounts without overflow or collision. **Cause of the issue:** Several layout issues combined to waste space and cause overflow: - The sub-tables were in separate `<td>` elements with fixed `colspan` values (2 and 5), unrelated to actual content width - `table-layout: fixed` forced thin columns (e.g. country code) to take equal space as wider columns (amounts), causing larger values to overflow - The "Taxes Applied" header colspan used `taxesByCountry.length` which doesn't work on objects (always undefined), so the header never spanned the full width in multi-country scenarios - Full country names (e.g. "United States") consumed unnecessary horizontal space - Long tax names (common with OSS) wrapped to multiple lines, making the table very tall **Fix:** By placing both sub-tables inside a single `<td>` with a flex container, they can share the available width dynamically based on content rather than being constrained by arbitrary colspan splits. Removing `table-layout: fixed` lets columns size naturally to their content. Using country codes instead of full names and adding ellipsis on long tax names further reduces the space pressure. Backport of: ba8099ab7bad7a7a9fe445ed6fda8c4daa7abcbd opw-5477029
This update fixes an issue where generated Swiss payment XMLs (pain.001) were invalid due to incorrect use of bank identification codes (BIC). The change ensures that only one of BIC or ClrSysMmbId is used, aligning with Swiss banking standards. This prevents payment processing errors and ensures compliance.
Original PR description
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner or payrun report - Pay with "Swiss ISO20022" > generate xml pain001 - Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml ! **Cause:** In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf). **Solution:** Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6). opw-4872507
This update resolves a validation error occurring during tax calculations for Brazilian invoices using the Avatax service. The fix clears incorrect tax data from the invoice before sending it to Avatax, preventing a mismatch between totals and ensuring invoices are processed correctly. This improves invoice accuracy and avoids disruptions to the invoicing process.
Original PR description
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not…
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not applicable - [Sales] Service Code Origin: 14.01.3/168061/1524 - [Sales] Service Codes: 14.01.3/168061/1524 - Create an Invoice with Document Type "Electronic Service Invoice - NFS-e" - Add the product on the line - Compute taxes - Compute taxes again Issue: Action will be blocked by a validation error resulting from the external taxes call ``` odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice. Errors: Rejection: Total Installments doesnt match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 ``` It occurs because during the call the system is considering the existing taxes on the line and it will send to the avatax service wrong amounts opw-5412456 opw-5409735 Forward-Port-Of: odoo/enterprise#108088
This update fixes an issue where international UPS shipments were generating commercial invoices with incorrect freight charges (showing $0.00). The fix ensures that freight charges are properly included on the invoice by specifying the necessary parameter during the shipment process. This ensures accurate customs documentation and avoids potential delays.
Original PR description
Issue ----- For international deliveries, the commercial invoice used for customs does not include the freight charges (it is set to 0). Steps to reproduce ----- - Create an international UPS sale - Confirm the delivery - Open the "UPSCommercialInvoice.pdf" file > In the price breakdown, freight is set to 0.0 Cause ----- It has to be specified in the `ship` request as `ShipmentServiceOptions.InternationalForms.FreightCharges.MonetaryValue` (source https://docs.rocketshipit.com/rs/docs/ups-api-parameters.html#shipment) Expected result ----- <img width="1912" height="963" alt="image" src="https://github.com/user-attachments/assets/170e49f7-6575-4524-b186-3829f4c20430" /> ----- Ticket: opw-5135494 Forward-Port-Of: odoo/enterprise#108465 Forward-Port-Of: odoo/enterprise#105505
This update resolves an issue preventing the BOE report export when using multi-company mode with companies having different VATs. The fix ensures the report correctly handles branch company selections, now requiring users to select all companies in the hierarchy for successful export.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_reports** module. * Create a parent company with two branch companies with all has different VATs. * Enable **multi-company mode** with all companies selected. * Go to tax report `Mod 390` * From gear icon clck on `BOE`. **Observed behavior:** * A warning appears: Please select the main company and its branches in the company selector to proceed. * Not able to export BOE. **Cause:** * This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierachy are in the options => they're not => error. **Fix:** * Added the `'branch_allowed': True` to the `BOE` button options. opw-5891472 Forward-Port-Of: odoo/enterprise#107252
This update fixes an issue in the barcode picking interface where multiple extra product scans would repeatedly open a confirmation dialog. Now, the dialog opens only once and allows users to easily select or deselect extra items before confirming the addition, streamlining the picking process.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269) Forward-Port-Of: odoo/enterprise#108393 Forward-Port-Of: odoo/enterprise#104932
11 changes
Resolved issues and error corrections
This update fixes an issue where manually invoicing subscriptions or upsells didn't correctly update their invoice status. Now, subscriptions and upsells are automatically marked as 'Fully Invoiced' after invoicing, ensuring accurate financial reporting. This improves the reliability of subscription billing.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585This update ensures Verifactu invoices generated from Point of Sale (PoS) orders correctly reflect the invoice type ('F3') when replacing a previous simplified invoice. Previously, the system incorrectly defaulted to 'F1'. This change aligns with Spanish tax regulations and guarantees accurate invoice generation for Verifactu documents.
Original PR description
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then…
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then go to PoS > Orders, and select the previously made order 4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order. 5. Click invoice to invoice the order; the invoice is no longer simplified. Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead. The fix ------- When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1. Sources: -------- Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD opw-5343973
This update fixes an issue where payroll rates weren't accurately calculated for employees using attendance-based contracts. The system now correctly uses the employee's planned working schedule (hours per day) to determine the appropriate hourly rates for salary and allowances, ensuring accurate pay calculations.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185
This update fixes an issue where product variant pricelists were incorrectly storing data after a rule was removed. Previously, the data remained tied to the variant, but now it's reset to the standard global pricelist setting, ensuring accurate pricing calculations. This resolves a data corruption problem impacting product variant pricing.
Original PR description
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to…
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to pricelist listing, select the pricelist - Edit price list rule - Remove the product - Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id) Related ticket: opw-5411034 (Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view) Description of the issue/feature this PR addresses: Fix corrupted data <img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" /> Current behavior before PR: product_tmpl_id set to None product_id / applied_on data stays the same Desired behavior after PR is merged: When product_tmpl_id is removed, reset the applied_on type back to 3_global --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the names of Ecuadorian localization regimes didn't comply with government regulations. The changes ensure that all names are now correctly formatted for electronic invoicing to the SRI (Servicio de Rentas Internas), maintaining consistency and avoiding potential compliance problems. The system now always uses Spanish names for these regimes, regardless of the user's language settings.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update fixes a problem where the automated invoice processing cron job would fail and lose progress. The change ensures the cron job processes invoices in smaller batches, committing changes after each one to prevent data loss and wasted credits. This improves the reliability of the BR EDI service.
Original PR description
The cron searched with limit=batch_size and only retriggered when >batch_size records were found which never happens. It also ran all invoices in a single transaction so one failure rolled back all progress while IAP credits were already consumed. Search batch_size + 1 so remaining invoices are detected, and commit after each invoice to preserve progress. opw-5954211 Forward-Port-Of: odoo/enterprise#108191
This update allows branch companies to see and use contacts belonging to their parent companies when creating invoices or vendor bills. Previously, branch companies were restricted from selecting these contacts. This change resolves a technical issue related to how company affiliations were handled within the accounting module.
Original PR description
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills. ### **Steps to reproduce:** 1) Create a…
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.
### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B).
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.
### **Current/Buggy Behavior:**
The contact does not appear in the search results.
### **Expected Behavior:**
The contact should be selectable.
### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.
However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].
This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.
### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.
[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896
**opw-5484611**
Forward-Port-Of: odoo/odoo#244671This update resolves an issue where customer emails with accented characters were being rejected by strict email servers like Yahoo. By eliminating subject header folding, Odoo now ensures all emails, regardless of character encoding, are delivered successfully, improving customer communication and support.
Original PR description
Description of the issue/feature this PR addresses: Yahoo and other strict mail servers reject emails with `554 Invalid Subject header` when Subject headers are folded at 78 characters and contain…
Description of the issue/feature this PR addresses: Yahoo and other strict mail servers reject emails with `554 Invalid Subject header` when Subject headers are folded at 78 characters and contain RFC 2047 encoded-words representing non-ASCII characters. The issue occurs because: 1. Long email subjects with accented characters (French: "arrière", "connecté", etc.) are RFC 2047 encoded 2. Python's `email.policy.SMTP` folds these headers at 78 characters per RFC 5322 SHOULD recommendation 3. Yahoo's strict validation rejects folded subjects when the fold occurs at certain positions within or between encoded-words 4. This results in customer-facing emails being rejected with no delivery failing silently, leading to missed communications. Current behavior before PR: > Subject: [SOS-1477030] Commande et livraison - Demande de retour - user pseudo 251003-GD1U0E - Cosmo Connected Casque Fusion avec feu =?utf-8?q?arri?==?utf-8?q?=C3=A8re_connect=C3=A9?= et accessoire (#1031590) This subject: - Is 168 characters when unfolded - Is folded into 3 lines (78, 74, 60 chars) - Contains RFC 2047 encoded "arrière connecté" - Is technically RFC 2822 compliant - **Gets rejected by Yahoo with "554 Invalid Subject header"** While this is technically RFC 2822 compliant, Yahoo's strict validation rejects it. Python's `email.policy.SMTP` folds headers at 78 characters to follow RFC 5322's SHOULD recommendation. However, when subjects contain non-ASCII characters that get RFC 2047 encoded, the folding can create patterns that strict mail servers reject. Desired behavior after PR is merged: - No folding of Subject headers, regardless of length - Yahoo and all strict SMTP servers accept these emails - Customer support emails deliver successfully --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where custom analytic distributions on sales order lines were being reset to the default model distribution when the order was confirmed. Previously, users couldn't maintain their specific distribution settings. Now, custom distributions will be preserved, ensuring accurate tracking of costs within project sales.
Original PR description
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned,…
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model. --- Steps to reproduce: 1. Install sale_project,project_purchase. 2. Activate "Analytic Accounting" in the settings. 3. Create a new Product "test"; Type: Service, Create on Order: Project. 4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank. 5. Create a new Quotation in the Sales apps; Partner: Acme. 6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model. 7. In the Analytic Distribution cell, add a line with any non null distribution. 8. Confirm the Quotation. 9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains. --- Desired behavior after this commit is merged: Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user. --- opw-4934291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where archived employees caused conflicts when managing appraisal plans. The fix ensures that archived employees' appraisal dates are cleared, preventing errors when setting appraisal plans for active employees. This improves the stability and usability of the appraisal management feature.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#100437
This update corrects a bug where invoices created by users in time zones before Saudi Arabia could be incorrectly dated in the future, leading to ZATCA rejection. The change ensures invoice dates are properly aligned with Saudi Arabia's time, preventing future invoicing issues and maintaining compliance.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246311
6 changes
Resolved issues and error corrections
This update resolves an issue where the General Ledger Excel export was blank when generating reports from branch companies. The fix ensures that all relevant financial data, including accounts and journal entries, are correctly included in the exported file, providing accurate reporting for branch operations.
Original PR description
Behavior before: When exporting the General Ledger to Excel from a branch company, the generated file was empty. Behavior after: The General Ledger Excel export now correctly includes all relevant data for branch companies. Root cause: The SQL query used to retrieve accounts did not properly account for multi-company hierarchies. In a branch setup, the chart of accounts is typically defined on the parent company, while the journal entries (account_move_line) belong to the branch company. As a result, conditions such as aml.company_id = account.company_id or account.company_id IN company_ids returned no records, leading to an empty export. Steps to reproduce: 1. Create a branch company. 2. Create invoices in the branch company using accounts from the parent company. 3. Open the General Ledger report and export it to Excel. 4. The exported file is empty. OPW: 5901758
This update resolves an issue where the General Ledger XLSX export for branch companies was blank. The fix ensures that branch companies correctly display their transactions in the XLSX file by properly considering the parent company hierarchy and transaction company IDs. This improves reporting accuracy for branch financial data.
Original PR description
**Steps to reproduce:** * Install **Accounting** module. * Create a **branch company** with a parent company. * Create and post an invoice for the branch. * Go to **Accounting → Reporting → Profit &…
**Steps to reproduce:** * Install **Accounting** module. * Create a **branch company** with a parent company. * Create and post an invoice for the branch. * Go to **Accounting → Reporting → Profit & Loss**. * Switch to the **branch company**. * Click an report line **⋮ → General Ledger**. * Click **Download XLSX**. **Observed behavior:** * The exported XLSX file is **blank**. * The report displays correctly in the UI, but the XLSX export shows no accounts. **Cause:** * `_get_accounts_with_move_lines` filtered accounts with `account.company_id IN company_ids`, while accounts are defined on the **parent company** and shared with branches via `check_company_domain_parent_of`. When only a branch is selected, no accounts match. * The AML existence check used `aml.company_id = account.company_id`, but AMLs are recorded with the **branch's company_id**, not the parent’s, so the join never matches branch transactions. * Additionally, `export_to_xlsx` passed the raw `options` to `_get_accounts_with_move_lines` instead of the regenerated `report_options`, leading to an inconsistent company context. **Fix:** * Search accounts using the **parent hierarchy**. * Still filter move lines by the selected branch company. * Branches now see parent accounts with only their own transactions in the XLSX export. opw-5902062
This update resolves a problem where ZATCA invoices were being sent with an incorrect issue date due to timezone differences. The fix ensures the invoice date is accurately formatted for ZATCA submission, preventing a common error and improving invoice processing for Saudi Arabia. This change addresses a technical issue related to ZATCA compliance.
Original PR description
When sending an invoice to ZATCA between 21:00 and 23:59 UTC, the following ZATCA error appears: [400] BR-KSA-04: The document issue date (BT-2) must be less than or equal to the current date. This is caused by the field l10n_sa_confirmation_datetime in _post of l10n_sa/account_move, which combines the date and the time in UTC. In _export_invoice_vals, we reconvert this field to UTC+3 (Asia/Riyadh). Example: Current time UTC+3: 2026-02-19 02:45:00 Stored as UTC: 2026-02-18 23:45:00 (Before the fix) Sent to ZATCA as UTC+3: 2026-02-20 02:45:00 (in the future) (After the fix) Sent to ZATCA as UTC+3: 2026-02-19 02:45:00 opw-5450479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a limitation in the General Ledger export by ensuring that branch accounts linked to parent company accounts are now included. Previously, the system excluded these lines, leading to incomplete reporting. This change improves the accuracy of financial reports for branch operations.
Original PR description
The PR #103329 explicitly excludes `account.move.lines` with accounts that do not match their company. However, branches can use the accounts of their parent company, and thus these lines should be reported in a General Ledger export. [opw-5499234](https://www.odoo.com/odoo/unassigned-tasks/5499234)
This update fixes a bug in the General Ledger CSV export by adding an initial balance line, ensuring accurate reporting. It also corrects rounding logic to properly handle currency conversions, improving the reliability of financial data exports. This ensures consistent and accurate financial reporting.
Original PR description
1) 8dfe4c06106029f3f8039afc863bcacf7057106f added a csv export ledger for the general ledger, but it doesn't handle the initial balance. The fix is to call `_get_initial_balance_values` in the export method, as the query doesn't compute the initial balance lines. 2) Also changing the rounding logic, as currently the currency used is always the company currency, but for `amount_currency` it should use `currency_id`. task-5734354
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicate quantities being added to the transfer. The fix ensures that the quantity is saved correctly, preventing data inconsistencies and improving the accuracy of inventory tracking.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899