Daily updates from Odoo
Thursday, November 20, 2025
15 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.
This fix ensures the editor’s color picker can see custom colors already used on the page, including for background colors. As a result, users get a consistent selection of page colors and can reuse existing branding colors more easily.
Original PR description
Before this commit, the colorpalette for the background color would not display custom colors already on the page. The issue appeared in 17.0 and worked in 16.0 before the conversion of wysiwyg to owl. github.com/https://github.com/odoo/odoo/pull/118966 The "getEditableCustomColors" method was not forwarded and therefore we used the default function, returning nothing. Steps to reproduce the issue: - Add a snippet - Set the background / font color of the snippet to a custom color - Add another snippet - Open the colorpicker for the text color (The colorpicker have access to the custom color set above) - Open the colorpicker for the background color (The colorpicker does not have access to the custom color set above) task-3806989
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
Anchor links with the “Open in New Window” option now behave as expected and open in a new tab instead of staying in the same page. This fixes a confusing issue that could make users think the setting was not working.
Original PR description
Steps to Reproduce: 1. Create an anchor link for any dropped snippet. 2. Insert the link through the link popover. 3. Enable the "Open in New Window" option. 4. Click on Save. 5. Click on the link. Issue: Even though the "Open in New Window" option is enabled, the page scrolls in the same tab instead of opening in a new window and scrolling to the targeted view. Reason: When an anchor link has target="_blank", `ev.preventDefault()` was still being called, which prevented the browser from performing its default behavior of opening the link in a new tab. Fix: Removed `ev.preventDefault()` for such links, as the expected behavior is to open them in a new tab whenever target="_blank" is set. Additionally, the offcanvas mobile-specific logic has been removed, as it is no longer necessary now that `ev.preventDefault()` is no longer used. task-5104027
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
Documentation and clarification updates
This change updates the Adhoc Contributor License Agreement documentation to include additional members. It matters because it keeps the project’s legal records current for contributors and helps ensure future contributions are properly covered.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes the corporate contributor agreement record for Moduon. It matters for keeping legal and administrative documentation current and aligned with the company’s latest information.
Original PR description
@moduon MT-12696