Daily updates from Odoo
Wednesday, January 21, 2026
22 changes · master
Resolved issues and error corrections
This update enhances the accuracy of Vietnamese tax reports by correcting outdated calculations and aligning VAT tax definitions. The changes include updating tax labels, assigning accounts, and introducing new tax components, ultimately providing clearer and more reliable tax information for users. This PR is related to a larger Enterprise update.
Original PR description
Before: -`Import tax` remained defined, even though the calculation was not accurate. -Imported VAT taxes were not aligned with the new specifications. -VAT receivable and payable accounts were not assigned to the tax groups. After: -Removed the import tax to match the updated VAT calculation method. -Updated all imported VAT taxes (0%, 5%, 8%, 10%) with the revised labels and descriptions. -Added new VAT-related accounts to the appropriate tax groups to ensure clearer reporting. -Introduced new taxes such as “Subtract Base” and reorganized component taxes. -Cleaned up the tax report by removing the outdated “Import Tax” line. Impact: -Provides clearer, more consistent tax information to users. -Keeps tax reports accurate and easier to understand. Related Enterprise PR: https://github.com/odoo/enterprise/pull/100871 task-5166420
This update enhances the accuracy of tax reports for Odoo Enterprise users in Vietnam by correcting previous calculation errors and aligning VAT tax definitions. The changes ensure clearer, more consistent tax information, simplifying reporting and improving financial data reliability.
Original PR description
Before: -Import tax remained defined, even though the calculation was not accurate. -Imported VAT taxes were not aligned with the new specifications. -VAT receivable and payable accounts were not assigned to the tax groups. After: -Removed the import tax to match the updated VAT calculation method. -Updated all imported VAT taxes (0%, 5%, 8%, 10%) with the revised labels and descriptions. -Added new VAT-related accounts to the appropriate tax groups to ensure clearer reporting. -Introduced new taxes such as “Subtract Base” and reorganized component taxes. -Cleaned up the tax report by removing the outdated “Import Tax” line. Impact: -Provides clearer, more consistent tax information to users. -Keeps tax reports accurate and easier to understand. Related Community PR: https://github.com/odoo/odoo/pull/237873 task-5166420
This update resolves an issue where the POS system in Ecuador would crash when a customer was removed from the partner list after selecting 'Consumidor Final'. The fix ensures a customer is always selected, either a specific customer or 'Consumidor Final', improving stability and compliance with Ecuadorian regulations. This prevents data errors and ensures accurate reporting.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570 Forward-Port-Of: odoo/enterprise#104049 Forward-Port-Of: odoo/enterprise#102221
This update fixes a calculation error in the POS order report's margin calculation. Previously, refunds were incorrectly displayed, leading to inaccurate profit figures. The fix ensures that refund orders are properly accounted for, providing a more precise margin calculation for all order types.
Original PR description
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: -…
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: - the margin is calculated wrong, as we do not consider order sign - as `margin = price_subtotal - total_cost` - so with price_subtotal `200` and total_cost `-100` margin becomes 300 Fix: - consider order sign i.e. -ve for refund order else +ve for `price_subtotal` - so with price_subtotal `-200` and total_cost `-100` margin becomes -100 **Before** <img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" /> **After:** <img width="343" alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" /> Note: for this to be applied, app update is needed opw-5418964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241870
This update fixes inaccuracies in the reporting of Undistributed Profit After Tax (420.1 and 420.2) for Vietnamese accounting. The changes ensure accurate calculation of equity balances by correcting formulas and preventing double-counting, improving the reliability of financial reports.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104935 Forward-Port-Of: odoo/enterprise#104373
This update addresses a potential issue where users could infer application status by seeing warning messages. The change now creates internal activities for applicants, managed by recruiters, providing a more secure and transparent tracking system. This prevents misuse of the application process and improves data privacy.
Original PR description
When applying to a job with an email, phone number, or LinkedIn profile that is already associated with an applicant, a warning would appear showing that there is either an existing applicant or an existing refused applicant. This can cause problems as anyone can use this method to see if a person has applied and deduce the status of their application. This PR replaces these warnings in the frontend by creating activities on the applicant that are assigned to either the applicant's recruiter or the applicant's job's recruiter. task-4943060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update increases the timeout for the main Odoo test suite to address occasional failures during nightly builds. Previously, the suite's execution time exceeded limits due to the continued use of the older, full test run. Increasing the timeout to one hour provides a longer execution window and helps ensure consistent test results.
Original PR description
This commit increases the timeout of the main (desktop) hoot test suite. Since [1], the suite is split by sub-builds, such that each sub-build only runs the tests defined in the addons that are tested by that sub-build. So the suite never timeouts anymore on regular builds. However, in nightly, we still run the whole suite "old school", i.e. all tests in the same run. In that case, the suite sometimes (in 19.1) or often (in master) exceeds the previous timeout (50m). With 1 hour, we hope that it will be enough. Note that the number of tests keeps increasing, hence the need to increase the timeout. [1] https://github.com/odoo/odoo/pull/234132 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#244715
This update resolves an issue where spreadsheet pivot insertions could fail or not resize correctly. The code has been consolidated and now automatically adds necessary columns, ensuring a smoother and more consistent experience for users inserting pivots from spreadsheets, mirroring the web pivot functionality.
Original PR description
Current behavior before PR: - Inserting a pivot from a spreadsheet could trigger spill errors when the pivot had more columns than the default columns. - Columns could not be resized when inserting a pivot from a spreadsheet, unlike insertion from a web pivot view. Desired behavior after PR is merged: - Both pivot insertion flows are combined into a single implementation to remove duplicated code. - Required columns are added automatically to prevent spill errors. - Columns are resized when inserting a pivot from a spreadsheet, matching the behavior of web pivot insertion. Task: [5404283](https://www.odoo.com/odoo/2328/tasks/5404283) Forward-Port-Of: odoo/enterprise#102524
This update resolves an issue where certain carriers weren't correctly recognized when integrating with shipping partners. The change ensures that all carriers are compatible, streamlining the shipping process and preventing errors related to partner recognition. This improves the reliability of order fulfillment.
Original PR description
Forward-Port-Of: odoo/odoo#244742 Forward-Port-Of: odoo/odoo#244035
This update ensures that eWaybill invoices exported from Odoo accurately reflect reverse charge amounts for GST, aligning with the requirements of the Indian government. Previously, the eWaybill JSON didn't include these charges, causing discrepancies. This change fixes this issue, improving data accuracy for export transactions.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This change fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with VAT numbers formatted with or without dots. Now, Odoo will correctly identify and link invoices with the same VAT number, regardless of formatting, ensuring accurate record-keeping and reporting. This improves data consistency and reduces the risk of manual reconciliation.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update resolves an issue where government entities using a TAN instead of a PAN for their GSTIN were incorrectly flagged with an error during partner creation. The fix adjusts the validation process to recognize and support GSTINs based on TANs, ensuring accurate data entry for these important customers. This improves the system's ability to handle government-related business transactions.
Original PR description
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection…
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection Account Number) instead of a PAN as the base for their GSTIN ### Cause: In 19.0, PAN handling was refactored using the new `pan_entity` mechanism With this change, PAN values are validated through `_check_pan_name()`, which incorrectly raises a `ValidationError` for GSTINs that rely on a TAN instead of a PAN: `The entered PAN seems invalid. Please enter a valid PAN.` The PAN entity shouldn't be created for non PAN number ### Steps to reproduce: - Install `l10n_in` and `contacts`, then switch to IN Company - Create a new contact with GSTIN: `07DELN10357E1DH` - Save and the Error is raised ### Notes: At the same time, we'll set the TAN if the GSTIN is based on it The documentation for the TAN structure: https://incometaxindia.gov.in/tutorials/23.%20tan.pdf opw-5461356 Forward-Port-Of: odoo/odoo#243737
This update ensures that the live chat information and member lists automatically open by default when navigating between conversations. Previously, opening one panel would disable the other. This change improves the user experience by providing the most relevant information upfront, making it easier to manage conversations.
Original PR description
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this…
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this necessarily meant the auto-open of member list was disabled, and vice-versa. This is a problem because when navigating between livechat and non-livechat would necessarily imply the dismiss of either panel, which is not good because the best default is having livechat panel open by default, and for non-livechat conversations it should auto-open the member list panel. This commit fixes the issue as follow: - auto-close of panel are aware of whether action are active, as removal of auto-open from auto-close makes sense only when another panel is made active when the older panel was visible - closing of member panel by opening the livechat info panel should preserve auto-open of member list for other conversations Task-5496830 [1]: https://github.com/odoo/odoo/pull/238472 https://github.com/odoo/enterprise/pull/104435 Forward-Port-Of: odoo/odoo#244320 Forward-Port-Of: odoo/odoo#243864
This update prevents subscription start dates or plan changes from automatically resetting manual discounts on order lines. Previously, changes triggered a recalculation that wiped out user-entered commercial discounts. Now, the system checks if the line content has changed before recalculating, preserving user-defined discounts.
Original PR description
Before this commit, changing the `start_date` or `plan_id` on a Subscription would trigger a recomputation of the `discount` field on all order lines. This triggered the standard `_compute_discount`…
Before this commit, changing the `start_date` or `plan_id` on a Subscription would trigger a recomputation of the `discount` field on all order lines. This triggered the standard `_compute_discount` method, which recalculates the price and discount based on the Pricelist, effectively wiping out any manually entered commercial discounts. This occurred because the `_compute_discount` method in `sale_subscription` depends on `order_id.start_date` to calculate pro-rated amounts for upsells. However, it was unconditionally calling `super()`, which runs the standard pricelist logic even when the line content itself (Product, Qty) had not changed. This commit introduces a check to detect if the line content has actually been modified by the user (comparing against the database origin). - If the line content (Product, Qty, UoM) is unchanged, we skip the `super()` call to preserve the manual discount. - If the line content is changed (or it is a new line), we allow `super()` to run to update the price according to the pricelist. This ensures that contextual changes (like shifting the start date) do not destroy manual data entered on the lines. Task: 5788384
This update fixes a layout issue that occurred when reordering items in the cart, ensuring a consistent and functional cart page for all users. The change improves the overall user experience by dynamically adjusting the cart layout and implementing security measures to prevent potential vulnerabilities.
Original PR description
The current cart page layout supports two states: - Empty cart: A single column spans the entire screen width to display a simple message in the center. - Non-empty cart: Two columns are displayed,…
The current cart page layout supports two states: - Empty cart: A single column spans the entire screen width to display a simple message in the center. - Non-empty cart: Two columns are displayed, where the left column shows a detailed view of each order line, and the right column shows a summary and navigation buttons. Before #226128, using the quick reorder feature on the cart page would break the page layout. The initial single-column layout would span the entire screen width, forcing the cart summary onto a new row. The fix in #226128 used a small trick in JavaScript to adjust the cart's column widths on the client side, ensuring compatibility with existing database templates. This commit reworks how the `website_sale.shorter_cart_summary` template is updated. Instead of replacing the inner content of a hook element in the layout, we now replace the hook element entirely with a new version of itself. This ensures that custom styling classes applied to the hook element are updated as well, resolving cart layout discrepancies. Additionally, to reduce the risk of XSS attacks, the "markup-ing" of the updated HTML is now performed at the moment it is fetched from the server. This ensures that the new element is escaped back to a regular string if it is tampered with in any way before being inserted into the page. task-5082207 See also: - https://github.com/odoo/enterprise/pull/104917
The picking operations report was incorrectly printing all deliveries on a single page when multiple deliveries were selected. This change addresses a layout update that removed automatic page breaks, now forcing a page break to ensure reports with multiple deliveries are formatted correctly.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
This update fixes an issue preventing QR codes from being generated for invoices. The change allows QR codes to be created through automation rules and API calls by providing a fallback mechanism for accessing necessary configuration data. This ensures invoices with payment links are correctly generated.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF"; 2. create an automation rule for the `account.move` model; 3. set "Trigger" to…
Versions
--------
- saas-18.3+
Steps
-----
1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF";
2. create an automation rule for the `account.move` model;
3. set "Trigger" to "Create & Edit";
4. set "Apply on" domain to `[("state", "=", "posted")]`;
5. set "When updating" to "Status";
6. add an action to execute the following code:
```python
env['account.move.send']._generate_and_send_invoices(records)
```
7. call `action_post` on an invoice via RPC or Odoo Shell.
Issue
-----
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> RuntimeError: object is not bound
Cause
-----
In order to add a payment link QR code to the invoice[^1], it needs to generate an access token for the portal. This happens via the `generate_access_token` function from `odoo.addons.payment.utils`. Issue is that it relies on having access to a `odoo.http.request` object, so that it can use its `env` to retrieve the `database.secret` config parameter.
When this flow gets triggered via an API call (or Odoo Shell), the `request` object is unbound, causing the error.
[^1]: feature added via commit bcb73cd159885
Solution
--------
Introduce an optional `env` kwarg to `generate_access_token`, falling back on `request.env` if it's not provided.
opw-5487075
Forward-Port-Of: odoo/odoo#244703
Forward-Port-Of: odoo/odoo#243528This update resolves a bug that caused the column layout within the HTML editor to break after performing undo operations. Specifically, changing the number of columns repeatedly resulted in a distorted layout. This fix ensures the column structure remains intact, improving the user experience when editing layouts.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create 3 columns using powerbox - Convert it into 4 columns - Press ctrl + z to make it 3 columns - Convert it into 4 columns again using powerbox Notice that column structure is broken. This happens because after undo operation, in `changeColumnsNumber` the regex replaces column div className incorrectly leading to invalid colund structure. **Desired behavior after PR is merged:** This PR ensures that column structure doesn't break. task-5468578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242500
This update fixes an issue where changing the rental period of an order didn't automatically update related rental transfers. The fix mimics the rescheduling behavior of purchase orders, ensuring that rental transfers are accurately adjusted when the rental period is modified. This improves the reliability of rental order management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#103602 Forward-Port-Of: odoo/enterprise#101334
This update fixes an issue where product prices in Point of Sale weren't accurately calculated when using different currency settings for the PoS. The fix ensures standard prices are converted to the PoS currency, preventing incorrect pricelist calculations and ensuring accurate order totals. This improves the reliability of pricing within the POS system.
Original PR description
The standard price of the products were not converted to the currency of the PoS journal, which could lead to issues when creating pricelist items based on the standard price. Steps to reproduce: ------------------- * Change the currency of any PoS journal to a different currency than the company currency. * Create a product with a standard price > 0. * Create a pricelist that uses the standard price as a base price. (e.g. price = standard price * 2) * Add this product to a PoS order > Observation: The price is not correctly computed according to the pricelist, because the standard price was not converted to the PoS currency. Why the fix: ------------ We just make sure to convert the standard price of the products when loading the products in the PoS session the same way as we do it for the list price. opw-5124388 Forward-Port-Of: odoo/odoo#244147 Forward-Port-Of: odoo/odoo#241168
This update resolves an issue where the 'Import Bank Statement' feature incorrectly selected a journal in multi-company Odoo instances due to elevated server permissions. The fix ensures the import process filters by the currently chosen company, preventing incorrect journal selection and improving data accuracy. A new test confirms the fix's reliability.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#105003 Forward-Port-Of: odoo/enterprise#104326
This update resolves a bug that prevented correct currency display when changing inactive currencies in invoices and bills. The fix ensures that the system properly fetches and uses the correct currency rates, preventing errors and crashes when viewing or editing these documents. This improves the reliability of financial reporting.
Original PR description
In the form view of invoices and bills, if the currency is changed to an inactive one, an option to activate it from the form view was available, but when the button is pressed the front-end doesn't receive the new data related to the currency which resulted in unexpected errors when trying to view the invoice/bill or the list of invoices/bills task-5412003 Forward-Port-Of: odoo/odoo#240086