Daily updates from Odoo
Navigate
Branch
Friday, July 17, 2026
354 changes
18 changes
New functionality added to Odoo
A new German reporting module lets businesses submit tax returns directly from Odoo to Elster, Germany's official online tax portal. This reduces manual export and upload steps, helping finance teams handle compliance submissions more efficiently.
Original PR description
This module enables users to submit their tax returns to Elster directly from Odoo. see IAP: https://github.com/odoo/iap-apps/pull/1513 task-5193637 Forward-Port-Of: odoo/enterprise#121805
Enhancements to existing features
Peruvian e-invoicing now includes the product classification codes required by SUNAT's upcoming validation rules. This helps businesses avoid rejected e-invoices for affected goods when the new requirements take effect.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
The journal creation wizard in Accounting now supports navigation with keyboard arrow keys. This makes the setup flow easier and faster to use, especially for users who prefer keyboard-based navigation or need improved accessibility.
Original PR description
This commit aims to allow for navigation through the journal create wizard via keybaord arrows. Related Odoofin PR: https://github.com/odoo/odoofin/pull/502 task-5796200 Forward-Port-Of: odoo/enterprise#105541
Bank reconciliation now highlights draft statement lines in blue, making them quicker to identify during review. This helps users distinguish unfinished items at a glance and reduces the chance of overlooking draft entries.
Original PR description
This commit will put the text in blue when the statement line is in draft to be able to see quickly which lines are in draft. task-6327308 Forward-Port-Of: odoo/enterprise#124418 Forward-Port-Of: odoo/enterprise#121775
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
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#124221
Original PR description
Forward-Port-Of: odoo/enterprise#124221
19 changes
Security fixes and vulnerability patches
Employee payroll fields for several country-specific payroll modules are now only visible to authorized payroll users. This helps prevent non-payroll staff from accessing sensitive payroll information and keeps permissions consistent across employee records.
Original PR description
This commit adds `groups="hr_payroll.group_hr_payroll_user"` to all fields displayed inside payroll tab in the form view of employee to make sure those fields are only accessible to payroll users. runbot-error-234071 Forward-Port-Of: odoo/enterprise#123420 Forward-Port-Of: odoo/enterprise#122293
New functionality added to Odoo
German accounting users can now send tax returns to Elster directly from Odoo, reducing manual export and submission steps. This adds a dedicated Elster integration module and related checks to support a smoother compliance workflow.
Original PR description
This module enables users to submit their tax returns to Elster directly from Odoo. see IAP: https://github.com/odoo/iap-apps/pull/1513 task-5193637 Forward-Port-Of: odoo/enterprise#121805
Enhancements to existing features
Updates the product code catalog so Peruvian e-invoices can include the required SUNAT product classifications for new 2026 validation rules. This helps avoid invoice rejections for affected goods while keeping Peru-specific codes limited to companies using the Peru localization.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
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
Code cleanup and technical improvements
This change removes duplicate internal logic for handling flexible leave intervals in Planning Holidays. The shared Holidays Gantt component already provides the same behavior, so this reduces maintenance risk without changing the user experience.
Original PR description
After commit e0b126c, `_handle_flexible_leave_interval` is already implemented in `hr_holidays_gantt` and covers the same case previously handled in `planning_holidays`. https://github.com/odoo/enterprise/blob/7ed917c1de11e29257a726efd4dafe403b9efba1/hr_holidays_gantt/models/resource_calendar.py#L17-L20 Since `planning_holidays` depends on `hr_holidays_gantt`, the duplicate implementation in `planning_holidays` is no longer necessary. **opw-6243778** Forward-Port-Of: odoo/enterprise#124477 Forward-Port-Of: odoo/enterprise#119229
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#124221
Original PR description
Forward-Port-Of: odoo/enterprise#124221
26 changes
Security fixes and vulnerability patches
Employee payroll fields in several country payroll modules are now limited to authorized payroll users. This helps prevent non-payroll staff from viewing sensitive payroll-related employee information.
Original PR description
This commit adds `groups="hr_payroll.group_hr_payroll_user"` to all fields displayed inside payroll tab in the form view of employee to make sure those fields are only accessible to payroll users. runbot-error-234071 Forward-Port-Of: odoo/enterprise#123420 Forward-Port-Of: odoo/enterprise#122293
New functionality added to Odoo
German companies can now submit tax returns directly to Elster from Odoo, reducing manual steps outside the system. This adds a dedicated Elster integration for German tax reporting and supports a more streamlined compliance workflow.
Original PR description
This module enables users to submit their tax returns to Elster directly from Odoo. see IAP: https://github.com/odoo/iap-apps/pull/1513 task-5193637 Forward-Port-Of: odoo/enterprise#121805
Enhancements to existing features
The journal creation wizard can now be navigated using keyboard arrow keys. This makes setup faster and more accessible for users who prefer or rely on keyboard navigation.
Original PR description
This commit aims to allow for navigation through the journal create wizard via keybaord arrows. Related Odoofin PR: https://github.com/odoo/odoofin/pull/502 task-5796200 Forward-Port-Of: odoo/enterprise#105541
This update ensures required product classification codes are available for Peruvian electronic invoices ahead of SUNAT's 2026 validation changes. It helps prevent invoice rejections for affected goods while limiting Peru-specific code activations to companies using the Peruvian localization.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
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
Code cleanup and technical improvements
This update removes duplicated internal logic for handling flexible employee leave in planning, because the same behavior is already provided by a related holidays module. It reduces maintenance risk without changing the expected user experience.
Original PR description
After commit https://github.com/odoo/enterprise/commit/e0b126cb1ec80743ef06784e230320a1c50041e9, `_handle_flexible_leave_interval` is already implemented in `hr_holidays_gantt` and covers the same case previously handled in `planning_holidays`. https://github.com/odoo/enterprise/blob/7ed917c1de11e29257a726efd4dafe403b9efba1/hr_holidays_gantt/models/resource_calendar.py#L17-L20 Since `planning_holidays` depends on `hr_holidays_gantt`, the duplicate implementation in `planning_holidays` is no longer necessary. **opw-6243778** Forward-Port-Of: odoo/enterprise#124322 Forward-Port-Of: odoo/enterprise#119229
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#124221
Original PR description
Forward-Port-Of: odoo/enterprise#124221
11 changes
New functionality added to Odoo
A new German localization feature lets businesses submit tax returns directly to Elster from within Odoo. This reduces manual export and submission steps, helping German companies streamline compliance workflows.
Original PR description
This module enables users to submit their tax returns to Elster directly from Odoo. see IAP: https://github.com/odoo/iap-apps/pull/1513 task-5193637 Forward-Port-Of: odoo/enterprise#121805
Enhancements to existing features
Peruvian e-invoicing now includes the additional product classification codes required by SUNAT's upcoming validation rules. This helps businesses avoid invoice rejections for affected goods once the new requirements take effect.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
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
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#124221
Original PR description
Forward-Port-Of: odoo/enterprise#124221
7 changes
Enhancements to existing features
Peruvian e-invoicing now includes the product classification codes required by SUNAT's upcoming 2026 validation rules. This helps businesses avoid rejected electronic invoices for affected goods once the new rules take effect.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
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
9 changes
Enhancements to existing features
Online payment initiation now includes the payer's bank account details and account holder name when required by providers such as Powens. This helps more bank payments start successfully by giving providers the information some banks need upfront.
Original PR description
With Powens, some banks requires the payer's bank information such as bank account number and bank holder name. This commit adds those informations to the odoofin route to be sent to the payment providers. task-6373634
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