Daily updates from Odoo
Monday, September 1, 2025
18 changes · master
New functionality added to Odoo
This change adds Slovenian Intrastat support so businesses can use the correct local reporting periods and submission deadlines. It helps companies operating in Slovenia stay aligned with local statistical reporting requirements in Odoo.
Original PR description
[ADD] l10n_si_intrastat: Slovenian Intrastat Tax returns feature was introduced in 18.3, this module implements the specific Slovenian periodicities and deadlines for Intrastat. task-4987884
Enhancements to existing features
The knowledge editor's revision history dialog has been improved and its automated checks were updated. This helps ensure users have a more reliable experience when reviewing prior content changes.
Original PR description
* adapt and improve tests task-3560677
Managers can now use the appraisal campaign wizard to start appraisals for the employees they manage. This improves HR workflow by allowing managers to initiate reviews directly while keeping access limited to their own teams.
Original PR description
-Previously, managers could not access the appraisal campaign wizard to launch appraisals for their employees. -Wizard access is now available to all users, limited to the employees they actually manage. -Views were updated so all users can see the "Launch Campaign" button, but only managers can create campaigns for their subordinates.
Auto-planning now treats flexible workers according to their daily and weekly capacity instead of forcing them into a standard 8-to-5 schedule. This helps teams plan shifts and project tasks more accurately, including shared tasks and round-the-clock operations, while avoiding overbooking.
Original PR description
[IMP] planning,project: auto plan for flexible resources Before this commit: - auto plan, for planning and project, considers flex resources as regular resources working with a regular calendar from…
[IMP] planning,project: auto plan for flexible resources Before this commit: - auto plan, for planning and project, considers flex resources as regular resources working with a regular calendar from 8 to 17. for fully flexible resources, they are considered working the full range, without checking leaves, and the overload on the day itself, there is no daily limit in the calendar, but the day is limited to 24 hours. - when a task is assigned to many users, it's planned with its real allocated hours, but the real time to allocated is allocated_hours divided by the number of users. After this commit: - flex resources should not follow a regular calendar as flex calendars doesn't have attendances, they can work at any moment of the day without exceeding a number of hours per day and a number of hours per week (configured in the flex calendar). The auto plan plans shifts/tasks without exceeding daily/week rate and without following a regular calendar, a flex employee is considered working from 00:00 to 23:59 to cover more use-cases, such as restaurants, hospitals, firefighters. Same for fully flexible employees, the auto plan makes sure no overload on a range of time, example: it's not possible to do a shift/task of 4 hours between 8 and 10 (only 2 working hours available) - hours to plan for tasks = allocated_hours / number of users task-4822880
Spreadsheet pivot views can now group data using a chain of related fields, such as grouping leads by a customer's country. This makes spreadsheet reporting more precise and helps users analyze business data through richer categories without leaving the pivot configuration flow.
Original PR description
This commit adds support for grouping by a sequence of fields in the spreadsheet pivot view. It allows users to define a sequence of fields to group by, for example, grouping the Leads by the country of the customer (partner_id.country_id). Task: 4883357
After closing a VAT or tax return period, users can now email payment instructions, including payment details and a QR code, to selected colleagues. This helps route payment information to the right people and marks the return as paid once the instruction email is sent.
Original PR description
Before this commit - users who close the VAT period isn't necessarily the one who pay, they need to be able to send the VAT instructions on how to file the return. After this commit - user after closing the tax period from VAT return payment wizard can send email to selected users with vat payment details and qr code to ease tax return payment process - return state will be marked as paid once the mail is send task-4852346
VoIP now includes data for providers that have been successfully tested, making them easier for users to find and set up. This reduces configuration effort and helps businesses get VoIP services running more reliably.
Original PR description
This commit makes working providers more discoverable for users and ease the providers' configurations by adding those providers' data in VoIP be default. Task-4987919
Point of Sale scales now use a shared connection service that can switch between multiple communication methods if one fails. This improves reliability for weighing products and supports smoother operation across IoT setups.
Original PR description
We now use the iot http service to manage scales. This allows using both webrtc, longpolling or websocket when one protocol or the other is failing. This commit also refactors the IotHttpService to bring a new global `onMessage` method that handles only listenting for events with fallbacks. (e.g. waiting for an event with webrtc fails? Fallback using longpolling). Community PR: odoo/odoo#223795 Task: 5031975
New salary offers are now always connected to the relevant employee or applicant and limited to people in the current company. This helps prevent offers from being created with mismatched company or person details, improving data accuracy in the salary offer process.
Original PR description
When creating a new offer: - it is always linked to either an employee or an applicant, depending on the application used, - the employee/applicant domain is restricted to the current company, - the 'company_id' is automatically set to the active company based on the chosen employee/applicant. task-4981877
Manual advance invoicing for post-paid subscriptions now bills the complete billing period instead of stopping at the current date. This gives businesses more predictable subscription invoices while still accounting for products that may be delivered during the period.
Original PR description
Currently when users are manually invoicing a post-paid subscription in advance (before the next invoice date), the invoice is generated for the past period until today --> Only a partial period. This has been done to avoid users to invoice a future period during which some other products may be delivered.
taskid-4929802The GSTR document summary for GSTR-1 Table 13 is now part of the main Indian reports module instead of a separate add-on. This simplifies setup and maintenance while keeping the required compliance reporting available without extra dependencies.
Original PR description
Before: - A separate module `l10n_in_reports_gstr_document_summary` was introduced across all stable versions up to saas-18.4 to provide GSTR1 Table 13 reporting After: - From saas-18.5 onwards, the GSTR document summary functionality is merged directly into l10n_in_reports. Impact: - Consolidates functionality into a single module for easier maintenance. - Ensures GSTR-1 Table 13 compliance continues without additional dependencies. Related Upgrade PR https://github.com/odoo/upgrade/pull/8269 Original Module PR https://github.com/odoo/enterprise/pull/85473
Resolved issues and error corrections
Fixes an issue where Mexican sales orders could show zero invoiced quantity after an invoice cancellation was completed through CFDI. The sales order now updates its invoiced quantities when the CFDI status changes, helping keep order and billing records accurate.
Original PR description
How to reproduce the issue: In l10n_mx: 1. Create a sale order. 2. Create an invoice from the SO, with yesterday’s date, and send it to the CFDI. 3. Lock the period at yesterday’s date. 4. Request the invoice cancellation with the “01” method. This creates a new invoice — confirm it. 5. Create a credit note for the original invoice. 6. Retry sending the cancel request to the CFDI; the CFDI state is now cancelled for the original invoice. On the original SO, the quantity invoiced is 0 despite the CFDI state of the original invoice being cancelled. This commit forces a recompute of the quantity invoiced when the CFDI state changes. Since _compute_qty_invoiced uses _get_invoice_lines, which filters out invoices in sent state, only lines from invoices in cancelled state will be taken into account. opw-4910139 Forward-Port-Of: odoo/enterprise#93480 Forward-Port-Of: odoo/enterprise#91924
Replacing work entries in the Gantt view now correctly creates a new entry using the selected type and the appropriate duration. This helps HR users avoid incorrect work entry totals when updating employee schedules, including empty days where expected working hours are used.
Original PR description
task-5043872
This fixes Italian POS receipts so change given back to customers is not sent to fiscal printers as a negative payment. This helps ensure orders are accepted by fiscal printers and properly reported to the authorities.
Original PR description
Before this commit, specifying the payment method used to give back the change in a POS order would lead to the fiscal printer receiving a negative payment as input, which is not supported, thus leading to the order not being treated by the fiscal printer (so not reported to the government). Only the payments with is_change=true where filtered out. I am now adding a filter to only keep the positive payments in the receipt, as the fiscal printer is computing the change itself. opw-4931671 Forward-Port-Of: odoo/enterprise#91794
Fixes an issue that could block users from deleting a generated bank statement line when the related journal entry used multiple reconciliation rules. This helps accounting users correct bank reconciliations without encountering an unexpected error.
Original PR description
Currently, an error occurs when trying to remove a move line from a bank statement line if the journal entry contains lines with different reconciliation models. **Steps to Reproduce:** 1. Install…
Currently, an error occurs when trying to remove a move line from a bank statement line if the journal entry contains lines with different reconciliation models. **Steps to Reproduce:** 1. Install the Accounting module. 2. Duplicate the "Internal Transfer" reconciliation model. 3. Accounting dashboard > click on Bank > create new record. 4. Add the invoice, apply "Internal Transfer" reconciliation model. 5. Edit the balance of the line to lower, apply duplicated model(Internal Transfers (copy)). 6. Try deleting the generated Liquidity Transfer line. (Refer [this video](https://drive.google.com/file/d/1cz80Q5325x3rqYUlGahVzFIXH2iqrbRF/view?usp=drive_link) for steps to reproduce.) **Error:** ValueError - Expected singleton: account.reconcile.model(8, 6) **Cause:** In the method `delete_reconciled_line` at [1], the `reco_model_id` is fetched from `self.move_id.line_ids.reconcile_model_id`. If the move contains lines linked to multiple reconcile models, this causes a singleton error during subsequent processing. **Fix:** This commit uses the already computed `move_lines_to_remove` to retrieve `reconcile_model_id` instead of accessing it from `self.move_id.line_ids`, which may result in a multi-recordset. [1] - https://github.com/odoo/enterprise/blob/89aa58029a79928788277489414f8192aa5353e4/account_accountant/models/account_bank_statement.py#L1041-L1049 sentry-6781788260 Forward-Port-Of: odoo/enterprise#91619
Kenyan e-invoicing checks now ignore cancelled or draft credit notes when validating quantities and amounts against the original invoice. This prevents incorrect blocking errors when businesses create replacement credit notes after cancelling earlier ones.
Original PR description
[FIX] l10_ke_edi_edi_oscu: ensure quantity and monetary values checks are performed on reconciled reversals only. Fixes a behavior where the checks performed on the credit notes related to their quantities and monetary values include non reconciled credit notes. Steps to reproduce: 1 - activate `l10n_ke` on some company. 2 - Create an invoice. 3 - Create a partial or full credit note ( this one will be reconciled with the invoice automatically ) 4 - cancel the credit note or reset it to draft. 5 - create another credit note where the quantities and/or monetary values exceed that of the invoice if summed up with the cancelled credit note. Following the steps will result in an error message saying that the monetary value or quantities on the credit notes exceed that of the invoice. The correct behavior is to simply not count any credit note that isn't explicitly reconciled with the invoice. opw-4779976 Forward-Port-Of: odoo/enterprise#92319
Default values for tax return types are now applied when companies and return types are created, rather than only during initial chart setup. This prevents missing or incorrect defaults when country-specific reporting modules are installed later, improving consistency for accounting compliance setups.
Original PR description
Before the company dependent default values for the return types were set only during the ```_post_load_data``` of the chart template. The issue with this way is that when we install a l10n for instance 10n_be_reports which add new return types, l10n_be would create a new company then trigger the _post_load_data function on return types that existed at that time. The only problem is that return types from l10n_be_reports are still not installed. The change here is that we set the default value on the creation of the company and return type.
Fixed an issue where returning a rental order linked to a Point of Sale picking could incorrectly increase the delivered quantity. This helps keep rental order records accurate after PoS settlement and return workflows.
Original PR description
**Issue:** Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS **Cause:** The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty`…
**Issue:** Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS **Cause:** The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty` to the related `sale_line` each time it runs When there is no PoS order, the method add 0 to the line, so the expected behavior work But when you have a PoS Picking, a quantity was added to `qty_delivered` each time the `rental.order.wizard` is used The issue also occured earlier when the `flush_all()` is called in `_process_order()` **Fix:** There is already a `_compute_qty_delivered` method in `pos_sale_stock_renting` that override the `qty_delivered` But it's restricted by `_are_rental_pickings_enabled()` That's not necessary because we don't use any `stock.picking` in the `_compute_qty_delivered` function, only `stock.move` so we removed that verification To make the code working, we also need to extend the _get_outgoing_incoming_moves() results Because there were also block by a `_are_rental_pickings_enabled()` condition even if there is only moves here We need all the moves to calculate `qty_delivered` properly **Steps to reproduce:** - Create a New Product "Rental PoS" that Can be Rented - Create and confirm a New Rental Order, with any customer and your product - Open a PoS Session - Click on Quotation/Order - Choose the last Order and Settle the order - Click on Yes (to confirm import to PoS) - Click on Payment, select Cash and Pay - Go in the Backend, and to your RO - Click Return and Validate - Before the fix, the Delivered should be 2.0 opw-4877019 Forward-Port-Of: odoo/enterprise#93406 Forward-Port-Of: odoo/enterprise#90510