Daily updates from Odoo
Friday, July 17, 2026
286 changes
23 changes
Resolved issues and error corrections
This fixes an issue that could interrupt the signing workflow when the system is running in debug mode. The signing page now reliably selects the correct signing field even when extra hidden page markers are present, reducing errors for users preparing or completing documents.
Original PR description
Use lastElementChild when retrieving the sign item from the target element. In debug mode, inherited templates may introduce HTML comments into the DOM. Since lastChild return a comment node, accessing classList on the returned node raises an error. Using lastElementChild ensures that the last HTML element is always retrieved, regardless of comment nodes in the DOM. Forward-Port-Of: odoo/enterprise#123991 Forward-Port-Of: odoo/enterprise#122106
Hong Kong IRD payroll reports now use the correct tax year based on employee start or departure dates. The update also enforces required details when an employee departure reason is marked as “other,” helping businesses meet IRD certification and filing requirements.
Original PR description
As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD.
A first submission highlighted a few issues that we are now fixing.
From 19.0:
- In IR56F, the RTN_ASS_YR should be the tax year in which the employee left the company. E.g. after april, the next year.
- In the same report, if the code for the cessation reason is 5 (other), the reason MUST be provided.
From 19.2:
- Same change has to be done when setting RTN_ASS_YR for IR56G
- A same change has to also be done for IR56E, based on the date the employee joined the company.
task-6332150
Forward-Port-Of: odoo/enterprise#124456
Forward-Port-Of: odoo/enterprise#121877The Budget Report now opens much faster for companies with large accounting and purchasing datasets. This fixes timeouts that previously made the report unusable from budget records, improving access to budget tracking and analysis.
Original PR description
**Description** Opening the Budget Report from any budget record times out on databases with significant data volume. The request to `budget.report/formatted_read_grouping_sets` consistently times…
**Description**
Opening the Budget Report from any budget record times out on databases
with significant data volume. The request to
`budget.report/formatted_read_grouping_sets` consistently times out,
making the Budget Report completely unusable.
**Root cause:**
`budget.report` is an SQL view that consists of 5 UNION ALL branches.
When the list view loads, the ORM translates the `budget_analytic_id`
domain into a WHERE clause on the outer query wrapping the full UNION
ALL subquery. PostgreSQL cannot push this filter through a UNION ALL as
it's a hard optimization barrier. It must fully materialize the subquery
regardless of which budget is being viewed.
**Fix:**
Override _search on budget.report to extract budget_analytic_id and
budget_line_id conditions from the incoming domain using the Domain API.
budget_line_id is rewritten as Domain('id', op, value) so _to_sql()
correctly emits bl.id in the raw SQL. The resulting domain is injected
in context under budget_line_domain and read in _get_bl_query,
_get_aal_query (base module), and _get_pol_query (purchase module) to
filter budget_line rows inside each branch's LEFT JOIN ON clause.
This also removes the budget_report_budget_line_ids context key from
budget_line._compute_all, unifying both filters under one mechanism.
---
On customer DB (568k `account_analytic_line`, 27k `budget_line`,
116k confirmed `purchase_order_line`, 114k posted vendor bill lines
with purchase link):
| Budget | Before | After |
|---|---|---|
| 8 lines, 730d span | timeout | 2.27s |
| 14 lines | timeout | 2.39s |
| 14 lines, 1095d span | timeout | 1.63s |
- Before: https://explain.dalibo.com/plan/ehed5eb8de251426
- After: https://explain.dalibo.com/plan/db8aef35cag9hg6f
opw-6098047
Forward-Port-Of: odoo/enterprise#120707
Forward-Port-Of: odoo/enterprise#114692Colombian POS orders containing combo products now generate electronic documents that DIAN can accept. The system excludes zero-priced combo parent lines from the submitted XML, preventing card-paid combo sales from failing validation.
Original PR description
Issue: When ordering through POS combo items won't be accepted by DIAN. Steps to reproduce: Set company to Colombia and activate the DIAN module. Simulate a sell of an combo item with POS. Pay with card. Error will ensue. Cause: The XML sent to DIAN is not accepted because one of the items has 0 price (the combo item). Solution: Not sending lines that are combo items. opw-6232599 Forward-Port-Of: odoo/enterprise#123928 Forward-Port-Of: odoo/enterprise#119652
This fixes an issue where attendee email previews could show an outdated event start date after an event was rescheduled. Attendees now receive emails with the correct updated event timing, reducing confusion for multi-day events.
Original PR description
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to…
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to attendee and Click on Send by Email Observation: ------------------------------------------------ The event start date displayed in the email body is not updated after the event dates are modified. Issue: ------------------------------------------------ In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58 However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f * `event_begin_date` is made stored for cohort view grouping * However, the base compute method only depends on `event_id` and `event_slot_id` https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180 * When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`) * Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work * Stored computed fields only recalculate when their explicit dependencies change Solution: ------------------------------------------------ * Corrected the dependencies of `_compute_event_begin_date` to recompute value on changing the date of the event opw-6284576 Forward-Port-Of: odoo/enterprise#120184
Payroll frequency labels now appear in the user's selected language across core payroll and multiple country-specific payroll modules. This improves clarity for HR users working in localized interfaces, such as French, by showing salary schedule options in the expected language.
Original PR description
Issue: ---------------------------------------- The values of the field `schedule_pay` aren't translated. Steps to reproduce: ---------------------------------------- - Switch the language to French - Open an employee form, "Paie" tab - The selection in the "Salaire" tab is not translated to French Cause: ---------------------------------------- When the selection values were moved to a method in 7a123d71925b25f26ba0a8abff0c4a159147bdd0. The strings were not declared as translatable. opw-6359395 Forward-Port-Of: odoo/enterprise#124504 Forward-Port-Of: odoo/enterprise#123718
Managers will no longer see the Print option twice in the Planning Gantt view. This makes the interface cleaner and reduces confusion when using planning actions.
Original PR description
Issue: - Managers see the "Print" action twice in the Gantt view: once as a standalone button and once in the Actions dropdown. Cause: - The standalone Print button is guarded on `!this.isManager`, but `isManager` lives on the model. The expression is therefore always truthy, so the button always renders. Fix: - Use `!this.model.isManager` instead. task-6364971 Forward-Port-Of: odoo/enterprise#123442
This fixes an error that could occur when validating certain stock operations involving kits in the Kenyan OSCU stock integration. Businesses using the Kenyan localization can complete affected inventory workflows more reliably without unexpected interruptions.
Original PR description
**CAUSE** super()._action_done() delete a record from self, and return a new recordset of stock.moves. We filter the old recordset instead of filtering the new one, leading to an MissingError traceback. **STEP TO REPRODUCE** On a fresh db, install: `l10n_ke,l10n_ke_edi_oscu,l10n_ke_edi_oscu_mrp,l10n_ke_edi_oscu_pos,l10n_ke_edi_oscu_stock,l10n_ke_edi_tremol,l10n_ke_hr_payroll,l10n_ke_hr_payroll_account,l10n_ke_reports` and run `TestKitPicking.test_add_sml_with_kit_to_confirmed_picking`. runbot-241262 Forward-Port-Of: odoo/enterprise#124663
This fixes an issue that prevented exchange rate adjustment entries from appearing in the bank reconciliation widget. Accounting users can now see the expected exchange movements when reconciling bank transactions, reducing confusion and helping reconciliation stay accurate.
Original PR description
Fix a bug where the exchange moves are no more displayed in the bank reco widget. Bug introduced here: https://github.com/odoo/enterprise/pull/119557 no-task Forward-Port-Of: odoo/enterprise#124495
This fixes a crash when downloading or printing German POS receipts that include Fiskaly TSS certification data. Businesses using certified German point-of-sale flows can reliably access receipts from the backend without errors.
Original PR description
With fiskaly in production, when printing the pos receipt, it crashes because the tss values dictionnary is not correctly interacted with. To reproduce: install l10n_de_pos_cert create a DE shop activate fiskaly and the tss in the settings of the POS create an order in the POS and pay it go to the backend, open the pos order and download the receipt it will crash To reproduce without production credentials, you can not activate fiskaly and the tss but still create and pay the pos order. Then, you can change the pos.config to add the l10n_de_fiskaly_tss_id and change the pos.order to add the l10n_de_fiskaly_time_start. Then download the receipt. opw-6356628 Fixes https://github.com/odoo/enterprise/pull/115676 Forward-Port-Of: odoo/enterprise#123473
This update prevents the Avalara tax integration from keeping a proxy connection active when a database is neutralized. It helps avoid unintended external communication from copied or non-production environments while keeping normal business data unchanged.
Original PR description
backport of https://github.com/odoo/enterprise/pull/122024 no-task Forward-Port-Of: odoo/enterprise#124681
This fixes an internal test setup issue in the Timesheet Grid module so automated checks run reliably. It helps prevent false test failures during development and release validation, with no direct change to end-user behavior.
Original PR description
Before this commit, the component was mounted in the `beforeEach` block before its `onRpc` mocks were registered. This caused the initial data fetch to fail because the mocks were not yet available during initialization. This commit fixes the test by moving the component mount (`doAction`) inside the test block, strictly after the mocks are defined. Forward-Port-Of: odoo/enterprise#123683
VoIP call smart buttons now open the same family-wide records that they count, covering the contact and related company contacts. New records created from those actions still default to the original contact person, reducing confusion for sales, CRM, helpdesk, project, and subscription users.
Original PR description
Commit [1] change the smart buttons on voip.call to count records from all family of the partner (count all record from all partners from the partner's company). However, the actions on the buttons stay the same, they will only open records from the partner itself. This is confusing, we change it to also show records from the whole partner family. [1]: 16772c5c1e604d6beb514f9e5b166fc0c2f452a7 Task-6379569
Coding editor activity in the timesheet assistant now uses the correct event category, so it displays with the intended code-related icon. This avoids confusing or missing visual cues when users review assistant events.
Original PR description
In the assistant, events from a coding editor use the "code" event type, which doesn't exist. This PR changes it to the correct value, which is "development". Task-6392585 Forward-Port-Of: odoo/enterprise#124502
Payroll schedule options in the Kuwait payroll localization now appear in the user's selected language. This fixes a missed localization issue so business users see consistent translated labels in payroll configuration.
Original PR description
The values returned by `_get_selection_schedule_pay()` wern't translated. This localization was missed by this forward port: 961bedf91d754cce5d3cdecabe1e504770902d05 opw-6359395
Chilean point-of-sale receipts with SII barcodes now print correctly instead of crashing during receipt generation. This ensures sales can be validated and customers can receive compliant receipts without interruption.
Original PR description
Steps to reproduce: - Have a Chilean company with DTE configured (a resolution number/date and a signed boleta/factura, so the order's move has an SII barcode) - Open a PoS session, pay an order and validate it Issue: The receipt fails to render and printing crashes with: `TypeError: ctx.image.l10n_cl_sii_barcode_image.to_base64 is not a function` Cause: Commit 0b50021bdae adapted this template as part of the BinaryValue migration (odoo/odoo#244421), calling `to_base64()` on the barcode image. However `l10n_cl_sii_barcode_image` is a computed `fields.Char` that already holds a base64 string (`_pdf417_barcode` returns `b64encode(...).decode()`), not a Binary, so it is never wrapped in a `BinaryValue`. Moreover, this template is also rendered client-side by the PoS QWeb engine, where the value loaded from the server is a plain string with no `to_base64` method either. opw-6389718 Forward-Port-Of: odoo/enterprise#124438
Service sale order lines created from field service planning now let Odoo calculate prices automatically. This ensures customer pricelists and product pricing rules are applied correctly instead of being bypassed by a fixed unit price.
Original PR description
Before this commit, in the method `_generate_service_sale_order_lines` the `price_unit` for sale order lines used an explicitly defined unit price. This prevented the pre-computation of the price. It may cause some issues, for example if there was a pricelist defined on the product, we didn't apply the prices from that pricelist. This commit removes explicit definition of the `price_unit` to let the sale order creation process handle it. [error-941068](https://runbot.odoo.com/odoo/error/941068)
The Balance Sheet report now displays numeric column headers with the correct spacing. This small visual fix improves readability and consistency in financial reports without changing any report data or calculations.
Original PR description
Due to `padding: 0.25rem 0.75rem !important;` To reproduce: - Open Balance Sheet - Check the Balance column numeric-header
Opening the template picker from an audit report article without a parent no longer causes an error. Instead, users see a clear message when no article template is available, keeping the audit report editing flow usable.
Original PR description
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to…
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to reproduce: 1. Install `accountant_knowledge`. 2. Create and open a new audit report. 3. Delete all content from article (the root). 4. Click the "Load a Template" button in the helper. => Crash with `AssertionError: Invalid falsy real id.` The issue occurs because the method responsible for loading the annex to display (see: `get_suggested_templates`) expects at least one record in the recordset. When the article has no parent, the recordset is empty, causing the method to fail. Before attempting to load a template, we will check whether the article has a parent article. If no parent exists, no template will be provided to the template picker. In that case, the picker will display a helper message indicating that no article template is available to load. Task [link](https://www.odoo.com/odoo/project.task/6333859) Task-6333859 Forward-Port-Of: odoo/enterprise#121807
This fixes cases where Point of Sale payments could get stuck when websocket connections were unavailable and the system fell back to longpolling. It also corrects Six payment handling in kiosk mode, improving payment reliability for affected stores.
Original PR description
A change from odoo/enterprise#116705 made the `iot_http_service` try to access the `self_ordering_mode` on the session`, leading to longpolling failure on non-self order as data would be undefined. Also, a mistake in error catching in the longpolling service made it so that an event request thrown would abort directly with the previous one, instead of only the previous one. If websocket was unavailable at the same time, it would result on the PoS getting stuck waiting for confirmation of the payment. In addition, we fixed Six payments in Kiosk, failing because it tryed to access `user.id` where user was `undefined`. task-6391166
Colombian electronic invoice XML imports now treat the listed price as the actual unit price, matching DIAN rules. This prevents incorrect negative discounts from appearing on vendor bills when imported products have quantities greater than one.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466 Forward-Port-Of: odoo/enterprise#124567 Forward-Port-Of: odoo/enterprise#122313
This fix prevents an accounting dashboard filter from accidentally affecting document creation during Mexican electronic invoicing payment updates. It avoids an error that could block users from updating payments on CFDI invoices after reconciling bank transactions.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124578 Forward-Port-Of: odoo/enterprise#124074
This fix ensures contract updates use the right template, preferring the current contract version when available or falling back to the template from the salary offer. This helps HR teams avoid incorrect contract documents during offer and contract update workflows.
Original PR description
contract update template should come from current version if any or from the offer's contract template. Task-6094733 Forward-Port-Of: odoo/enterprise#124638 Forward-Port-Of: odoo/enterprise#123450
14 changes
Resolved issues and error corrections
This fixes partner form views for Ecuador and Mexico localization features after a prior layout change caused tax ID-related fields to appear incorrectly or fail to load. Businesses using these localizations should see partner identification information display reliably again.
Original PR description
In previous refactor [1], we wrapped the "vat" field under a "vat_div" div. This broke some xpath depending on the "vat". This commit repair those views. Note: 19.4+ made a second change in the div around the vat and identifiers, the views should already be fixed in upper versions. [1]: https://github.com/odoo/odoo/commit/825e7c803a4effd601fb247c660416f1cc6d26d7 task-6382108
Fixed an issue where changing a product variant's cost could leave the displayed on-sale price one step behind when using cost-based pricelists. This helps sales teams and store operators see accurate pricing right away after cost updates.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update correctly. It gets delayed by one update because the product._origin isn't getting updated with the new onchanged value. Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" updates based on the value before. To fix the issue, we need to update the product._origin for standard_price just like the lst_price before computing the on_sale_price opw-5947995 Forward-Port-Of: odoo/enterprise#122391 Forward-Port-Of: odoo/enterprise#119470
This fixes an error that could appear when payroll users in debug mode filtered the payslip list for Off-Cycle items. The payroll list now handles payslips without a linked pay run correctly, improving reliability for that view.
Original PR description
Before this commit, when the user is in debug mode, goes to payslips list view and applies `Off-Cycle` filter, a traceback is occured saying `Invalid props for component 'PayslipActionHelper': 'payrunId' is not a number`.
The reason is because we search the id of the payrun by parsing the domain applied to fetch payslips displayed inside the list view but `Off-Cycle` filter will apply the following domain: `[('payslip_run_id', '=', False)]` and so False is given to PayslipActionHelper but it is not a number.
This commit makes sure to set undefined to payrunId prop of PayslipActionHelper when `payrun_id` found is falsy.
runbot-error-241053This fix prevents zero-priced combo parent items from being included in the Colombian electronic invoice data sent from Point of Sale. As a result, businesses using Colombian DIAN integration can process and report POS combo sales without rejection errors.
Original PR description
Issue: When ordering through POS combo items won't be accepted by DIAN. Steps to reproduce: Set company to Colombia and activate the DIAN module. Simulate a sell of an combo item with POS. Pay with card. Error will ensue. Cause: The XML sent to DIAN is not accepted because one of the items has 0 price (the combo item). Solution: Not sending lines that are combo items. opw-6232599 Forward-Port-Of: odoo/enterprise#123928 Forward-Port-Of: odoo/enterprise#119652
Bank reconciliation now correctly shows exchange difference entries again. This helps accounting users review and match bank transactions accurately when currency exchange differences are involved.
Original PR description
Fix a bug where the exchange moves are no more displayed in the bank reco widget. Bug introduced here: https://github.com/odoo/enterprise/pull/119557 no-task Forward-Port-Of: odoo/enterprise#124495
The preparation display now keeps restaurant orders in a stable order when staff interact with individual order lines. Orders only move in the queue when they change stage, reducing confusion for kitchen teams after a page reload.
Original PR description
**Steps to reproduce:** - Setup a preparation display - Go to the restaurant - Send an order to the kitchen, with 2 lines - Go to another table and send an order with 2 lines to the kitchen - On the display, click the first line of the first order - Reload the page - Order 1 and order 2 have swapped places **Why the fix:** We are currently sorting the orders based on their write_date, meaning that when we click a line, the write date is updated, and it goes to the end of the line. To prevent this, we are now using **last_stage_change** that is only updated when going from one stage to another. This means the cards will stay in the same order, and go to the back of the line once they change stage. To make it so that they are last when changing stage, we update the **last_stage_change** in the frontend as well when changing stage, because it was only done in the backend before this commit. opw-6361046 Forward-Port-Of: odoo/enterprise#124048
The Timesheets menu icon now appears whenever a user has an active employee record in any selected company, not just the current company. This prevents users from missing access to timesheet entry when they can legitimately create timesheets through another selected company.
Original PR description
Steps to reproduce: - install Timesheets - create an employee for a user in company B - switch to company A (where the user has no employee) - the systray icon is hidden even though the user can…
Steps to reproduce: - install Timesheets - create an employee for a user in company B - switch to company A (where the user has no employee) - the systray icon is hidden even though the user can create timesheets in company B via the company selector Current behavior: the systray only checks the current company for a valid employee, ignoring other selected companies. Expected behavior: the systray should be visible whenever the user can create timesheets i.e. when they have an active employee in any of the selected companies. Issue: the check used a stored boolean on `res.partner` that has no company scope and becomes stale when an employee is archived (the stored dependency does not re-fire). the timesheet creation logic checks all selected companies for active employees, but the systray did not mirror that. Fix: use `employee_ids` a `One2many` that checks all selected companies and excludes archived employees, matching the timesheet creation logic exactly. task-6330539 Forward-Port-Of: odoo/enterprise#121730
New US companies and branches now correctly inherit the journal settings on existing payroll structures during setup. This prevents missing payroll accounting configuration and reduces manual follow-up after creating a company.
Original PR description
Steps to reproduce: 1. A structure related to US, and set journal_id. 2. Create a new US company or branche of the existing company. 3. Go to the created structure, the journal_id is empty. Root cause: After creating a company, _configure_payroll_account should be triggered to finish the configuration. Setting the journal_id for the existing structures (with the same company country) is part of that configuration. The method responsible to call the configuration, is _load_payroll_accounts in account_chart_template.py (hr_payroll_account), and it should call the following method: _configure_payroll_account_generic_coa. This method was deleted in 19.3 and that was the problem. task-6394082
Users can now open the template picker in audit report articles even when the article has no parent. Instead of showing an error, the picker will simply indicate that no article template is available to load.
Original PR description
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to…
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to reproduce: 1. Install `accountant_knowledge`. 2. Create and open a new audit report. 3. Delete all content from article (the root). 4. Click the "Load a Template" button in the helper. => Crash with `AssertionError: Invalid falsy real id.` The issue occurs because the method responsible for loading the annex to display (see: `get_suggested_templates`) expects at least one record in the recordset. When the article has no parent, the recordset is empty, causing the method to fail. Before attempting to load a template, we will check whether the article has a parent article. If no parent exists, no template will be provided to the template picker. In that case, the picker will display a helper message indicating that no article template is available to load. Task [link](https://www.odoo.com/odoo/project.task/6333859) Task-6333859 Forward-Port-Of: odoo/enterprise#121807
Colombian electronic invoice imports now treat the listed price as the actual unit price, matching DIAN rules. This prevents incorrect price reductions from appearing on vendor bills when imported invoice lines use quantities greater than one.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466 Forward-Port-Of: odoo/enterprise#124567 Forward-Port-Of: odoo/enterprise#122313
Preparation tickets now load the needed styling again after a receipt printing refactor caused them to lose parts of their layout. The update also restores missing receipt details, improves related POS UI elements, and ensures customer notes print correctly.
Original PR description
..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores the missing data and improves the overall UI. It also fixes an issue where customer notes were not printed on the receipt. Templates checked: * point_of_sale.pos_order_change_receipt * point_of_sale.pos_order_change_receipt_line --- Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Refacto: https://github.com/odoo/odoo/pull/244395 Forward-Port-Of: odoo/enterprise#118782
Point of Sale tax calculations with AvaTax now use the company/store location instead of requiring a customer address. This makes tax handling more reliable for regular in-store sales and fixes quantity-related subtotal calculations.
Original PR description
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on…
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on pos_warehouse_id This could be useful in very obscure scenarios (B2B sales, traveling salesmen), but for those cases customers can already use our Avatax integration on sale orders. We want this module to be useful for normal B2C POS sales. Taxes they charge are the same regardless of where the customer may live. This commit makes many changes: - Stop requiring a customer to be selected, - Always calculate local sales (from company location to company location) if the Avatax option is enabled on pos.config, - Fix a bug where price_subtotal is not multiplied by quantity, - Removes copy/pasted code from sale.order that serves no purpose, This makes the module useful for companies that don't want to manually figure out what taxes to charge. This could be especially useful for companies with many shops in different locations. A tour test was added to make sure the module keeps working. The test added before [1] was removed because it was redundant and less complete than the one included here. This is deliberately not backported to Odoo 18 [2]. We keep the current behavior there. [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Closes odoo/enterprise#82779 task-4710463 Forward-Port-Of: odoo/enterprise#124370 Forward-Port-Of: odoo/enterprise#123190
This fix ensures salary contract updates use the right template, preferring the current contract version when available and otherwise using the template from the original offer. This helps HR teams generate accurate contract update documents and reduces the risk of using an incorrect template.
Original PR description
contract update template should come from current version if any or from the offer's contract template. Task-6094733 Forward-Port-Of: odoo/enterprise#124638 Forward-Port-Of: odoo/enterprise#123450
Fixes an error that could block updating payments on Mexican electronic invoices after users grouped accounting dashboard records by type. The change ensures unrelated screen filters do not interfere when creating document attachments, making the payment update flow more reliable.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124578 Forward-Port-Of: odoo/enterprise#124074
20 changes
Resolved issues and error corrections
The Timesheets systray icon now appears for users who have an active employee record in any selected company, not just the currently active company. This prevents eligible users in multi-company setups from losing quick access to timesheet entry.
Original PR description
Steps to reproduce: - install Timesheets - create an employee for a user in company B - switch to company A (where the user has no employee) - the systray icon is hidden even though the user can…
Steps to reproduce: - install Timesheets - create an employee for a user in company B - switch to company A (where the user has no employee) - the systray icon is hidden even though the user can create timesheets in company B via the company selector Current behavior: the systray only checks the current company for a valid employee, ignoring other selected companies. Expected behavior: the systray should be visible whenever the user can create timesheets i.e. when they have an active employee in any of the selected companies. Issue: the check used a stored boolean on `res.partner` that has no company scope and becomes stale when an employee is archived (the stored dependency does not re-fire). the timesheet creation logic checks all selected companies for active employees, but the systray did not mirror that. Fix: use `employee_ids` a `One2many` that checks all selected companies and excludes archived employees, matching the timesheet creation logic exactly. task-6330539
This fix ensures Norwegian SAF-T exports use the correct official account grouping when account numbers are extended. It helps businesses avoid incorrect grouping codes in compliance reports submitted or reviewed for Norwegian accounting requirements.
Original PR description
Steps to reproduce: - change 1920 Banck account to 19204321 - go in general ledger and export to "SAF-T" Issue: The grouping code is 4321 Grouping code should match official grouping code. As a matter of fact the chart of account seems to match thos grouping account if we slice them correctly. opw-6285078 Forward-Port-Of: odoo/enterprise#122213 Forward-Port-Of: odoo/enterprise#121932
The test setup for Odoo Cloud Notifications now matches real behavior by registering devices only for internal users. This reduces false test coverage around users who should not receive these notifications and helps keep notification reliability checks accurate.
Original PR description
Only devices of internal users are registered in order to send them Odoo Cloud Notifications (OCN). However, the test setup registers devices for non-internal users as well. This commit ensures devices are only registered for internal users. Forward-Port-Of: odoo/enterprise#119956
Colombian electronic invoice imports now read the unit price correctly when the XML includes a base quantity greater than one. This prevents incorrect negative discounts on vendor bills and helps imported bills match DIAN invoice totals.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466 Forward-Port-Of: odoo/enterprise#124400 Forward-Port-Of: odoo/enterprise#122313
Creating an employee contract from a template now also copies the template's analytic distribution. This prevents missing cost allocation information on new contracts and reduces manual correction for payroll accounting.
Original PR description
Problem: When creating a new contract from a template, the analytic distribution field is not copied from the template to the contract. Steps to reproduce: 1. Create a contract template with an analytic distribution. 2. Create a new contract for an employee from the template. 3. Check the analytic distribution field on the new contract. 4. Notice how the analytic distribution field is empty, even though it was set on the template. Cause: The field is not included in the list of whitelisted fields to copy from the template. https://github.com/odoo/odoo/blob/0133e46f89df7dce8c39d2bacd29579d57a83fad/addons/hr/models/hr_version.py#L443 opw-6370781 Forward-Port-Of: odoo/enterprise#123955
Uruguayan electronic invoices now avoid adding extra blank lines between configured addenda text and invoice terms. This helps prevent addenda content from being pushed onto a separate page when it should fit on the same page.
Original PR description
## Context When generating a CFE (Comprobante Fiscal Electrónico) that contains both a configured addenda (e.g. bank account details stored in `l10n_uy_edi_addenda_ids`) and terms & conditions from…
## Context
When generating a CFE (Comprobante Fiscal Electrónico) that contains both a configured addenda (e.g. bank account details stored in `l10n_uy_edi_addenda_ids`) and terms & conditions from the invoice's `narration` field, the resulting addenda string could end up with unnecessary blank lines between the two sections, causing the addenda to be rendered on a separate page even when the logical content fits within the 6-line threshold.
## Root Cause
`_l10n_uy_edi_get_addenda` joins both parts without stripping whitespace from either of them first, and adds two lines between addendas and terms and conditions:
addenda = addenda + "\n\n" + term_and_conditions if addenda else term_and_conditions
Two sources independently introduce extra newlines around the separator:
1. **Addenda content** — `_get_legends` returns the raw `content` field value of each addenda record. These fields commonly end with a trailing `\n`, so the addenda string already ends with a newline before the `"\n"` separator is concatenated.
2. **`html2plaintext`** — the `narration` field is stored as HTML. When converted to plain text, `html2plaintext` typically wraps paragraph content in leading/trailing newlines.
The combination of the trailing `\n` from the addenda, the explicit `"\n\n"` separator, and the leading/trailing `\n` from `html2plaintext` produces 2–3 consecutive newlines, which `splitlines()` counts as blank lines.
A realistic 4-line addenda + 1-line narration thus produces **7 lines** instead of the expected 5, crossing the 6-line threshold in `_get_report_params` and triggering `adenda=true` — which forces the addenda onto a separate page unnecessarily.
## Steps to Reproduce
1. Configure a `l10n_uy_edi.addenda` record of type `addenda` with multi-line content (4 lines)
2. Create and confirm an invoice with `narration` set to a short single-line term
3. Generate the CFE PDF via Uruware.
4. Observe that the addenda is rendered on a separate page despite the logical content being only 5 lines.
<img width="1042" height="448" alt="image" src="https://github.com/user-attachments/assets/b538211c-5f37-4648-979d-99cd75cf31c2" />
## Fix
Strip leading and trailing whitespace (including newlines) from both parts before joining them. The ternary is also replaced with an explicit `if/else` for clarity:
def _l10n_uy_edi_get_addenda(self):
addenda = self.l10n_uy_edi_document_id._get_legends("addenda", self)
if self.narration:
term_and_conditions = html2plaintext(self.narration).strip()
if addenda:
addenda = addenda.strip() + "\n" + term_and_conditions
else:
addenda = term_and_conditions
return self._l10n_uy_edi_clean_non_ascii_chars(addenda)
This guarantees exactly one `\n` separator between sections regardless of how the content fields were stored or how `html2plaintext` formatted the narration.
The threshold logic in `_get_report_params` is unchanged: addendas that genuinely exceed 6 lines (after wrapping at 140 chars) continue to be printed on a dedicated page.
Result
<img width="1117" height="456" alt="image" src="https://github.com/user-attachments/assets/3a2d942c-8c37-40f6-bc25-470c0bd25b08" />
Forward-Port-Of: odoo/enterprise#119283Avalara tax calculation in Point of Sale now works for standard in-store sales without requiring a customer to be selected. Taxes are calculated based on the company/store location, fixing incorrect customer-address-based tax results and quantity subtotal issues for retailers with multiple shops.
Original PR description
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on…
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on pos_warehouse_id This could be useful in very obscure scenarios (B2B sales, traveling salesmen), but for those cases customers can already use our Avatax integration on sale orders. We want this module to be useful for normal B2C POS sales. Taxes they charge are the same regardless of where the customer may live. This commit makes many changes: - Stop requiring a customer to be selected, - Always calculate local sales (from company location to company location) if the Avatax option is enabled on pos.config, - Fix a bug where price_subtotal is not multiplied by quantity, - Removes copy/pasted code from sale.order that serves no purpose, This makes the module useful for companies that don't want to manually figure out what taxes to charge. This could be especially useful for companies with many shops in different locations. A tour test was added to make sure the module keeps working. The test added before [1] was removed because it was redundant and less complete than the one included here. This is deliberately not backported to Odoo 18 [2]. We keep the current behavior there. [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Closes odoo/enterprise#82779 task-4710463 Forward-Port-Of: odoo/enterprise#124169 Forward-Port-Of: odoo/enterprise#123190
Long timesheet descriptions in the assistant now expand dynamically instead of being cut off. This makes it easier for users to review and understand detailed time entries without losing important context.
Original PR description
- changed the description field to expand dynamically to display long descriptions in full instead of truncating them in the assistant Task-6348575
Colombian point-of-sale orders that include combo products can now be accepted by DIAN. The fix avoids sending zero-priced combo parent lines in the electronic document, preventing card-paid combo sales from failing validation.
Original PR description
Issue: When ordering through POS combo items won't be accepted by DIAN. Steps to reproduce: Set company to Colombia and activate the DIAN module. Simulate a sell of an combo item with POS. Pay with card. Error will ensue. Cause: The XML sent to DIAN is not accepted because one of the items has 0 price (the combo item). Solution: Not sending lines that are combo items. opw-6232599 Forward-Port-Of: odoo/enterprise#123928 Forward-Port-Of: odoo/enterprise#119652
This fix ensures Saudi GOSI social insurance contributions are calculated on the full eligible salary instead of being reduced incorrectly. It helps payroll teams produce more accurate payslips and accounting entries for Saudi employees.
Original PR description
task-id: 6380239 Forward-Port-Of: odoo/enterprise#124323 Forward-Port-Of: odoo/enterprise#124122
This fixes an issue where exchange rate adjustment entries were no longer shown in the bank reconciliation widget. Users can now see the relevant exchange moves again, helping accounting teams reconcile bank transactions accurately.
Original PR description
Fix a bug where the exchange moves are no more displayed in the bank reco widget. Bug introduced here: https://github.com/odoo/enterprise/pull/119557 no-task Forward-Port-Of: odoo/enterprise#124495
Odoo Studio now handles field labels written with non-Latin characters, such as Arabic, without triggering an invalid custom field name error. This lets users rename fields in their preferred language without being blocked by the system.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027 Forward-Port-Of: odoo/enterprise#122094 Forward-Port-Of: odoo/enterprise#121343
Users with IoT access but without Point of Sale access can now enable LNA on an IoT box without encountering an access error. This removes an unnecessary permission-related blocker and makes IoT box setup smoother for authorized IoT users.
Original PR description
Before this commit, if a user who has IoT permissions but not POS permissions tries to enable LNA on an IoT box record, they will receive an Access Error. After this commit, a `sudo` is added to the `onchange` handler fixing the issue. task-6392548
Preparation display orders no longer move around just because a kitchen line is clicked or refreshed. Orders now keep their position until they actually move to another preparation stage, making the restaurant workflow more predictable for staff.
Original PR description
**Steps to reproduce:** - Setup a preparation display - Go to the restaurant - Send an order to the kitchen, with 2 lines - Go to another table and send an order with 2 lines to the kitchen - On the display, click the first line of the first order - Reload the page - Order 1 and order 2 have swapped places **Why the fix:** We are currently sorting the orders based on their write_date, meaning that when we click a line, the write date is updated, and it goes to the end of the line. To prevent this, we are now using **last_stage_change** that is only updated when going from one stage to another. This means the cards will stay in the same order, and go to the back of the line once they change stage. To make it so that they are last when changing stage, we update the **last_stage_change** in the frontend as well when changing stage, because it was only done in the backend before this commit. opw-6361046 Forward-Port-Of: odoo/enterprise#124048
Payroll CFDI files now correctly include the employer CURP when the Mexican company record represents an individual. This prevents document generation errors for employers using fiscal regime 621 with a 13-character RFC.
Original PR description
Issue: ---------------------------------------- There is a fiscal regime where the company is actually an individual but is authorized to generate documents. Steps to reproduce:…
Issue: ---------------------------------------- There is a fiscal regime where the company is actually an individual but is authorized to generate documents. Steps to reproduce: ---------------------------------------- - Install "l10n_mx_hr_payroll_account_edi" - Change the current company fiscal regime to '621' - Add an VAT of length 13 to the current company - Add a CURP number on the current company - In Payroll generate a payslip, validate it - Post the Journal entry - On the payslip, click "Generate CFDI" - An error is returned, saying the Emisor:Curp applies to individuals Cause: ---------------------------------------- An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'. We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML. Solution: ---------------------------------------- We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present. opw-6351558 Forward-Port-Of: odoo/enterprise#124027
Studio approval rules that check restricted customer-related fields now work without causing access errors for users who lack accounting permissions. This prevents valid sales order confirmations from being interrupted while keeping the approval logic in place.
Original PR description
Issue: A studio.approval.rule.domain includes a related field that calls an access rights group that the user who used the action isn't apart of, Is blocked by the filtered_domain. To Replicate: 1) Install studio, sale, Accounting and make sure "account_followup" is installed 2) create a related field on the sales.order form related to "customer -> follow up status" 3) Save 4) Create a "Studio Approval Rule" (studio.approval.rule) with a domain using the new related studio field -> method : "action_confirm" -> approver:admin 5) create a test user with no accounting access rights 6) in an incognito browser try and create a sales order, and then confirm it. it will throw the access rights error Fix: add a sudo to the filtered_domain opw-6316069 Forward-Port-Of: odoo/enterprise#121856
Duplicating certain Sign templates with multiple documents, signers, and fields no longer fails due to repeated signer role handling. This helps users reliably reuse complex signing templates without manual recreation or support intervention.
Original PR description
Issue: This [loop](https://github.com/odoo-dev/enterprise/blob/55bb2cc570451361701d53583f019ed832a5e5d3/sign/models/sign_item.py#L59-L63) runs multiple times with the same approvers(sign.item.role), but doesn't take into account the already 'seen map' inside the base copy function for batching. If they are already seen they will return a non-iterable [None]. To replicate: 1) Sign -> Template -> upload PDF 2) Go into the template 3) Add 2 Documents, with 2 signers and multiple fields on both documents 4) Save -> gear Icon -> make into template 5) Go back to the list view of templates 6) Select the template -> Gear Icon -> Duplicate Fix: add an already seen check to skip if already seen. opw-6352408 Forward-Port-Of: odoo/enterprise#122667
Opening the template picker from a root audit report article no longer triggers an error. If no parent article exists, the picker now simply shows that no template is available, allowing users to continue their work without interruption.
Original PR description
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to…
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to reproduce: 1. Install `accountant_knowledge`. 2. Create and open a new audit report. 3. Delete all content from article (the root). 4. Click the "Load a Template" button in the helper. => Crash with `AssertionError: Invalid falsy real id.` The issue occurs because the method responsible for loading the annex to display (see: `get_suggested_templates`) expects at least one record in the recordset. When the article has no parent, the recordset is empty, causing the method to fail. Before attempting to load a template, we will check whether the article has a parent article. If no parent exists, no template will be provided to the template picker. In that case, the picker will display a helper message indicating that no article template is available to load. Task [link](https://www.odoo.com/odoo/project.task/6333859) Task-6333859 Forward-Port-Of: odoo/enterprise#121807
Phone call records now hide related action buttons when no customer or contact is attached, preventing errors from unexpected clicks. Subscription shortcuts were also aligned with the standard customer view so users see consistent behavior across apps.
Original PR description
Same as in [1], we don't show smart buttons when no partner to prevent unexpected errors. Also remove `invisible="subscription_count == 0"` to make it same as smart button on res.partner. [1]: 0fbb730e02de22b196a45455f801e96321a75167
This fix prevents an accounting view setting from interfering when Odoo creates document attachments for Mexican electronic invoicing. Businesses using CFDI payments can update payment information without encountering an unexpected error caused by the prior dashboard filter context.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124578 Forward-Port-Of: odoo/enterprise#124074
8 changes
Resolved issues and error corrections
Odoo Studio now handles field labels written with non-Latin characters, such as Arabic, without creating an invalid internal field name. This prevents users from seeing an error when renaming custom fields in these languages, making Studio more reliable for multilingual teams.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027 Forward-Port-Of: odoo/enterprise#122094 Forward-Port-Of: odoo/enterprise#121343
Studio approval rules now work when their conditions reference fields that the acting user cannot directly access. This prevents sales order confirmations and similar actions from being blocked by an access rights error, improving reliability for users with limited permissions.
Original PR description
Issue: A studio.approval.rule.domain includes a related field that calls an access rights group that the user who used the action isn't apart of, Is blocked by the filtered_domain. To Replicate: 1) Install studio, sale, Accounting and make sure "account_followup" is installed 2) create a related field on the sales.order form related to "customer -> follow up status" 3) Save 4) Create a "Studio Approval Rule" (studio.approval.rule) with a domain using the new related studio field -> method : "action_confirm" -> approver:admin 5) create a test user with no accounting access rights 6) in an incognito browser try and create a sales order, and then confirm it. it will throw the access rights error Fix: add a sudo to the filtered_domain opw-6316069 Forward-Port-Of: odoo/enterprise#121856
Bank reconciliation list views now show the same supporting attachments as the kanban view. This helps accounting users see the right documents consistently when reviewing and reconciling bank statement lines.
Original PR description
The aim of this commit is showing the same attachment in the bank reconciliation list view than in the kanban view. Before this commit, the field used to display the attachments was attachment_ids, this field were a related on the attachment_ids from account.move. This fix, removes the related to only keep a domain on the One2Many field. Thanks to the relational database, Odoo is giving us the right attachments when we want to display the field. task-6153002
Polish currency rates no longer need an extra one-day date adjustment because the system already uses the previous day’s rate. This prevents rates from being dated too far back and helps keep accounting calculations aligned with Polish requirements.
Original PR description
In Poland, it is mandatory to use the previous day's currency rate. We used to achieve this by shifting the rate's date by one day. Since https://github.com/odoo/odoo/pull/231948, we already use the previous day's rate, so the shift is no longer needed. See: https://www.odoo.com/mail/message/1118975071
Preparation display orders no longer jump around when staff interact with individual order lines. Orders now keep their position until they move to a new preparation stage, making kitchen workflows easier to follow after a refresh.
Original PR description
**Steps to reproduce:** - Setup a preparation display - Go to the restaurant - Send an order to the kitchen, with 2 lines - Go to another table and send an order with 2 lines to the kitchen - On the display, click the first line of the first order - Reload the page - Order 1 and order 2 have swapped places **Why the fix:** We are currently sorting the orders based on their write_date, meaning that when we click a line, the write date is updated, and it goes to the end of the line. To prevent this, we are now using **last_stage_change** that is only updated when going from one stage to another. This means the cards will stay in the same order, and go to the back of the line once they change stage. To make it so that they are last when changing stage, we update the **last_stage_change** in the frontend as well when changing stage, because it was only done in the backend before this commit. opw-6361046 Forward-Port-Of: odoo/enterprise#124048
Invoices marked as excluded from follow-up are now also left out of follow-up email attachments and printed follow-up letters. This prevents customers from receiving documents for invoices the business intentionally removed from collection reminders.
Original PR description
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the…
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice. 3. Open the contact form and click on the Customer Statement smart button 4. Exclude the invoice using the 'No Follow-Up' toggle 5. In the Accounting tab in the contact form, click on send 6. Open the internal link of the Content Template, go to the options tab and select 'Print Follow-up Letter' in Dynamic Reports 7. Save the configuration and send the email Issue: Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF. Why this happens: Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless. opw-6310602 Forward-Port-Of: odoo/enterprise#124541 Forward-Port-Of: odoo/enterprise#122249
Email buttons for appointments and event registrations now use the website tied to the appointment or event instead of a generic or recently used website address. This prevents customers on multi-website setups from being sent to the wrong site when managing bookings or registrations.
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from…
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. Case 1: - Have website A and website B - Create an appointment page website A - Log in via website B - As public user, make an appointment in Website A - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url. This parameter is then used as fallback when we need to retrieve the base url without an active record Case 2: - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf opw-4146760 opw-4336369 Forward-Port-Of: odoo/enterprise#124555 Forward-Port-Of: odoo/enterprise#122669
Fixes how salary contract updates choose their template, using the current contract version when available or the offer's template otherwise. This helps HR teams generate contract updates with the expected document structure and reduces manual corrections.
Original PR description
contract update template should come from current version if any or from the offer's contract template. Task-6094733 Forward-Port-Of: odoo/enterprise#124638 Forward-Port-Of: odoo/enterprise#123450
6 changes
Resolved issues and error corrections
French VAT declarations now handle SIRET numbers entered with spaces, preventing avoidable submission failures. The process also checks bank account number formatting and warns users before sending if the details look incorrect.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745 Forward-Port-Of: odoo/enterprise#124448 Forward-Port-Of: odoo/enterprise#120689
Invoices marked as excluded from follow-up are now also left out of follow-up email attachments and printed follow-up letters. This prevents customers from receiving documents for invoices the business intentionally removed from follow-up communications.
Original PR description
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the…
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice. 3. Open the contact form and click on the Customer Statement smart button 4. Exclude the invoice using the 'No Follow-Up' toggle 5. In the Accounting tab in the contact form, click on send 6. Open the internal link of the Content Template, go to the options tab and select 'Print Follow-up Letter' in Dynamic Reports 7. Save the configuration and send the email Issue: Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF. Why this happens: Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless. opw-6310602 Forward-Port-Of: odoo/enterprise#124541 Forward-Port-Of: odoo/enterprise#122249
Odoo Studio now handles field labels written with non-Latin characters, such as Arabic, without triggering an invalid field name error. This lets users rename fields in their own language more reliably and avoids interruptions when customizing views.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027 Forward-Port-Of: odoo/enterprise#122094 Forward-Port-Of: odoo/enterprise#121343
This fix makes the POS barcode lookup feature check product creation permissions immediately and consistently. It helps avoid situations where users might see incorrect product creation options due to delayed permission checks.
Original PR description
Replace the asynchronous `allowProductCreation` method with the `hasProductCreationAccess` getter to evaluate product creation permissions synchronously and ensure consistent behavior. Task-6361787 Related PR: https://github.com/odoo/odoo/pull/274420 Forward-Port-Of: odoo/enterprise#124527 Forward-Port-Of: odoo/enterprise#123073
This fix prevents an unrelated screen filter from interfering when payment documents are updated for Mexican electronic invoices. It avoids an error that could block users from updating payments after reconciling invoices, improving reliability in the accounting workflow.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124074
Resetting a submitted tax return no longer removes the global tax lock date for everyone. This keeps closed VAT periods protected while still allowing authorized users to use temporary lock-date exceptions when corrections are needed.
Original PR description
To reproduce the issue: 1) Initialize a company in Belgium, create the tax returns 2) Submit the VAT return from January 3) Open the lock date wizard. The tax lock date is January 31st. 4) Add a lock…
To reproduce the issue:
1) Initialize a company in Belgium, create the tax returns 2) Submit the VAT return from January
3) Open the lock date wizard. The tax lock date is January 31st. 4) Add a lock date exception removing the tax lock date just for you, for 5 min. 5) Reset January's return
6) Reopen the lock date wizard.
====> Your exception is still there, but the tax lock date for everyone has been reset to December 31st.
This is plain wrong. Resetting a return should not automatically reopen the period for everyone. Lock dates exceptions/modifications are anyway required to reset the return ; they should pilot the whole flow. Nothing being magically hidden from the user means there can't be someone else mistakenly encoding something into the reopened period.
Another fix was required to make this one work: setting the tax lock date before submitting the return should work. In bigger environments, users might want to do that as a first step to reduce the number of people encoding data before actually doing the submission of the return. Therefore, the case where the tax lock date is already set at the date_to of the return when submitting it was supposed to be already supported, and allow the creation of the closing entry for that return, despite it being on the tax lock date. The test ensuring this was however badly written, and the feature didn't work: the closing was created at a later date than the lock date automatically, due to the Bills' Algorithm.8 changes
Resolved issues and error corrections
This fixes an invoicing issue for Argentine electronic invoices where using an unsupported ID type for a final consumer could cause a system error. Users will now receive a clear warning to use the correct identification type, helping prevent failed invoice confirmations and confusion.
Original PR description
After applying the community fix, a new issue appears in enterprise. **Steps to reproduce:** - Install the `l10n_ar_edi` module. - Go to Customers and create a new customer with: - Country: Argentina…
After applying the community fix, a new issue appears in enterprise. **Steps to reproduce:** - Install the `l10n_ar_edi` module. - Go to Customers and create a new customer with: - Country: Argentina - Identification Type: `Passport` - Identification Number: `1234567890a` - AFIP Responsibility Type: `Consumidor Final` - Create a new invoice for this customer with: - Journal: `Electronic Invoice (FE)` - Document Type: `(6) INVOICES B` - Try to confirm the invoice. **Error:** ValueError: invalid literal for int() with base 10: '1234567890a' **Expected behaviour:** For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, the identification type must be `DNI` or `CUIL/CUIT`. If another identification type is used, the user should receive a proper warning instead of a traceback. (see [1]) **Root Cause:** After the community fix, `_get_id_number_sanitize()` can return an alphanumeric value, which is later converted with `int()` at [2] and [3], causing an error. **Fix:** This commit adds an explicit validation for Argentinean contacts with AFIP Responsibility Type Consumidor Final before converting the identification number to an integer, ensuring the user receives the proper warning message. [1]: https://www.odoo.com/mail/message/1118392033 [2]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798 [3]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931 Related community PR: https://github.com/odoo/odoo/pull/272651 opw-6333998
Odoo Studio now handles field labels written with non-Latin characters, such as Arabic, without creating an invalid internal field name. This prevents an error when users rename custom fields and makes Studio more usable for multilingual teams.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027 Forward-Port-Of: odoo/enterprise#122094 Forward-Port-Of: odoo/enterprise#121343
Swiss QR-IBAN payment references are now cleaned before payment files are generated, removing unsupported characters such as the degree symbol. This helps prevent ISO 20022 bank payment files from being rejected by Swiss banks while keeping valid QR references intact.
Original PR description
**Steps to reproduce:** * Configure a Swiss company with the Swiss accounting localization. * Install `account_sepa`. * Configure a bank journal with a valid Swiss **QR-IBAN**. * Create a vendor with…
**Steps to reproduce:** * Configure a Swiss company with the Swiss accounting localization. * Install `account_sepa`. * Configure a bank journal with a valid Swiss **QR-IBAN**. * Create a vendor with a valid Swiss bank account. * Under **Accounting -> Configuration -> Settings** enable QR Payments. * Go to the vendor and enter the correct QR-IBAN number under the Accounting Section. * Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the account number of QR-IBAN. * Create and post a vendor payment using the bank journal. * Set the payment reference (`ref`) to contain the `°` character. * Add the payment to a batch payment and generate the ISO 20022 payment file. * Inspect the generated XML. **Observed Behaviour:** The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that may be rejected by Swiss banks because it does not comply with the EPC minimum character set. **Cause:** The QR-IBAN branch validates the structured reference before sanitizing it, allowing unsupported characters to remain in the generated XML. **Fix:** Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters are removed while preserving valid QR references. opw - 6350931 Forward-Port-Of: odoo/enterprise#124105 Forward-Port-Of: odoo/enterprise#123267
The point of sale barcode lookup now checks product creation permissions in a more consistent way. This helps ensure users only see or use product creation options when their access rights allow it, reducing confusing behavior at checkout.
Original PR description
Replace the asynchronous `allowProductCreation` method with the `hasProductCreationAccess` getter to evaluate product creation permissions synchronously and ensure consistent behavior. Task-6361787 Related PR: https://github.com/odoo/odoo/pull/274420 Forward-Port-Of: odoo/enterprise#123073
Delivery guides for Chilean electronic stock documents no longer fail when a kit includes components measured in a different unit category than the kit itself. The system now prices those component lines from the product instead of forcing an incompatible sale order unit conversion, allowing users to print delivery guides successfully.
Original PR description
When a kit is delivered, each component move is linked to the kit's sale order line. Pricing the delivery guide in "sale order" mode converted the component quantity into the kit's sale UoM. For a component sold in a different UoM category than the kit, this cross-category conversion raises a UserError. Steps to reproduce: - Create a BoM for a kit product with a component in a different UoM category - Create a customer with Delivery Guide Price = "From Sale Order" - Sold the kit in a sale order and deliver it - On the delivery, print the delivery guide -> error This fix makes the guide price for a component move to be "product" if the component's product is different from the related sale line product, avoiding the cross-category UoM conversion. opw-6327895 Forward-Port-Of: odoo/enterprise#122776
This fixes an issue where resetting certain Uruguay electronic invoicing records to draft could fail when triggered remotely. The change ensures the action returns a valid response, preventing avoidable errors during accounting workflows.
Original PR description
Calling the method in RPC causes an error: ``` TypeError: cannot marshal None unless allow_none is enabled ``` Forward-Port-Of: odoo/enterprise#124653
Users can no longer trigger a server error by creating a new commission adjustment recipient directly from the adjustment list. The change prevents an invalid entry path, keeping the Sales Commission adjustments screen stable.
Original PR description
Steps to reproduce: - Go to Sales > Commission > Adjustments - In Add to/Reduce From, type a name with no match - Click Create '<name>' -> server crashes (RPC_ERROR) Cause: `sale.commission.plan.user._rec_name` is a Many2one (`user_id`). Default `name_create` wrote the typed text into that integer column, which Postgres rejected. Fix: - Disable quick-create on `add_user_id`/`reduce_user_id` in the Adjustments list view Version: saas-18.3 to master opw-6384909
This fixes an issue where updating payments for Mexican electronic invoices could fail after users grouped accounting records by type. The system now ignores unrelated default values when creating document attachments, preventing errors and allowing payment updates to complete normally.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124074
1 change
Resolved issues and error corrections
Employees can now access and sign signature requests sent to their private email address. The request remains linked to the employee’s existing contact record, avoiding access problems while still delivering the email to the private address.
Original PR description
Before, when a signature request was sent to an employee's private email address, a new partner was created with the private email address and the signature request was linked to that new partner. Since there is a security rule where an employee cannot access a sign request item unless the partner on it matches partner for that employee, the employee is not able to see the sign request as the linked partner to the sign request item is an entirely new partner that is not linked to the employee. To fix the issue, the sign request is now linked to the employee's partner but the email itself is sent to the employee's private email. Task-5358107
10 changes
Resolved issues and error corrections
The salary contract flow now uses the right update template, taking it from the current contract version when available or from the offer's contract template otherwise. This helps ensure contract updates generated from offers follow the intended template and reduces manual corrections.
Original PR description
contract update template should come from current version if any or from the offer's contract template. Task-6094733 Forward-Port-Of: odoo/enterprise#123450
This fix prevents an intermittent error when the signing document preview closes or reloads at just the wrong moment. It helps keep automated checks stable and reduces the chance of unexpected signing interface errors.
Original PR description
Due to a race condition, in the PDFIframe sometimes the Iframe gets detached before we access it and we therefore have this.root.defaultView = null. Since when the Iframe is detached we don't really care about defining the eventBus, we can fix the problem related to its assignation by first checking the value of this.root.defaultView and only continuing in case it has one. This PR fixes a runbot error. Runbot Error: 233524
The barcode app now correctly finds manufacturing orders that were split into multiple related orders. This prevents users from seeing a false “not found” error when scanning the original manufacturing order name, keeping shop floor workflows moving smoothly.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM: 1 X COMP (enough units in stock) - Create and confirm an MO for 3 units - Click on the cog wheel icon > Split the MO in 3 - On the barcode app > Operations > Manufacturing - Scan the name of your base MO #### > Error: No product or order found for barcode ... ### Expected behavior: Scanning an existing MO only adds its barcode as a `search_default_name`: https://github.com/odoo/enterprise/blob/598a8e335605fd68e3ceb5c1170864243426f994/stock_barcode_mrp/models/mrp_production.py#L162-L178 However, while this search is performed with an ilike, we only check the existence of an exact match before raising an error, which does not happen since our splitted MOs have a name: barcode-001, barcode-002, barcode-003,... opw-6376937
Invoices marked as excluded from follow-up are now consistently left out of follow-up email attachments and printed follow-up letters. This prevents customers from receiving documents for invoices the business has intentionally removed from follow-up actions.
Original PR description
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the…
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice. 3. Open the contact form and click on the Customer Statement smart button 4. Exclude the invoice using the 'No Follow-Up' toggle 5. In the Accounting tab in the contact form, click on send 6. Open the internal link of the Content Template, go to the options tab and select 'Print Follow-up Letter' in Dynamic Reports 7. Save the configuration and send the email Issue: Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF. Why this happens: Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless. opw-6310602 Forward-Port-Of: odoo/enterprise#124541 Forward-Port-Of: odoo/enterprise#122249
This update adds automated test coverage to ensure currency translation adjustments use the correct exchange rates when the company currency changes during the year. It helps prevent incorrect financial reporting values in multi-currency scenarios, especially around average and historical exchange rates.
Original PR description
Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency. Scenario 2: fluctuating domestic (USD) rate USD rate=1 from Jan 1 to Jun 30, USD rate=3 from Jul 1 to Dec 31 EUR rates unchanged: 2 from Jan 1, 4 from Jul 1 Correct conversion factors (= USD_rate / EUR_rate): Jan 1 – Jun 30 (182 days): 1/2 = 0.50 Jul 1 – Dec 31 (184 days): 3/4 = 0.75 Current rate at 2020-12-31: 3/4 = 0.75 Correct average rate: (0.50 * 182 + 0.75 * 184) / 366 = 229/366 ≈ 0.62568 Previsouly bugged average rate (USD fixed at current=3): (1.50 * 182 + 0.75 * 184) / 366 = 411/366 ≈ 1.12295 Historical equity rates (correct vs previously bugged): Mar 1 (USD=1, EUR=2): correct = 1/2 = 0.50; buggy = 3/2 = 1.50 → 40 * 0.50 = 20 vs 40 * 1.50 = 60 Oct 1 (USD=3, EUR=4): correct = 3/4 = 0.75; buggy = 3/4 = 0.75 → 60 * 0.75 = 45 (same by coincidence) task-5953104
Odoo Studio no longer fails when users rename fields with Arabic or other non-Latin labels. This prevents an unnecessary validation error and makes field labeling more reliable for multilingual users.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027 Forward-Port-Of: odoo/enterprise#122094 Forward-Port-Of: odoo/enterprise#121343
French VAT declarations now handle SIRET numbers even when users enter spaces, reducing failed submissions. The update also checks bank account number formatting and warns users before incorrect details cause issues.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745 Forward-Port-Of: odoo/enterprise#124448 Forward-Port-Of: odoo/enterprise#120689
Fixed an issue where emailing the Partner Ledger could fail for companies using different currencies. The email wizard now opens reliably in multi-currency setups, while single-currency setups are unchanged.
Original PR description
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard…
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard on opening with: ``` psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist ``` ### Current behavior before PR To compute the recipients, `AccountPartnerLedgerReportHandler._get_report_send_recipients` runs `_get_query_sums`, whose SQL joins the currency table. In a multi-currency setup that table is a **temporary** table that must be created beforehand by `AccountReport._init_currency_table`. Every regular rendering entry point calls `_init_currency_table` before running currency-table queries, but the report-sending path does not, so the query fails on a missing `account_currency_table` relation. ### Desired behavior after PR is merged `_init_currency_table(options)` is called before running the query, so the temporary table exists. It is a no-op in mono-currency setups (early return in `_init_currency_table`), so mono-currency behavior is unchanged. ### Steps to reproduce 1. Have several companies using different currencies. 2. Select more than one of them in the company switcher. 3. Open **Accounting > Reporting > Partner Ledger**. 4. Click **Send by email** → the wizard crashes on opening. Video: https://drive.google.com/file/d/1skpg7YDtxcY1PCtURyzk5PdFPi7ZPreG/view A regression test covering the multi-currency send-recipients path is included in `test_partner_ledger_report.py`. I've created the task #6362131 for this issue
This fix ensures Manufacturing Planning uses the product's Bill of Materials batch size even when no specific BOM is selected while adding the product. This helps planners get correct replenishment quantities and avoid under-planning production.
Original PR description
In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size. Steps to reproduce: ------------------- * Create a…
In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size. Steps to reproduce: ------------------- * Create a product with a bom that has a batch size of 2 * Open MPS * Add the product - without specifying the bom - Route Manufacture * Add 1 in the Forcast Demand -> the batch size from the bom it's not taken into account. Observation: ------------- When updating mps, it will call get_production_schedule_view_state: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L424 this function when calculating the quantity to resplenish will call _get_resplenish_qty: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L534 to know the quantity to resplenish it will need the batch size, in mps they will only consider the batch size from the bom registered: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L863-L865 Since there is no default value for bom_id, If there is no bom selected, there is no batch size. opw-6259956
Envia shipping rate requests now send insurance information in the format expected by the carrier API. This ensures quoted delivery prices reflect configured insurance coverage, avoiding underquoted rates for insured shipments.
Original PR description
Issue ----- Insurance request is not reflected on the rating given by Envia. Steps to reproduce ----- - Create a MX company - Set up Envia - Fedex Nacional Economico (ground) - Create a MX client - Create a product (with some weight) - Create a SO - Add the product - Add envia delivery and get a rate - Update Envia delivery method - Set insurance to 50% - Go back to the SO - Add envia delivery and get a rate > The rate is the same both times Cause ----- We are passing the insurance value as a `insurance` field on the shipment, which is not what the API expects. We should instead pass it in `additionalServices` as shown in the example of https://docs.envia.com/docs/additional-services#how-to-add-services-to-a-shipment Follow up of 7258e4a ----- Ticket: opw-5254952
8 changes
Resolved issues and error corrections
Non-SEPA bank journals now default to the older PAIN 003 payment file format instead of PAIN 009 when users cannot manually choose the version. This helps prevent bank rejections for international payments and improves payment processing reliability.
Original PR description
Before this PR: - The sepa version field is hidden on non-SEPA journals and defaults to the pain009. Banks often reject this version, and users cannot change it because the field is invisible. After this PR: - The logic defaults to PAIN 003 when the SEPA payment method is not present. This ensures bank compatibility for international payments where the version cannot be set manually. task-6085943
The Knowledge and Documents cards on the customer portal now use the same layout as the other portal cards. This fixes a visual inconsistency where those cards appeared slightly wider, making the portal page look more polished and consistent.
Original PR description
The knowledge and documents portal card was injected directly into "o_portal_docs", causing it to render wider than other cards. This happened because other cards sit inside "o_portal_category" (row g-2 mt-3) divs, while, knowledge was a direct child of o_portal_docs, giving it a different grid context despite both using col-md-6. To fix the issue, we wrapped the portal_docs_entry in an "o_portal_category row g-2 mt-3" div to match the structure of all other portal cards. Steps to reproduce: 1.Go to the website. 2.Click on name drop down menu on the navbar like "Mitchell Admin" 3.Click on "My Accont" from the drop down menu 4.Once the page loads properly, you can see the knowledge card width is a little bit larger than other cards. Forward-Port-Of: odoo/enterprise#119939
This fixes an error when printing Chilean delivery guides for kits whose components use different unit types than the kit product. The guide now uses the component product price when needed, preventing failed document generation for affected deliveries.
Original PR description
When a kit is delivered, each component move is linked to the kit's sale order line. Pricing the delivery guide in "sale order" mode converted the component quantity into the kit's sale UoM. For a component sold in a different UoM category than the kit, this cross-category conversion raises a UserError. Steps to reproduce: - Create a BoM for a kit product with a component in a different UoM category - Create a customer with Delivery Guide Price = "From Sale Order" - Sold the kit in a sale order and deliver it - On the delivery, print the delivery guide -> error This fix makes the guide price for a component move to be "product" if the component's product is different from the related sale line product, avoiding the cross-category UoM conversion. opw-6327895 Forward-Port-Of: odoo/enterprise#122776
Intercompany deliveries can now automatically remove package references before receipt, avoiding mismatched inventory records between companies. This helps keep intercompany stock balances clearer and reduces confusion from leftover package-based records.
Original PR description
Issue: Compare to lot and serial number package are not multi company. It means that the package don't pass from a company to the other. So when a company deliver to another. The delivery will create a quant with the package. However the receipt in the other company will create a new quant without package (or a new package). It means that the quants are never reconcile and it could become difficult to understand what remains in intercompany location and what are artifact from past movements. In order to fix it, we introduce a new system parameter to directly unpack after the delivery. This way the receipt is always without source package and will automatically decrease the quant. opw-6376983
Amazon Ground shipments created through Envia now include each product's weight in the label request. This prevents valid high-quantity shipments from being blocked by Amazon's weight validation error.
Original PR description
**Issue:** Envia API documentation is very bad. When trying to generate an Amazon Ground shipping with Envia, the API will sometimes reject the payload with the following error: `Total items weight…
**Issue:** Envia API documentation is very bad. When trying to generate an Amazon Ground shipping with Envia, the API will sometimes reject the payload with the following error: `Total items weight exceeds package weight. Please refer to API documentation for allowable limits. (D-703)` Even though the [Envia documentation](https://docs.envia.com/reference/create-shipping-label) doesn't include it, it seems that Amazon requires the weight for each product. If the payload doesn't include the per-item weight, Amazon will set a default weight, which will cause the error to show up if the delivery contains a high quantity. This can be a blocking issue for some customers. **Steps to reproduce on a fresh DB:** - Install Inventory, Sales, and Envia Shipping - Switch company to be based in India (need to provide an address to deliver from, I just used the Odoo India address - InfoCity Gate, Gandhinagar, Gujarat 382007) - Configure an Amazon delivery carrier with Envia (India seems to be the only country that supports Amazon with Envia) - Inventory > Configuration > Delivery Methods > Envia.com method - Must be in a Production environment (because Envia's sandbox server does not work for some reason?) - Add an Envia Production Access Token (will have to use one with some funds) - Change 'Ship From' to India - Configure the `Envia.com Service Name`, set Carrier and Service to AMAZON and AMAZON - Amazon Shipping Standard - Create a demo product, give it an arbitrary weight like 0.1 kg - Create a sales order to an Indian customer, include the demo product with a high quantity (like 20), confirm (might have to create a warehouse and configure the customer's information) - On the generated picking, set the Carrier to Envia.com on the Additional Info tab - When trying to Validate, it should throw the error **Fix:** When generating the payload in _get_shipping_lines() in envia_request, include the item weight in the dictionary. Related ticket: opw-6261682
The bank reconciliation report now correctly includes all unreconciled transactions up to the selected date, not just those from the latest statement. This helps accounting teams get a complete view of outstanding bank items and avoid missing older transactions during reconciliation.
Original PR description
The reconciliation report lists only the unreconciled transactions from the last statement instead of all of them Steps: - Create 4 statements with one statement line each with different dates - Go to the reconciliation report (via the three dot menu on bank journal kanban card) - select date as Today -> only the line from the last statement is displayed opw-6250370 Forward-Port-Of: odoo/enterprise#119386
Rental orders using custom make-to-order purchase routes now correctly create the expected return transfer. This prevents missing return operations when businesses rent products that must first be purchased from a vendor.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental order for 1 x P and set the the MTO route on the sol - Confirm the order #### > The delivery as well as the purchase for 1 unit of P was generated but the return was not. ### Cause of the issue: The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297 However, in the present case, the mto route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated. opw-6361322
Uruguayan electronic export invoices that are fully offset by discounts can now be generated with the required discount details. This helps exporters issue valid zero-total export invoices for customs or trade requirements without validation errors.
Original PR description
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not…
## Problem When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not handled correctly by the XML/CFE generation logic. This use case is valid and required by exporters who need to reflect the declared value of goods/services while invoicing at zero (e.g. to comply with customs or incoterm requirements such as FCA). In Uruware's validation portal, the "Descuentos y Recargos" (discounts & surcharges) section of the subtotal block must be correctly populated for the CFE to be accepted. **Example:** An invoice with a line of 648.00 UYU and a global discount of −648.00 UYU → Total: 0.00. The export value is still declared, taxes are zero, but the CFE must reflect the discount amount explicitly. <img width="592" height="679" alt="example_expo_invoice_discount" src="https://github.com/user-attachments/assets/aa83c158-e342-4da5-a251-fc209bbed5c4" /> ## Root Cause The CFE template (`cfe_template.xml`) and the move computation logic (`account_move.py`) did not account for the case where export invoices carry line-level or global discounts that zero out the total. The discount amount was either omitted from the XML nodes or computed incorrectly, causing Uruware validation to fail or the discount block to not render. ## Fix - **`l10n_uy_edi/models/account_move.py`** — Updated the export invoice computation to correctly include discount amounts in the CFE data dict, ensuring the `ValorDR` is filled with the value of the discount per line. - **`l10n_uy_edi/views/cfe_template.xml`** — Adjusted the template condition so `MntExpoyAsim` node accepts 0 as value. ## Steps to Reproduce (before fix) 1. Create an export invoice (e-Factura Exportación) for a foreign partner. 2. Add a product line with a unit price, e.g. 216.00 × 3 = 648.00 UYU. 3. Add a global discount of 648.00 (same amount) so the total is 0.00. 4. Confirm and send to Uruware — the CFE is rejected / discount block is missing. ## Verification After the fix, the same invoice generates a valid CFE accepted by Uruware with the discount correctly reflected in the `DscRcgGlobal` node and the discount line visible on the printed document.
2 changes
Resolved issues and error corrections
This fix prevents payment document creation from failing when accounting views pass an unrelated document type value. If the incoming type is not valid for Documents, the system now uses the standard default so EDI payment updates can proceed normally.
Original PR description
In certain scenarios, a default_type context can be passed during document creation, and this value may not exist in the type selection field, as it may come from a type in another model. Steps to…
In certain scenarios, a default_type context can be passed during document creation, and this value may not exist in the type selection field, as it may come from a type in another model. Steps to reproduce using MX EDI update payment: - Setup a Mexican company with MX EDI - Install the documents_account module and create a folder for journals where you will place customer payments (ex: journal PAY/) - In accounting views, group journals by type, which will adds default_type = <journal type> when opening entries from this view - From this view, open the Customer Invoices journal, create and post an invoice - Register a payment, and then click on Update Payment button, which will triggers an EDI document creation with default_type="sale" in the context, causing the error 'ValueError: Wrong value for documents.document.type: "sale"' This fix falls back to the default document type if the type in the context is not in the selection, preventing the error and allowing the document to be created correctly. opw-5742850 opw-6182877
Refreshing an accounting report now clears the previous search from the session, so downloaded Excel files reflect the partners currently shown on screen. This avoids confusing mismatches where the page shows all partners but the export still contains only an earlier search result.
Original PR description
**Steps to reproduce:** - Install account_reports - Open "Partner Ledger" (make sure there are several partners) - Make a search to only display 1 partner - Download XLSX - Without changing the search text, refresh the page - Download XLSX again **Issue:** After refresh, the search text is empty and all the partners are displayed in the report. However, in the XLSX file, only the partner from the previous search is present. **Cause:** The current search is kept in the session and used when getting the XLSX. When refreshing or leaving the page, it's still kept in the session even if the search bar has been reset. opw-6333212