Daily updates from Odoo
Tuesday, October 21, 2025
14 changes · master
Enhancements to existing features
Updates Luxembourg payroll settings to reflect the 2025 minimum social salary and related employee tax credits. This helps businesses calculate payroll in line with the latest official Luxembourg social security and tax parameters.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf task-5176255 Forward-Port-Of: odoo/enterprise#97468
This update refines how manufacturing planning calculates monthly demand by using exact date ranges, improving accuracy for purchasing and production suggestions. It also streamlines field service product catalog navigation and internal data handling, making the back button behavior clearer and the catalog code easier to maintain.
Company-wide return deadline settings have been removed because deadlines can now be managed directly on each return type. This gives customers more precise control over filing timelines across accounting reports and country-specific returns.
Original PR description
The field deadline on the company is now removed as customers have now a way to override the deadline on the return type directly. task-5153900
Odoo Studio now lets users drag existing selection or stage-like fields onto a form status bar instead of creating only a new selection field. This makes stage setup more flexible and allows better ordering in grouped views, especially when using related stage records.
Original PR description
Before this commit, to add a StatusBar (stages) in a form view, one had to click on the form's editor hook. After some configuration it added a Selection field with some selection values setup by the user. The problem with selection values is that there are ordered lexicographically on the value in the column, that is the technical value of the selection value's tuple. Hence, in a grouped kanban (or list -- via a web_read_group) the groups could not have another order. After this commit, the StatusBar hook behaves as a droppable hook and one can drag and drop a selection field or a many2one, allowing for their respective configuration. If a many2one serves as the field underlying the statusbar, a button allows the user to add records, i.e. stages. task-4744988
This update adds country-specific EC Sales List and Intrastat reporting rules for Austria, Germany, the Netherlands, Italy, Poland, and Portugal. Businesses in these countries can better track required filing deadlines and periodicities directly in Odoo, supporting more accurate tax and trade compliance.
Original PR description
Following the implementation of the Tax returns feature in 18.3 which was focused on the general implementation and Belgium, we want to add the specification for other country and in this case Austria, Germany, The Netherlands, Italy, Poland, and Portugal. Adding EC sales list, Intrastat specific deadlines and periodicities. task-4776236
Studio now stores pipeline stages in a way that preserves their intended order, so kanban columns appear consistently and empty stages remain visible. This improves pipeline setup and editing, including statusbar display and option handling in the form editor.
Original PR description
**Before this PR:** In studio, the pipeline statusbar was modeled as a field selection which prevented the order of the stages to be used to order kanban columns correctly. **After this PR:** The pipeline statusbar is now modeled as a Many2one field pointing to a new model created when adding the statusbar to the form view. This allows the kanban view to be ordered correctly. The edition of the statusbar also works when the model is created with the pipeline option checked. Moreover, when a kanban column is empty, it is still displayed which prevent the user to be prompted for the creation of new stages. **This PR also introduces 2 fixes:** - All statusbar options are parsed when using the add operation. - The statusbar widget is now rendered correctly in the form editor. task-4744988
Argentina IVA Simple tax report exports are now handled directly in the main Argentine reporting module instead of a separate add-on. This simplifies module management while keeping the report export and related tests available for users who need Argentine VAT reporting.
Original PR description
In fe77a6b we merged a new module in stable to be able to support the export of IVA Simple Tax Reports for Argentina. This is no longer necessary in master, as such, the model data for activities have been merged into `l10n_ar` in community, and all of the tests and report exports have been moved to `l10n_ar_reports` in enterprise. task-5027104
The SEPA Direct Debit mandate form has been simplified to show only the most relevant information to everyday users. Date handling, bank account guidance, and scheme explanations are clearer, helping staff complete mandates with less confusion.
Original PR description
- Show identifier only in debug mode. - Use Date Range for start and end date with 'Indefinite' as placeholder. - Placeholder for partner bank 'Provided by customer'. - Make SDD scheme optoins clearer and adding useful help. task-5159986
Uruguayan electronic invoices can now correctly identify and report VAT rates outside the standard exempt, minimum, and basic categories. This improves compliance by adding the required reduced-rate totals and line indicators in the XML, plus a dedicated tax grid for reporting.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
Forward-Port-Of: odoo/enterprise#97640
Forward-Port-Of: odoo/enterprise#91392Resolved issues and error corrections
Ecuadorian XML vendor bill imports now read discount amounts and apply the matching discount percentage in Odoo. This prevents imported bills from overstating line amounts when supplier XML files include discounts.
Original PR description
In the l10n_ec_edi localization, XML files that include a <descuento> (discount) tag do not apply the discount when imported into Odoo. - Create an invoice with a discount and export the XML. - Re-import the XML as a vendor bill — the discount is missing. This commit fixes the issue by computing and importing the discount percentage from the <descuento> tag. opw-5137439 Forward-Port-Of: odoo/enterprise#96712
Refreshing appointment availability for a selected staff member no longer triggers an error when checking capacity. This helps customers and staff continue booking appointments smoothly without interruption.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#97634 Forward-Port-Of: odoo/enterprise#95862
This fix prevents automated receipt scanning from replacing an expense name that a user has already edited after upload. It also makes the OCR status banner appear immediately after adding an attachment, so users get clearer feedback without refreshing the page.
Original PR description
This commit https://github.com/odoo/odoo/commit/ca1f644a3c15f17482f56a2ece2a57f0f03098ff introduced the "untitled expense" title for expense when being uploaded. The user can then change manually the name. However, if the OCR is called after, it overrides the name previously set by the user. Therefore, if the name of an expense starts with "Untitled Expense", the OCR should not override the name. In addition, when uploading an expense on the form view, the OCR banner used to be not visible until the page was refreshed. This banner is now displayed directly after uploading the attachment. task-4684825
The Planning / Timesheet Analysis report now calculates planned and remaining hours using each employee's actual working schedule instead of assuming a standard Monday-to-Friday week. This makes reporting accurate for part-time employees or staff with non-standard days, helping managers rely on the report for capacity and workload decisions.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066 Forward-Port-Of: odoo/enterprise#95115
Fixes an issue where a bank payment that only covered part of an invoice could incorrectly mark the full invoice as paid. Payments are now applied only up to the transaction amount, preventing incorrect suspense balances and improving accounting accuracy.
Original PR description
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90…
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90 -------- Option 1 -------- - Reconcile the statement line with the three invoice lines from the reconcile button on the stmt line itself -------- Option 2 -------- - From the invoice, add the stmt line from the outstanding payments widget -> The invoice is marked as fully paid and the bank entry looks like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.68 | | Suspense account | 110.00 | 0.00 | It should look like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 23.34 | This is because we're calculating the partial amount only when looping over the last move line, which result with no partial amount since the transaction amount is already exceeded, therefore we end up adding all the line and balancing it with the suspense account line, which is wrong. With this commit, we add some conditions to check wether the amount is exceeded or will be exceeded, and we calculate the partial amount accordingly. opw-5076498 Forward-Port-Of: odoo/enterprise#97632 Forward-Port-Of: odoo/enterprise#96847