Daily updates from Odoo
Friday, March 13, 2026
10 changes · master
Resolved issues and error corrections
This update resolves a security vulnerability by preventing the use of public partner information within the Enterprise POS module. This change ensures data privacy and strengthens the overall security posture of the Odoo Enterprise platform. It corrects a potential risk related to data exposure.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/251472
This update ensures accurate subline totals in stock barcode transactions. The system now requires the 'stock.group_production_lot' setting to be active, which was introduced in the 18.3 release. Without this setting, the test fails to calculate the correct totals.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109 Forward-Port-Of: odoo/enterprise#108908
This update ensures that the filing status for employees is always selected during payroll configuration. Previously, missing this information would prevent users from generating payslips. This change ensures accurate payroll calculations and avoids disruptions to the payroll process.
Original PR description
Before this PR, if an employee’s filing status is not selected in the configuration, users get an error and cannot compute payroll using the US salary structure. In this PR, we make the l10n_us_filing_status field required. This prevents users from being blocked when generating a payslip. task-5957074
This update resolves a warning in the payroll dashboard that appeared when employees were linked to partners without a defined DMFA work location. The change adds a field to the partner record to directly link it to the appropriate DMFA location, providing clearer reporting and a more user-friendly experience for payroll management.
Original PR description
Previously, DMFA work locations were defined in their own model and linked to a partner. The link didn't exist in the other direction (from partner to DMFA work location). Therefore, when an active employee had a partner not relate to any work location, we were getting a warnign in the payroll dashboard that was showing the list of partners with missing location. However, it was not possible from the partner to define the location, which was confusing and not helpful. With this commit we add the new field on res_partner and modify the views to show it. Task: 5940867
This update resolves an issue preventing users from completing rental orders. The removal of a temporary flag and the addition of a synchronization step now ensures the order confirmation only occurs when required data is valid. This improves the reliability and user experience of the rental order process.
Original PR description
This commit marks the 'rental_tour' as stable by removing the 'undeterministicTour_doNotCopy' flag. A synchronization step has been added to wait for the input field to have a valid value before confirming the order.
This update corrects a previous calculation error related to how extra legal holidays impact salary and benefit costs. The new formula now accurately reflects that taking extra days off doesn't increase benefit costs, leading to more precise wage calculations, particularly for meal vouchers. This ensures accurate payroll processing for employees in Belgium.
Original PR description
Specifications ============== Before this PR, taking extra legal paid holidays on your salary package was making the benefit taken cost more then if you didn't take any extra legal holidays. At fixed…
Specifications
==============
Before this PR, taking extra legal paid holidays on your salary package was
making the benefit taken cost more then if you didn't take any extra legal
holidays.
At fixed wage, the yearly cost was then higher than it should be.
At fixed yearly cost, the wage was then lower than it should be.
Indeed, for example, the average Meal vouchers monthly cost should only be
multiplied by the number of month in the year the get the yearly cost of meal
voucher. Before, they were also weighted by the number of extra legal days,
but taking more extra legal holidays will not cost more meal voucher to
the employer. In fact, in that precise example, the employee will not even
receive meal vouchers when an extra legal day off will be taken.
In that precise example, it will even cost less to the employer.
But anyway, benefits should not be weighted in function of the number of
the extra legal paid holidays the employee will take as benefit cost are in
reality not impacted by those extra legal days.
After this PR, only the wage is impacted by the extra legal paid holidays.
See below development for more numbered details.
Old Formula
===========
Yearly Cost
----------------
YC = (Benefits + (Cost_Factor * Wage) + Sacrifice_Fixed) / Sacrifice_Ratio
Detailed Example given for Belgian payroll
Yearly_cost = (
(sum_of_monthly_benefits_costs * 12)
+ sum_of_yearly_benefits_costs
+ ((13.92 + (13.0 * EMPLOYER_ONSS)) * Gross_Salary)
+ insurance_group_cost
) / (1.0 - (Extra_Legal_holidays_number / 231.0))
For: wage = 5000€, Benefits = 150€ Rep fee + 500€ car, Extra Legal = 15:
-> Yearly Cost = 101641.07
Wage
--------
Wage = ((YC * Sacrifice_Ratio) - Sacrifice_Fixed - Benefits) / Costs_factor
Detailed Example given for Belgian payroll
Wage = (
(
Yearly_cost
* (1.0 - (Extra_Legal_holidays_number / 231.0))
)
- insurance_group_cost
- (sum_of_monthly_benefits_costs * 12)
- sum_of_yearly_benefits_costs
) / (13.92 + (13.0 * EMPLOYER_ONSS))
For: Yearly Cost = 100k€, Benefits = 150€ Rep fee + 500€ car, Extra Legal = 15:
-> Wage = 4912.05
New Formula
===========
Yearly Cost
----------------
YC = Benefits + (Cost_Factor * Wage / Sacrifice_Ratio) + Sacrifice_Fixed
Detailed Example given for Belgian payroll
Yearly_cost = (sum_of_monthly_benefits_costs * 12)
+ sum_of_yearly_benefits_costs
+ (
(13.92 + (13.0 * EMPLOYER_ONSS))
* Gross_Salary
/ (1.0 - (Extra_Legal_holidays_number / 231.0))
)
+ insurance_group_cost
For: wage = 5000€, Benefits = 150€ Rep fee + 500€ car, Extra Legal = 15:
-> Yearly Cost = 101099.40€ (541.67 less than with old formula)
Wage
--------
Wage = (YC - Sacrifice_Fixed - Benefits) * Sacrifice_Ratio / Costs_factor
Detailed Example given for Belgian payroll
Wage =
(
Yearly_cost
- insurance_group_cost
- (sum_of_monthly_benefits_costs * 12)
- sum_of_yearly_benefits_costs
)
* (1.0 - (Extra_Legal_holidays_number / 231.0))
/ (13.92 + (13.0 * EMPLOYER_ONSS))
For: Yearly Cost = 100k€, Benefits = 150€ Rep fee + 500€ car, Extra Legal = 15:
-> Wage = 4941.08€ (29.03 more than with old formula)
Also, this PR applies a correction for the meal vouchers cost computation.
The more extra legal days off are taken, the less the meal voucher number
received by the employee there will be, and the less it will cost in average
per month.
Task-5896493This update corrects a budgeting issue impacting cultural and training industries where VAT isn't deductible. It ensures budgets accurately reflect VAT contributions, preventing misleading figures before bill recording. This improves budget forecasting and reporting for these specific business sectors.
Original PR description
In the cultural industry and/or training (formations) industry namely but not only, users often do not have right to deduct VAT. Though, they receive bills issued by their customer, where VAT is…
In the cultural industry and/or training (formations) industry namely but not only, users often do not have right to deduct VAT. Though, they receive bills issued by their customer, where VAT is explicitly set. Our users want to fetch the bills (import, Peppol, whatever) and post them quickly. Hence why even though they don't deduct VAT, they manipulate taxes. By doing so, they adapt their taxes: adapting the tax grids removing the account on the tax repartition line (or setting a distinct P&L account) >> this is how you can deduct if a tax is deductible or not The issue is that in budgets, before the bill is recorded, the committed account forgets to compute the non-deductible tax contribution. And the user is temporarily mislead because if the amounts have already been committed, the budget suggests that they have not yet been committed. Only when the bill is registered, then the committed amount is adapted to the bills. Adapt the computations of the budget so that the committed amount takes into account the non-deductible VAT. task-5993281
This update resolves an issue where payments weren't automatically matched to invoices when 'Outstanding Receipts' accounts were used in the bank journal. The fix allows for amount matching, ensuring accurate reconciliation of payments and invoices. This improves financial reporting accuracy.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387 Forward-Port-Of: odoo/enterprise#109992 Forward-Port-Of: odoo/enterprise#108564
This update restores the previous method for handling files within knowledge articles, resolving a printing problem caused by a recent change. The fix ensures that knowledge articles can now be printed correctly using wkhtmltopdf, improving the user experience for generating reports and documents.
Original PR description
### Purpose of this PR: - Restore the static file box implementation and drop the embedded component, as it breaks printing with wkhtmltopdf. - The original issue with the static file box was fixed in [#241591](https://github.com/odoo/odoo/pull/241591) Reverts: https://github.com/odoo/enterprise/pull/88929 community: https://github.com/odoo/odoo/pull/251098 Forward-Port-Of: odoo/enterprise#109376 Forward-Port-Of: odoo/enterprise#108999
This update corrects a bug in the DATEV export that was causing currency exchange difference values to appear as zero. The fix now uses the line balance, ensuring that actual exchange rates are accurately reflected in the exported DATEV file, providing correct financial reporting.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268