Thursday, November 20, 2025
11 changes · 17.0
Enhancements to existing features
This update makes the Indonesian E-Faktur Coretax export compute VAT-related values using the correct tax groups, which helps avoid incorrect invoice data in the XML file. It also adds a new tax group, updates related tax definitions, and restricts when the Coretax XML can be downloaded to reduce the risk of generating an invalid export.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267)
This update improves how GSTR-2B issues are handled by recognizing an additional error code and treating it as a warning. It also prevents background jobs from reprocessing records that are already in an error state, which reduces unnecessary processing and helps keep return period handling more reliable.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing.
Resolved issues and error corrections
Balance sheet lines now correctly respect the selected date range in cross-report comparisons. This ensures users see consistent figures when comparing periods and avoids misleading totals in financial reporting.
When a customer used split payment in Point of Sale, payments could be linked to a different contact than the sale itself if the customer was a child contact. This update makes sure the payment and the order use the same accounting partner, keeping customer statements balanced and consistent.
Original PR description
### Description Before this commit, when split payment was enabled for a payment method and a PoS order was assigned to a child contact, the accounting move for the payment was linked to the child contact, while the order move lines were linked to the parent contact. This inconsistency resulted in unbalanced customer statements. This commit ensures that the payment move is assigned to the same accounting partner as the order lines. ### How to reproduce: * Create a child contact (res.partner). * Activate "Identify Customer" (split payment) for a payment method. * Open the session. * Create an order assigning the child contact and pay using this method * Close the session. * Accounting payment for this session will be assigned to child partner opw-5121710
When a form section is hidden during rendering, it now stays blank instead of showing the word “undefined”. This prevents broken-looking layouts in full-size forms, especially where action buttons are generated separately.
Original PR description
Currently if the root node of a template is invisible at compile time the "new root" will contain the word "undefined" in plain text. Instead if we skip rendering the root for whatever reason, the new root should simply be an empty t node. This lead to issues in full-size forms specifically as the controller compiles the buttons separately. Meaning if the buttons div was evaluated to be invisible for whatever reason you would get "undefined" where stats buttons normally go. task-5322823
This fix ensures the vendor on-time rate shown in the smart button matches the graph. It now uses the original purchase order quantity instead of a delivery-side quantity that could be inflated after split or duplicated receipts, so the percentage is accurate for partial deliveries.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367
This update refreshes the LinkedIn API version used by the social integration. It was necessary because the previous version was retired, helping keep LinkedIn publishing and account features working as expected.
Original PR description
This commit updates the linkedin version header so that we can use the version of the API. Our actual version was recently sunset, needing the change of version to be done. task-5271712 Forward-Port-Of: odoo/enterprise#99759
Odoo now handles rejected Egypt e-invoice download responses more gracefully. If the external service returns an unexpected response, the system catches the error properly instead of showing a traceback to users.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195
The German DATEV export now includes bills where the tax total was manually adjusted, so the exported amounts match what users see in Accounting. This prevents incorrect totals in the audit file and keeps the export aligned with the final invoice values.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488
This fix allows users to create a reordering rule for a product in one company even if that product has a kit bill of materials in another company. It prevents an incorrect validation error by only checking kit rules that belong to the same company, so company-specific settings no longer interfere with each other.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491
This change ensures product labels always use the correct currency when calculating prices. It prevents certain label templates from showing incorrect prices due to a parameter mix-up.
Original PR description
Description of the issue/feature this PR addresses: In product label reports, calling _get_product_price with positional arguments may lead to incorrect parameter binding (e.g. currency_id being interpreted as uom). This can cause wrong prices to be displayed in labels in some cases. Current behavior before PR: Some label templates pass currency as a positional argument. This may result in wrong prices being shown depending on argument order. Desired behavior after PR is merged: Label templates always pass currency as a keyword argument, ensuring correct price computation and preventing mismatches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr My CLA signature is being added in this PR: https://github.com/odoo/odoo/pull/236586