Tuesday, January 20, 2026
31 changes · saas-19.1
New functionality added to Odoo
This update adds comprehensive tests for the new sections and combo products widgets in Odoo. These tests ensure the correct handling of hidden sections, pricing options, and product movements, enhancing the reliability and functionality of sales order management. The changes improve the overall stability and accuracy of these key features.
Original PR description
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets. HOOT Tests * **Sections widget (account & sale)** * Validate *Hide Composition* and…
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets.
HOOT Tests
* **Sections widget (account & sale)**
* Validate *Hide Composition* and *Hide Prices* actions.
* Ensure duplicating a section also duplicates its invisible `collapse_` fields.
* Confirm drag-and-drop under hidden sections resets `collapse_` values for subsections.
* **Combo products and Optional Sections(sale)**
* Support moving combo lines Up/Down.
* Validate optional product logic.
* Drag-and-drop behavior:
* Moving a product line under an optional section → quantity set to `0`.
* Moving it out of an optional section → quantity set to `1` if previously `0`.
* Moving a subsection under an optional section → resets `collapse_` fields.
Python Tests
* Validate `parent_id` compute logic.
* Test utility methods used in portal and report for Sales Orders with sections.
task-5083152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226613Enhancements to existing features
This update streamlines the accounting process for Ecuadorian businesses within Odoo by consolidating expense accounts and adding a new account for direct employee benefits. It also simplifies reconciliation processes for income-related expense accounts, ensuring accurate financial reporting.
Original PR description
Improve the distribution of expense and cost of revenue accounts in Ecuadorian localization We avoided not creating subcategories of expenses by eliminating the group called "Other employee benefit plan expense", which generated duplicity in the accounts. We fixed this by merging the accounts into the main "Employee benefit plan expense" group. Additionally, the account "Other employee benefits' was added to record any other benefits granted directly by the Ecuadorian companies. This ensures a better organization of the accounting setup. Mark as non-reconcilable the expense accounts (salaries and wages, travel expenses, contributions, etc) to avoid unnecessary reconciliation processes, these accounts are income statements and they are not accounts payable/receivable, therefore, they are closed at the end of the accounting period ### opw-4846355 Forward-Port-Of: odoo/odoo#208047
Resolved issues and error corrections
This update fixes an issue where the product comparison bar was hidden behind other website elements. By increasing the bar's visibility level, users can now consistently access and use the comparison feature regardless of the website's layout. This ensures a smoother shopping experience.
Original PR description
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded).…
This update enhances the kiosk payment process by centralizing IoT communication through a new service, `iot_http`. This improves reliability and security by handling various IoT protocols for payment requests, ensuring smoother transactions for customers.
Original PR description
We now use the `iot_http` service to handle all IoT available protocols to send payment requests. Forward-Port-Of: odoo/enterprise#104811
This update enhances the flexibility of Odoo's website builder by introducing a new system for modifying shape groups. Plugins can now directly adjust these groups, allowing for more dynamic and customizable website designs. This change improves the ability to tailor website layouts to specific business needs.
Original PR description
This commit defines `image_shape_groups_providers` and `background_shape_groups_providers` as new plugin resources. These resources return functions that receive the current shape groups, allowing plugins to mutate them directly or return groups to be merged into the final configuration. Forward-Port-Of: odoo/odoo#243121
Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7 Before this commit: The product comparison bottom bar had a z-index of only 3 (or 4 when expanded). This low z-index value caused it to be overlapped by any website snippets using grid mode with more than 3 items, as grid items conventionally have incremental z-index values (1, 2, 3, 4, ...) for JavaScript consistency. The issue was not limited to s_banner_categories but affected all grid-based snippets, making the comparison bar inaccessible when positioned behind snippet content. Solution: Increase the comparison bar's z-index to -modal (1055 in Bootstrap), ensuring it always appears above regular page content including grid snippets, while still remaining below actual modals and dialogs. After this commit: The comparison bar consistently appears on top of all snippet content, ensuring users can always access and interact with product comparisons regardless of the page layout or snippet configuration. opw:5426163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243975
A technical issue in the Odoo loyalty program tour was preventing users from completing the setup. This fix addresses a problem caused by an infinite scroll feature within the pop-up modal, which was causing the tour to get stuck. Merging this change will ensure the loyalty program tour functions correctly for all users.
Original PR description
fw-port fails because of infinite scroll in pop modal .modal .partner-list 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#218604
This update resolves an issue that prevented users from clicking 'Show', 'Force CFDI', or 'Retry' buttons on invoices after cancelling payments. The fix addresses a technical error related to missing payment information, ensuring invoices can be processed correctly in the MX electronic invoicing process.
Original PR description
When user is clicking any of the `Show`, `Force CFDI`, or `Retry` buttons in l10n_mx_edi.document error occurs. Steps to reproduce: - Install `l10n_mx_edi` module > Switch to `MX Company` - Setup `MX Electronic invoicing` in settings - Create a New Invoice > Send > Select `CFDI` > `Pay` > `Update Payments` - Payment > Cancel that Payment > Back to Invoice > CFDI(Notebook page) > Click on `Show` or `Force CFDI` or `Retry` Traceback: `ValueError: Expected singleton: account.move()` This error occurs when a payment is created and later deleted or cancelled, which results in an empty `move_id` in l10n_mx_edi.document. sentry-7113267386 Forward-Port-Of: odoo/enterprise#102248
This update fixes a bug where the user's final answer in the chatbot wasn't saved or shown in the side panel. The change ensures the final answer is correctly recorded, displayed, and the chat session is properly closed, improving the user experience.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due…
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due to the `isLast` check in `_goToNextStep()`. As a result, `_process_answer()` was not executed, and the user's final answer was not saved, which resulted in the `rawAnswer` field remaining empty and the answer not appearing in the side panel. The chat session was also not marked as closed since the backend route was never called. **Current behavior before PR:** --------------------------------- - The final chatbot answer is not visible in the side panel - The chat session remains open after the final step **Desired behavior after PR is merged:** ----------------------------------------- - The final chatbot answer is saved and displayed in the side panel - The backend route is triggered for the last step - The chat session is properly marked as closed **Task:** 5172125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235102
This update fixes an issue where foreign currency rates weren't correctly applied during Datev CSV exports. Now, invoices with foreign currency settings will accurately reflect the correct rates when generating reports for Datev, ensuring data consistency and accurate financial reporting. This resolves a previous reporting discrepancy.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239649
This update fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately reflects the currency rates set on invoices, ensuring accurate financial reporting for German customers. This improves the reliability of data exported to Datev.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 Forward-Port-Of: odoo/enterprise#101910
This update corrects a technical issue where the kiosk system wasn't correctly receiving payment information from IoT payment terminals. The fix ensures the kiosk retrieves the accurate response data, improving the reliability of self-order transactions. This resolves a potential disruption to the customer ordering process.
Original PR description
In v19.0, IoT Boxes respond with a dict containing a `result` key holding the actual response of the action. The kiosk couldn't get the terminal answer as it was reading directly in the response dict, instead of its `result` key. Forward-Port-Of: odoo/enterprise#104799
A recent test failed due to a problem with how payment providers were being set up across multiple companies in our demo data. This update ensures that each payment provider is linked to the correct website company, resolving the error and improving the reliability of the website's payment functionality. This fix prevents potential issues with assigning payment providers to different companies.
Original PR description
What is fixed ------------- The test_payment_provider_visibility_with_portal didn't pass due to a multi company issue. In demo data, "Demo" payment provider exists for different companies which led the search method to return every one of them. Trying to assign the shop website id to each of them then raises an error as their company_id are inconsistent. The fix ------------- We now ensure only one provider is selected and its company is the same as the website's company. Runbot error : 237822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244441
This update resolves an error preventing branch companies from registering for Peppol when sending from the parent company. The change allows users to correctly activate Peppol in both the main and branch companies, ensuring seamless integration with the Peppol network. This resolves a previous registration issue.
Original PR description
1. Activate Peppol in the main company for both sending and receiving; 2. Create a branch company; 3. Activate Peppol in the branch and select "Send from parent company"; => Error message: "Cannot register a user with a receiver application". opw-5725278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244520
This update prevents errors when creating inter-company invoices by ensuring payment terms are compatible with the receiving company. Previously, invoices automatically used the payment term of the originating company, leading to posting failures. Now, the system correctly applies company-specific payment terms, streamlining inter-company transactions.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both…
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies. * Create a **payment term** assigned to **Company A**. * Create a **sale order** from Company A to Company B using that payment term. * Confirm the sale order and create the **invoice**. * Post the invoice to trigger the inter-company vendor bill. **Observed behavior:** * The generated **vendor bill** for Company B uses **Company A’s payment term**. * Posting fails because the payment term is incompatible with Company B. **Cause:** * Inter-company document creation reuses payment terms without checking whether they belong to the **target company**. * Payment terms from the source company can be propagated to the destination document. **Fix:** * Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices. * Payment terms belonging to a different company are now ignored. **NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution. opw-5392745 Forward-Port-Of: odoo/enterprise#102986
This update resolves a bug in the website builder that caused crashes when customizing shadow settings. The fix prevents errors when shadow values are not in the expected format, ensuring a more stable and reliable builder experience for users. This improves the overall usability of the website customization tool.
Original PR description
Forward-Port-Of: odoo/odoo#244244
This update corrects a technical issue where the payment callback URL was incorrectly triggered, causing verification problems. The fix ensures the callback URL only activates when a redirect is expected, aligning with Razorpay's documentation and improving payment reliability for UPI transactions.
Original PR description
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only…
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only trigger when `redirect` is `True`. Cause: - In Razorpay documentation it's not clearly mention it will only trigger `callback_url` when `redirect` is `True`, so in some cases it redirect to `callback_url` even `redirect` is `False` which is cause issue during signature verification as it try to verify signature according to `is_redirect` with `razorpay_secret` but in oAuth `razorpay_secret` is not set. Razorpay doc link: https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/integration-steps/#123-checkout-options <img width="670" height="537" alt="image" src="https://github.com/user-attachments/assets/81c855c0-aaca-4953-bcff-942bc11a32d2" /> Fix: - Only set `callback_url` for `REDIRECT_PAYMENT_METHOD_CODES` PMs where we expect it to redirect to `return_url` and not in the oAuth flow, Instead relying on the `redirect` option of the Razorpay. opw-5389499 Forward-Port-Of: odoo/odoo#243596 Forward-Port-Of: odoo/odoo#243054
This update resolves an issue where grouping accounting records by their root account was failing, resulting in an error. The change allows for full domain optimization during record retrieval, ensuring accurate grouping and displaying the expected nested records. This improves the functionality of the chart of accounts feature.
Original PR description
Access records in a grouped by `account_root` list failed, showing an error message:
Unsupported operator on Root 'Account' (account.account) in [('root_id', 'any', [('display_name', 'in', [10])])]
Step to reproduce:
- New DB with `accountant` module
- Accounting -> Chart of accounts
- Group By "Root"
- Open any grouped record set
When opening the record set, Odoo fetches data using the domain `[('id', '=', '10')]`
The domain goes through optimization as follows:
```
[('id', '=', '10')]
basic : [('id', 'in', ['10'])]
full : [('root_id', 'any', [('display_name', 'in', [10])])]
```
However, the `_search_account_root` method protects the technical field `account_root`.
This commit adapts it to allow full optimized domain search and solving the error.
Ticket [link](https://www.odoo.com/odoo/project.task/5178896)
opw-5178896
Forward-Port-Of: odoo/odoo#238841This update resolves an issue preventing correct Spanish translations in reports. The fix ensures the translation process has access to necessary data (like user and context) during the translation lookup, resulting in accurate and complete Spanish reports. This improves the user experience for Spanish-speaking customers.
Original PR description
Problem --------- Currently, the lazy translation is executed inside the Markup frame. This has the consequence of having the frame pretty much empty (no context, no user, no cr) when looking for the language. Thus, the lazy translate cannot retreive any language. Solution --------- Use `str` in the compute method so that the frame used to compute the translation is actually the compute method (which has data needed to retreive the language) and not the markup. Before: -> compute ..|-> Markup (the frame used) ....|-> _lt => fail After: -> compute (the frame used) ..|-> _lt ....|-> Markup error-237535 error-237536 Forward-Port-Of: odoo/enterprise#104776
This update resolves an issue where Odoo invoices with discounts generated for the Danish Nemhandel system were failing validation. The fix ensures discounts are correctly accounted for in the invoice data, allowing these invoices to be successfully transmitted to customers. This improves the accuracy of financial data and avoids potential disruptions in payment processing.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241789 Forward-Port-Of: odoo/odoo#241614
This update increases the timeout for the main Odoo test suite to handle the growing number of tests. Previously, the suite would frequently fail due to lengthy run times, but this change provides a longer window to ensure all tests complete successfully. This improves the stability of nightly builds.
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
This update resolves an issue where inserting pivots from spreadsheets could cause errors or prevent resizing. Now, the spreadsheet pivot insertion process is streamlined, automatically adding necessary columns and matching the resizing behavior of web pivots, ensuring a smoother user experience.
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)
This update ensures that the minimum wage is accurately calculated and pro-rated based on employee work time. The change addresses a previous issue where the minimum wage wasn't correctly adjusted, ensuring compliance with Belgian labor laws. This update improves payroll accuracy and reduces the risk of non-compliance.
Original PR description
Since changes made in 302bf2b4e201da8f56b1da012dd7f03c81a85e22 the minimum wage should be pro-rated to the work time rate. Forward-Port-Of: odoo/enterprise#104419
This update resolves a problem where the payer company was incorrectly identified in the 1099 report when using multiple companies. The fix ensures that each 1099 report accurately reflects the correct payer company for each invoice, improving report accuracy and compliance. This impacts users with multi-company configurations.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update ensures that live chat and member lists automatically open by default, regardless of which panel is currently active. Previously, opening one panel would disable the other. This change provides a better user experience by maintaining the preferred default view for both live chat and non-live chat 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 runbot-237994 [1]: https://github.com/odoo/odoo/pull/238472 https://github.com/odoo/enterprise/pull/104435 Forward-Port-Of: odoo/odoo#243864
This update combines member and live chat information automatically when creating tickets through the website helpdesk and WhatsApp channels. Previously, this data was handled separately, leading to a less streamlined experience for users. This change ensures a more complete and accurate view of customer interactions within tickets, improving support efficiency.
Original PR description
*: website_helpdesk_livechat, whatsapp Task-5496830 https://github.com/odoo/odoo/pull/243864 Forward-Port-Of: odoo/enterprise#104435
This update resolves an issue preventing the generation of QR codes for invoices when using automated workflows. The fix ensures the system correctly accesses necessary configuration data, allowing QR codes to be created without requiring a direct HTTP request. This improves invoice automation and payment processing.
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#244610
Forward-Port-Of: odoo/odoo#243528Users were experiencing blocks in the Point of Sale UI due to preparation printers ignoring print requests. This change reverts a recent update to restore normal print functionality and remove the blocking issue. It ensures users can consistently use the Point of Sale feature.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit fcd0aab5f1349310e161b175f118eb8d3db818e4. This unblocks the user's UI in case of a duplicate print Forward-Port-Of: odoo/odoo#243981
A recent change in the Odoo POS system was causing users to be blocked from printing, leading to frustration. This pull request reverts a previous update to restore the normal printing functionality and resolve this blocking issue.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit 5e290c264f14108e036344663fc459bf77da265e. This unblocks the user's UI in case of a duplicate print Forward-Port-Of: odoo/enterprise#104421
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring correct price difference calculations and accurate financial reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243941 Forward-Port-Of: odoo/odoo#238428
This update resolves an issue where certain carriers weren't correctly integrated with shipping partners within the website sale module. The change ensures that carrier options align properly with available shipping partners, leading to more accurate shipping calculations and a smoother customer experience. This improves the reliability of the online ordering process.
Original PR description
Forward-Port-Of: odoo/odoo#244649 Forward-Port-Of: odoo/odoo#244035
This update fixes an error in the financial reporting for Vietnam (l10n_vn_reports) that resulted in inaccurate calculations for key balance sheet codes (420.1 and 420.2). The changes ensure these figures accurately reflect equity and profit, improving the reliability of financial statements.
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#104786 Forward-Port-Of: odoo/enterprise#104373