Friday, December 26, 2025
6 changes · saas-18.4
Resolved issues and error corrections
This update fixes a reporting issue where the Expected Arrival Date wasn't displayed on DIN 5008 Purchase Order reports. The fix adds this crucial information to the report template, aligning with previous versions and confirmed requirements from internal teams. This ensures accurate reporting for DIN 5008 transactions.
Original PR description
**Steps to reproduce:** 1. Install l10n_din5008 and purchase modules. 2. Switch the Document Layout template to DIN 5008. 3. Create or open an existing Purchase Order. 4. Print the Purchase Order…
**Steps to reproduce:** 1. Install l10n_din5008 and purchase modules. 2. Switch the Document Layout template to DIN 5008. 3. Create or open an existing Purchase Order. 4. Print the Purchase Order report. **Issue:** The Expected Arrival Date does not appear on the DIN 5008 Purchase Order report. Both functional experts and PO (CHKL) confirmed that the Expected Arrival Date should appear by default on the Purchase Order report in DIN 5008. **Cause:** The date_planned (Expected Arrival) field was introduced in standard Purchase Order report in v18.0, but DIN 5008 report template was not updated accordingly **Fix:** Add the Expected Arrival information to the DIN 5008 Purchase Order template. Before: <img width="606" height="162" alt="image" src="https://github.com/user-attachments/assets/e11f5b1f-5898-4ec9-a4f2-087db5dfeced" /> After: <img width="605" height="147" alt="image" src="https://github.com/user-attachments/assets/57419d00-50c9-4508-9bfc-307c0a54dc67" /> **opw-5376176** Forward-Port-Of: odoo/odoo#239619
This update corrects a previous error in the Profit & Loss report's Gross Profit calculation, now accurately reflecting stock effects. Additionally, the report's layout has been simplified for better readability and user experience. This ensures more reliable financial reporting.
Original PR description
Previously, the Gross Profit calculation did not include the stock effect, which resulted in incorrect values. With this PR, the Gross Profit is now computed including the stock effect, ensuring accurate results. In addition, some UI adjustments have been made to simplify and improve the readability of the report. task-5357539 opw-5163207 master PR: https://github.com/odoo/enterprise/pull/101650 Forward-Port-Of: odoo/enterprise#101649
This update fixes an error in how VAT is calculated for transactions using Reverse Charge taxes, particularly when combined with non-deductible tax configurations. Previously, the output VAT was incorrectly reduced. Now, the full VAT amount (21%) is correctly declared as due, aligning with standard Reverse Charge regulations.
Original PR description
When combining a Reverse Charge tax (e.g., Intra-Community Acquisition) with a Non-Deductible tax configuration (e.g., 60% Professional Use), the resulting accounting entry for the VAT Payable…
When combining a Reverse Charge tax (e.g., Intra-Community Acquisition) with a Non-Deductible tax configuration (e.g., 60% Professional Use), the resulting accounting entry for the VAT Payable (Output Tax) was incorrect. Steps to reproduce: 1. Create a Vendor Bill. 2. Use a Tax configured as both Reverse Charge (e.g., 21%) and partially Non-Deductible (e.g., 40% non-deductible). 3. Set the price to 100.00. Observed behavior: - VAT Deductible (Input): 12.60 (Correct: 60% of 21). - Non-Deductible Expense: 8.40 (Correct: 40% of 21). - VAT Payable (Output): 12.60 (Incorrect: it was reduced by the non-deductible part). Expected behavior: - VAT Payable (Output) should be 21.00. In a Reverse Charge mechanism, the full tax amount must be declared as due, regardless of the deductibility on the input side. Solution: Post process the taxes_data in case of professional with reverse-charge so wie will have the Payable part with the hole amount 21 in the previous example task-5418096 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240955
This update fixes an issue where holiday carryover days weren't being calculated correctly, leading to an inaccurate count of expiring days. The change ensures that accrued holiday days are properly added before the expiration date is determined, resolving a discrepancy in the number of days expiring.
Original PR description
To reproduce: ============= - Create an accrual plan: - Carryover date: allocation - One level: - Accrues 2 days. - Accrual date: monthly on 1st of each month - Starts immediately on allocation start…
To reproduce:
=============
- Create an accrual plan:
- Carryover date: allocation
- One level:
- Accrues 2 days.
- Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
- Starts on 01/07/2024
We should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.
Problem:
========
When `accrued_gain_time` of the accrual plan is 'start', in the `_process_accrual_plans` method, the property `expiring_days` is set when the first accrual still hasn't been added to the `number_of_days` (it is usually added at the [end of the loop](https://github.com/odoo/odoo/blob/18.0/addons/hr_holidays/models/hr_leave_allocation.py#L596)).
Solution:
=========
In the `_process_accrual_plans`, add the accrued days to the `number_of_days` before the `expiring_days` is set.
[opw-4963163](https://www.odoo.com/odoo/all-tasks/4963163)
Forward-Port-Of: odoo/odoo#233424This update corrects a bug where the analytic distribution of expenses wasn't consistently applied when reinvoicing to customers. Now, the analytic account linked to the sales order takes priority, ensuring accurate tracking of costs and revenue across all related documents (expense, invoice, and sales order).
Original PR description
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account…
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account “Commercial &Marketing” to the previous created product “Hotel” - Create an SO for a customer “Gilles”. The SO is linked to the analytic account “Home Construction” - Create an expense which category is “Hotel”. The analytic distribution is automatically set to “Commercial & Marketing” - Reinvoice this expense to “Gilles”. The analytic distribution automatically changes to “Home Construction”. -> Wrong. We lose part of the information - When posting the expense report, the expense is added in the SO through a dedicated SO line. The analytic account previously set as “Home Construction” is now transformed, for an unknown reason, into “Commercial & Marketing”. -> Wrong. - On the vendor bill, the analytic distribution is “Home Construction” Now: 1. The analytic plans from the expense and from the SO are different. Simply add the analytic account from the SO 2. The analytic plans are the same. There are conflicts. In this case, the analytic distribution set on the SO is prioritary. We ensure that costs incurred or sales generated from the expense are reflected in the SO's analytic plan rather than the generic one. In the previous example, Home Construction is the only analytic account that should be considered on the expense, bill and SO. task-4564463 Forward-Port-Of: odoo/odoo#240762 Forward-Port-Of: odoo/odoo#233794
This update fixes a bug that caused duplicate work orders to be created when a manufacturing order's Bill of Materials (BoM) and quantity were modified. The fix ensures that work orders are only generated once, streamlining the production process and preventing errors.
Original PR description
Steps to reproduce:
- Create a storable product "P1"
- Create a BoM with one operation
- Create a manufacturing order for product "P1"
- Do not set any BoM
- Save
- In draft state:
- Set the BoM
- Without saving, update the quantity to produce
Problem:
The same operation is added twice, resulting in duplicate work orders.
Cause:
Work orders are recomputed multiple times when BoM and quantity are changed before saving, and existing (not yet saved) work orders linked to the same BoM are not properly filtered out.
Fix:
Ensure that work orders linked to the current BoM are only created once during recomputation.
opw-5404686
Forward-Port-Of: odoo/odoo#241319
Forward-Port-Of: odoo/odoo#240757