Thursday, February 26, 2026
26 changes · saas-19.1
Enhancements to existing features
This update streamlines the process of creating bank accounts for companies, particularly those requiring trusted verification. Users will now be directly prompted to activate accounts with their bank, simplifying the setup and reducing potential errors. This change improves the overall efficiency of managing company financial information.
Original PR description
Forward-Port-Of: odoo/odoo#249983
This update simplifies how businesses can tailor the product container displayed on the website, particularly for different modules. Previously, customization required complex code changes, now a dedicated method makes it easier to adapt and maintain, leading to greater flexibility and future compatibility. This change supports a more adaptable website experience.
Original PR description
The product_container element may vary across modules and cannot be hardcoded. Modifying it currently requires overriding the entire add_to_cart method, which reduces flexibility and maintainability. This change extracts the product_container logic into a dedicated method, making it easier to extend and customize without duplicating the full add_to_cart implementation. This ensures better forward compatibility and modular extensibility. Enterprise PR: https://github.com/odoo/enterprise/pull/107343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves an issue preventing the export of BOE reports when using multiple branch companies with different VATs. The fix ensures the report correctly considers all companies in the multi-company setup, allowing users to generate the necessary reports. This improves the functionality for businesses managing multiple entities.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_reports** module. * Create a parent company with two branch companies with all has different VATs. * Enable **multi-company mode** with all companies selected. * Go to tax report `Mod 390` * From gear icon clck on `BOE`. **Observed behavior:** * A warning appears: Please select the main company and its branches in the company selector to proceed. * Not able to export BOE. **Cause:** * This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierachy are in the options => they're not => error. **Fix:** * Added the `'branch_allowed': True` to the `BOE` button options. opw-5891472 Forward-Port-Of: odoo/enterprise#107252
Code cleanup and technical improvements
This update enhances website builders by automatically suggesting existing website pages and anchors when users select URLs. The change replaces an older system with a new, more efficient component that provides better internal linking options, streamlining the website creation process.
Original PR description
When website is installed, all URL pickers should suggest existing website pages and anchors. Before this commit, the `WebsiteUrlPicker` used `autocompleteWithPages` to suggest internal links. This…
This update resolves a technical error preventing UK tax reports from successfully connecting to HMRC. The issue stemmed from a missing VAT value on the company record. The fix ensures VAT is automatically set, allowing users to accurately file their tax returns. This prevents report submission failures.
Original PR description
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5 - Install l10n_uk_reports module - Keep the VAT value empty for the UK Company - On the Tax…
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear
<details><summary>Exact Traceback</summary>
<p>
```
RPC_ERROR
Odoo Server Error
Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
return retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 57, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
return report_method(model, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
self._get_vat(),
^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
if vat.startswith(('GB', 'XI')):
^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```
</p>
</details>
Reason:
- No VAT set on the current company.
Solution:
- Blocking level error for the user to set VAT on the current company.
Task-5929908
Forward-Port-Of: odoo/enterprise#107150This update streamlines the process of adding and locating bank accounts within Odoo Enterprise. The changes consolidate how bank accounts are handled, resolving inconsistencies and improving efficiency for users. This impacts several modules related to financial transactions and reporting.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update fixes an issue where accounts without a code in the consolidating company were being excluded from reports, leading to inaccurate totals. The change now intelligently searches for the correct account code across other companies to ensure accurate report consolidation and data consistency.
Original PR description
Description of the issue this commit addresses: When consolidating reports, any account that doesn't have a code on the consolidating company is filtered out of the consolidation. This will lead to amounts that do not match which should not happen. --- Desired behavior after this commit is merged: When an account should be used but is filtered out because of not having a code in the per company mapping, we try to find its code on any of the other companies he is and use that one as anchor in the consolidation. --- task-5911409 Forward-Port-Of: odoo/enterprise#107651
This update fixes an issue where shipping capacity percentages were inaccurate in batch transfers. The change ensures that each batch's estimated weight and volume are calculated correctly, providing users with reliable data in both the list view and individual record views. This improves the accuracy of dispatch management.
Original PR description
## Issue Before This PR: The fields `used_weight_percentage` and `used_volume_percentage` in the list view were showing incorrect values. These fields were incorrectly aggregating totals across all…
## Issue Before This PR: The fields `used_weight_percentage` and `used_volume_percentage` in the list view were showing incorrect values. These fields were incorrectly aggregating totals across all batches, as the calculation of `estimated_shipping_weight` and `estimated_shipping_volume` was not handled per batch, resulting in wrong percentages. ## Steps to Reproduce: - install inventory module and enable settings for batch transfers and dispatch management, - add two batch records with vehicles assigned (having weight or volume capacity), and transfers having products with weight or volume defined - Observe different values of weight % or volume %, in form and list view. ## Cause of the Issue: In the method `_compute_estimated_shipping_capacity` the computation loop referenced all records together, causing totals to be shared across batches. ## With This PR: Each batch now computes its own estimated shipping weight and volume correctly, ensuring correct per-batch values consistent with the form view and match what users see when opening individual records. Backport of [commit](https://github.com/odoo/odoo/pull/227166/changes/a709e84d8357a622198a8ac0a0199af9b16f56e7) Forward-Port-Of: odoo/odoo#250317 Forward-Port-Of: odoo/odoo#249239
This update resolves an issue where invoices generated using the Folder layout in India were being duplicated in the PDF reports. The problem stemmed from a formatting element in the invoice header that caused pagination errors. The fix replaced a specific HTML tag to reduce spacing and prevent the double rendering, ensuring accurate invoice printing.
Original PR description
**Steps to reproduce:** 1. Install l10n_in module 2. Switch to india 3. Go to Settings → Configure Document Layout and select Folder layout. 4. Create two Invoices: Select a customer. Add at least 6–7 invoice lines. Confirm the invoices then duplicate and again confirm. 5. Go back to the Invoice list view. 6. Select both newly created invoices. 7. Click Print **Issue:** When using Folder layout, invoices were rendered twice in PDF while printing. **Cause:** The `HSN Summary` title used an `<h3>` tag. Its larger default margins increased the document height, triggering a pagination reflow issue in wkhtmltopdf specific to Folder layout (due to floats and dynamic header spacing). This caused the invoice to be rendered twice. **Fix:** Replaced `<h3>` with `<h4>` to reduce vertical spacing and avoid pagination overflow. opw-5452609 Forward-Port-Of: odoo/odoo#249413
This update resolves a bug where the booking view wouldn't load after refreshing the Manage Booking page in our POS system. The fix ensures the booking view renders correctly, improving the user experience for appointments. This change was made to prevent disruptions in appointment scheduling workflows.
Original PR description
Steps: ----- - Install pos_appointment and pos_urban_piper modules. - Open a session for an UrbanPiper-configured POS. - Open the Manage Booking page. - Refresh the page. Issue: ----- - The booking view is not rendered after a page refresh. Cause: ----- - An awaited request in the posStore setup caused the `ActionComponent` not to be rendered yet when the `doAction` was called. Fix: ----- - First render the `ActionComponent`, then fetch the action data, and finally call `doAction`, so the action is executed seamlessly without interruption. Task-5713125 Forward-Port-Of: odoo/enterprise#105629
This update resolves an issue where the 'account_iso20022' module was generating invalid XML for Swiss payment files (pain.001). The fix ensures that only one of BIC or ClrSysMmbId is included, aligning with Swiss banking standards. This prevents payment processing errors and ensures compliance.
Original PR description
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner or payrun report - Pay with "Swiss ISO20022" > generate xml pain001 - Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml ! **Cause:** In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf). **Solution:** Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6). opw-4872507 Forward-Port-Of: odoo/enterprise#108461
This update fixes an issue in the barcode picking interface where multiple extra product scans would repeatedly open a confirmation dialog. Now, the dialog opens only once and dynamically updates, allowing users to easily select and deselect extra items before confirming the addition to their order. This streamlines the picking process and reduces user frustration.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269) Forward-Port-Of: odoo/enterprise#108623 Forward-Port-Of: odoo/enterprise#104932
This update fixes an issue where delivery slips incorrectly calculated package weight by omitting the weight of products inside. The system now accurately includes product weight when determining the total weight for shipping, ensuring accurate delivery costs and reporting. This improves the reliability of shipping calculations.
Original PR description
On delivery slip, the total weight of a package doesn't include the weight of the product in the outermost package. Steps to reproduce: ------------------- * Create a Package "Pa" with a package type…
On delivery slip, the total weight of a package doesn't include the weight of the product in the outermost package. Steps to reproduce: ------------------- * Create a Package "Pa" with a package type that has a weight * Create a product "Po" tracked by quantity * Add two units of the product Po to the package Pa * Create Delivery with two units of Po. * Confirm the Delivery and print the delivery slip -> The total weight is the weight of the package type without including the products inside. Observation: ------------- When computing the shipping_weight for the delivery, it will fallback on the package_weight to calculate it weight, https://github.com/odoo/odoo/blob/ca14f1aa21a75398919c1453be19011522bb3b5c/addons/stock/models/stock_picking.py#L893-L906 It retrieve the weight calculated by _get_weight https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_package.py#L435 Except for the outermost package, where it incorrectly considers only the package type weight and does not include the products weight opw-5499770 Forward-Port-Of: odoo/odoo#247227
This update resolves a validation error occurring during tax calculation for invoices in the Brazilian localization (BR). The issue stemmed from incorrect tax data being sent to the Avatax service due to redundant calculations. This fix ensures accurate tax data is transmitted, preventing invoice validation failures.
Original PR description
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not…
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not applicable - [Sales] Service Code Origin: 14.01.3/168061/1524 - [Sales] Service Codes: 14.01.3/168061/1524 - Create an Invoice with Document Type "Electronic Service Invoice - NFS-e" - Add the product on the line - Compute taxes - Compute taxes again Issue: Action will be blocked by a validation error resulting from the external taxes call ``` odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice. Errors: Rejection: Total Installments doesnt match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 ``` It occurs because during the call the system is considering the existing taxes on the line and it will send to the avatax service wrong amounts opw-5412456 opw-5409735 Forward-Port-Of: odoo/enterprise#108403 Forward-Port-Of: odoo/enterprise#108088
This update ensures self-order transactions in Point of Sale (POS) systems – including online payments, restaurants, and standard self-order – now use the same data validation rules as regular POS orders. This enhances data accuracy and reliability, reducing potential errors and improving the overall POS experience.
Original PR description
*: pos_online_payment_self_order, pos_restaurant, pos_self_order This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order. Forward-Port-Of: odoo/odoo#249455
This update fixes an issue where VAT amounts were incorrectly displayed as zero in XML reports generated from manual journal entries. The fix removed a filtering condition that was excluding standard product lines, ensuring accurate VAT calculations for deductible tax entries. This ensures correct reporting for tax compliance.
Original PR description
## Issue: When creating a manual journal entry with a deductible tax, the entry was included in the XML export, but the VAT amounts were all set to 0 ## Cause: The SQL query used to compute VAT amounts included an extra condition on display_type to be 'tax' However, journal entry lines are standard product lines and should not be excluded by this condition As a result, the amounts (MHT, TVA, TTC) were incorrectly computed as 0 in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA Company - Create a Journal Entry (Any account, Debit: 100, Taxes: 10% 150) - Open the Tax Report for the current month - Export the XML using the gear icon Before the fix, the value for mht, tva and ttc where all 0 opw-5226529 Forward-Port-Of: odoo/enterprise#108644
This update fixes an issue where the website builder's sidebar wouldn't block during reloadable actions when network speeds were slow. Now, the sidebar correctly blocks, ensuring a smoother and more reliable experience when making changes to website templates. This improves the usability of the website builder for our users.
Original PR description
When we perform a reloadable action in the builder, the builder's UI is not blocked, unlike in previous versions before the html_builder [refactoring] Steps to reproduce the issue: - Open website, and click on the header - In the dev tools, set the network throttling to 3G or slow 4G - Change the header's template => Notice that the sidebar is not blocked, while it should be. [refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5952793 Forward-Port-Of: odoo/odoo#250577 Forward-Port-Of: odoo/odoo#249526
This update fixes an issue where Odoo incorrectly displayed records after a user switched between companies. Previously, the system didn't immediately update the URL needed for correct record loading, leading to incorrect views. Now, the system reliably directs users to the correct record after a company change, ensuring a smoother user experience.
Original PR description
Have a flow where an action act_window is executed and wants to open a record in the form view, but that record is not in one of the companies that the current user is logged in. The ORM will crash with an access denied, that the JS catches cleverly (see odoo/odoo@6213c40932236101b529b82f0ea9fce1829c8c24) and tries to reload on that failed action after altering the allowed companies. Before this commit, this flow was imperfect because the url (that allows to reload at the right place) was not written immediately. So, more often than not, we ended up on the wrong view after reload. After this commit, we end up in the right action after reload. 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#250401
This update ensures rental accessories added from the cart page now use the same rental period as the existing cart, resolving a previous error that prevented accessories from being added. Previously, the system incorrectly compared rental periods, leading to compatibility issues. This change improves the user experience and prevents errors when adding rental accessories to carts.
Original PR description
Why this commit --- When adding a rental accessory product from the cart page suggested products, the…
Why this commit --- When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error preventing it from being added to the cart. This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there. After this Commit --- The rental start and end dates from the current sale order are passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error. Steps to Reproduce --- 1. Create two rental products A and B. 2. Configure product B as an accessory of product A. 3. Add product A to the cart with any rental period(except default). 4. From the cart page, attempt to add product B from suggested products. 5.Observe the error about mixing different rental periods. Here is the video demonstrating on how the error is reproduced : https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7 Expected Result The accessory product is added to the cart using the same rental period as the existing cart's rental period. Community PR: https://github.com/odoo/odoo/pull/249289 OPW: 5823691 Forward-Port-Of: odoo/enterprise#106426
This update corrects a bug that caused time off requests to be incorrectly displayed as allocations within the reporting system. The issue stemmed from a misalignment in the database query used to generate the reports, leading to incorrect record identification. This fix ensures that time off requests are now accurately displayed and reported.
Original PR description
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#249015
This update corrects a bug that prevented specific fields (Ask Restitution and Client Nihil) from appearing in the Belgian VAT return PDF reports. The change involved restoring a wrapper that correctly targeted the intended section for injecting these localized fields. This ensures accurate reporting for Odoo users in Belgium.
Original PR description
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper. 18.3-:…
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper.
18.3-:
https://github.com/odoo/enterprise/blob/ce67bf6fb4f694c25785580fe3ed290bcb8c92b5/account_reports/data/pdf_export_templates.xml#L151-L154
18.4+:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/account_reports/data/pdf_export_templates.xml#L159-L160
This broke `l10n_be_reports` which uses `(//div[hasclass('row')])[last()]` to inject BE-specific fields:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/l10n_be_reports/data/tax_report.xml#L9-L24
Without the wrapper, `[last()]` targets the conditional `aml_ir_filters` row instead, making BE fields invisible.
Steps to reproduce:
1. Create a Belgian company
2. Navigate to Accounting → Reporting → Tax Return
3. Create a VAT Return and submit it
4. Check the generated PDF in the attachment
=> The "Ask Restitution" and "Client Nihil" fields are missing from the PDF header.
Ticket [link](https://www.odoo.com/odoo/action-4043/5509725)
opw-5509725
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#107519This update fixes an issue where the VAT Book download was only generating for the primary company. Now, when multiple branches with the same CUIT are selected, the VAT Book will include data for all of them, ensuring accurate reporting for businesses with multiple branches.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#101898This update fixes an issue where users received blank PDF reports when attempting to print the planning report through the standard print menu. The fix ensures the report uses the correct data preparation process, guiding users to the intended calendar print button for accurate report generation.
Original PR description
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.…
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report. **Steps to reproduce:** 1. Go to Settings app and enable debug mode 2. Navigate to Technical → Reports 3. Search for "slot_report" 4. Click "Add to print menu" button 5. Refresh the browser 6. Go to Planning app and switch to list view 7. Select a few planning.slot records 8. Click Print → Planning **Current behavior:** A blank or invalid PDF is generated. **Expected behavior:** Users should receive a clear error message directing them to use the correct print method from the calendar view. **Cause of the issue:** The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports. **Fix:** Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data. opw-5477184 Forward-Port-Of: odoo/enterprise#105168
This update introduces a new 'Net Cost' salary rule in the UAE payroll module to accurately reflect employer costs. Previously, certain rules incorrectly reduced both employee and employer costs. This change ensures that employer contributions are calculated correctly, providing a more precise view of business expenses.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761
This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering errors due to uncertain data, which is now simply removed. This ensures payments can process smoothly and reliably.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632 Forward-Port-Of: odoo/odoo#250941
This update corrects a bug in the Belgian payroll system related to calculating sick leave. When employees take extended periods of sick leave, the system incorrectly identified different work entry types, leading to inaccurate payroll processing. This fix ensures accurate tracking of sick leave durations and avoids potential payment discrepancies.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code (see related Community PR) and we move the BE specific changes to the BE localization module. Here we override the check function to allow for the specific case described above, where LEAVE110 is the code for sick time off and LEAVE214 is the code for sick time of without pay. Task: 5472538 Community PR: https://github.com/odoo/odoo/pull/246116
When website is installed, all URL pickers should suggest existing
website pages and anchors.
Before this commit, the `WebsiteUrlPicker` used `autocompleteWithPages`
to suggest internal links.
This commit removes the usage of `autocompleteWithPages` and
replace `WebsiteUrlPicker` with `BuilderUrlPicker` with an Autocomplete
component completely to provide internal link and anchor
suggestions.
Key Changes:
- Introduce `AutoCompleteBuilderUrlPicker` component extending the base
`AutoComplete` component.
- Patch BuilderUrlPicker to:
- Replace its input with AutoCompleteBuilderUrlPicker.
- Provide a `sources` getter delegating suggestions to
loadOptionsSource.
- Handle selection vs input through `isOptionSelected`.
- Extract and reuse loadOptionsSource in website utils.
- Move `loadOptionsSource` to utils.
- Add `title` prop and `isOptionSelected` flag to AutoComplete to
properly differentiate selection vs input.
Enterprise PR: [106706](https://github.com/odoo/enterprise/pull/106706)
task-5260613
Forward-Port-Of: odoo/odoo#226324