Daily updates from Odoo
Friday, February 27, 2026
31 changes · 19.0
New functionality added to Odoo
This update introduces a new AI agent within Odoo that automatically creates partner records during account creation. To ensure data accuracy, a new feature will be added to blacklist specific partners from this automated process. This change improves partner management efficiency.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/84d84687ac09abad698b1b00a445f69a0d896e5f introduce a new ai agent called "Odoo agent" and in the create method a partner is created from it. We will add a new function to blacklist some partner from the retrieve partner functionality task-5973417
This update adds support for obtaining real-time currency exchange rates from the Central Bank of Cuba (BCC). This enhancement allows Odoo to accurately reflect the current exchange rates for transactions involving Cuban currency, improving financial reporting and operational accuracy. It leverages official BCC data for reliable currency conversions.
Original PR description
This commit introduces a new exchange rate provider for the Central Bank of Cuba (BCC). - Implement new exchange rate provider for Central Bank of Cuba (BCC) - Retrieve rates from official BCC source - Reference: https://www.bc.gob.cu/tasas-de-cambio (official published data and documentation) - Parse and normalize published currency values - Support multiple rate types (official, public, special)" Forward-Port-Of: odoo/enterprise#108789 Forward-Port-Of: odoo/enterprise#108367
Enhancements to existing features
This update enhances GST return filing within Odoo's multi-branch system, specifically addressing scenarios where branches operate independently or share a parent company's GST identity. It prevents automatic return creation, guides users to process returns through the parent company, and alerts users to potential conflicts with the parent's GST information.
Original PR description
In a multi-branch GST environment, branches may either share the parent company’s GST identity or operate as independent legal entities. The following improvements align GST return creation/filing…
In a multi-branch GST environment, branches may either share the parent company’s GST identity or operate as independent legal entities. The following improvements align GST return creation/filing with the above logic: - In this commit, we are modifying the GSTR returns so that they will not be created automatically. - Allow independent automatic return creation for branches with a different GST number than the parent. This is the case when the branch company with a different GST number than the parent sets the account opening date - Block the branch having the same GST number as the parent. When creating manual returns. Allowing access to returns filing at the branch level would risk duplicate or inconsistent GSTR filings. Instead, users are guided to process such returns from the parent company using the Tax Unit mechanism. - Display an alert warning when a branch uses the same GST username as the parent, at the time when the user enters credentials in settings. Task-5369591
This update makes the Gantt chart's date selection process faster and more intuitive. Previously, users had to click 'Apply' to see changes; now, date selections update immediately in the UI. This enhances the user experience and allows for quicker adjustments to the chart's date range.
Original PR description
- Previously, the Gantt scale selector only updated the displayed date range after the "Apply" button was clicked. This was because the template was bound to the component props rather than the local state. - This commit binds the date picker display to the local pickerValues state. Now, when a user selects a date in the picker, the UI updates immediately, while the actual data fetch remains deferred until "Apply" is clicked. Task: 5932671 Forward-Port-Of: odoo/enterprise#107380
This update enhances the security and logging around exporting large amounts of data from Odoo spreadsheets. Specifically, it adds logging for common export activities like downloading and printing, and restricts access to frozen/XLSX spreadsheets to authorized users. This improves data tracking and protects sensitive information.
Original PR description
Forward-Port-Of: odoo/enterprise#108289 Forward-Port-Of: odoo/enterprise#85888
Resolved issues and error corrections
This update corrects a bug preventing users from adding dependent salary rules after creating a main rule. The change ensures that all relevant rules are displayed when adding inputs to an employee's payroll, improving payroll configuration efficiency. This resolves a previous issue where dependent rules were hidden.
Original PR description
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the…
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display. Navigation: 1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save 2. Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save 3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save 4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available Objective ---------------------- Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet. Solution --------------------------- Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed. Task: 5942461
Recent tests were failing due to a conflict between modules activating different currencies (EUR vs. USD). This update ensures the OCR consistently uses the default USD currency, resolving the test failures and improving overall test reliability. This ensures consistent test results and a more stable system.
Original PR description
When the tests are run with all modules installed and demo data, some of them fail. One of the other modules activates the EUR currency, which causes the OCR to select it instead of leaving the default USD currency. - Test `test_bank_account` fails because, when the `currency_id` field is set, it triggers a re-computation of `partner_bank_id` which will reset its value to `False`. Runbot build error [240759](https://runbot.odoo.com/odoo/runbot.build.error/240759). - Test `test_invoice_ocr_note_author` fails because it's not expected that the `currency_id` is modified and logged in the tracking message. Runbot build error [238512](https://runbot.odoo.com/odoo/runbot.build.error/238512) (only in saas-19.2 and up, but it is mentionned here as the fix is the same). To make the tests more reliable, we now ensure only the USD currency is active.
This update fixes a bug in the Swiss payroll calculation that resulted in employer costs being incorrectly displayed as zero. The change ensures that employer costs are now accurately calculated and reflected, aligning with Swiss tax regulations. This improves payroll accuracy and reporting for Swiss businesses.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103
This update fixes a technical error that prevented managers without specific appraisal rights from scheduling meetings. The issue stemmed from access restrictions on related partner IDs. The fix simplifies the process by directly using employee work contact IDs, ensuring reliable meeting scheduling for all managers.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127
This update resolves an issue where work entries weren't being generated when multiple resource calendar attendances were adjacent in time. The fix prevents the system from incorrectly combining consecutive attendances, ensuring that work entries are created as expected for credit time and other work entry types. This improves the accuracy of time tracking for employees.
Original PR description
When you have two resource calendar attendances that are stuck together, and you generate work entries, the second one doesn't appear: Bug is caused when having two attendances stuck together: In a resource.calendar, change the time of a resource.calendar.attendance to finish at 15.36 and create a new one that begins at 15.36 and finished at 16.36 with a work entry type of Credit time. Go and regenerate work entries and you can see that no work entries are generated for credit time. Fixed by adding keep_distinct in an interval to not fuse them together. Also added extra checks to another test to not pass with incorrect values. task-5894994
This update fixes a bug that prevented payment advice reports from functioning correctly when employees had multiple bank accounts. The team verified all bank BICs and ensured the system now accurately generates payment advice reports even with invalid data for non-primary bank accounts. This ensures accurate financial reporting for our users.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497
This update resolves an issue where action buttons on the work entry Gantt view would cause errors when no employees were selected. The fix hides these buttons automatically when there are no employees, preventing unexpected errors and improving user experience.
Original PR description
On gantt view of work entries when user multi-selects entries, action buttons appears Ex. Set, Reset etc. When their are no employees in the column, on clicking these action buttons gives traceback. Ex:- `TypeError: Cannot read properties of undefined (reading '0')` or `KeyError: 'employee_id'` This fix will hide these buttons when there are no employees present. task-[5445718](https://www.odoo.com/odoo/project/1251/tasks/5445718)
This update resolves a potential issue during Odoo database upgrades. Previously, removing a payroll rule could cause upgrade scripts to fail. This change ensures that upgrade scripts continue to function correctly even if a rule has been deleted, improving the reliability of database updates.
Original PR description
This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script. If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value. This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted.
This update fixes the XML templates used for Dutch tax reporting (SBR and ICP) to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local tax regulations. The change was made to maintain compliance and avoid potential reporting errors.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update resolves an issue where the VAT Book download was only generating for the primary company, not related branches with the same CUIT. The fix ensures that VAT Books are correctly generated for all selected companies with the same tax identification number, improving reporting accuracy for Argentine businesses.
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 corrects a bug in the Belgian VAT reporting feature that caused key fields ('Ask Restitution' and 'Client Nihil') to be missing from the generated PDF reports. The change restored a necessary wrapper to ensure the correct fields are included, resolving an issue impacting report accuracy for Belgian users. This ensures accurate VAT return generation.
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 error in how payroll rates were calculated for employees on attendance-based contracts. Previously, rates were incorrectly based on actual work hours recorded, not the employee's planned schedule. Now, rates are accurately determined using the employee's working schedule, ensuring correct compensation for attendance-based employees.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry…
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#108637 Forward-Port-Of: odoo/enterprise#103282
This update fixes an issue where deleting a partially signed offer would incorrectly delete the associated employee. The change ensures the employee record is only deleted when the offer is archived and the employee has no other active offers. This prevents data loss and maintains accurate employee records.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109 Forward-Port-Of: odoo/enterprise#100991
This update resolves an issue preventing the SAF-T report from correctly identifying suppliers for fixed assets. The fix ensures that supplier information is accurately retrieved by expanding the data source to include depreciation lines, addressing a problem caused by bills being posted in a previous period.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#105987
This update fixes an issue where check printing in the Philippines wasn't accurately reflecting payments after withholding taxes. Now, the check amount will correctly display the net payment amount, ensuring accurate financial reporting for Philippine businesses. A new test case has been added to verify this change.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108611
This update fixes a bug where NSSF Tier 2 and Pension Contribution deductions weren't consistently shown on payslips, even when correctly reported. The changes ensure that all relevant deductions are accurately displayed on the payslip, regardless of whether contributions are remitted to insurance or the pension authority. This improves payroll transparency and reporting accuracy.
Original PR description
Issue: - NSSF Tier 2 and Pension Contribution salary rules only appeared on the payslip and salary computation when remitted to NSSF. - When Tier 2 was remitted to insurance, NSSF Tier 2 deductions were missing from the payslip display, even though reporting was correct. - Similarly, Pension Contribution was missing from the payslip when pension was remitted to insurance instead of the pension authority. Fix: - Updated the NSSF Tier 2 salary rule condition to ensure it always appears in salary computation and payslip. - Updated the Pension Contribution salary rule to ensure it is always displayed on the payslip even when remitted to insurance. - Adapted the NSSF Report as well. task-5896380
A bug was causing errors when setting up approval rules in web_studio, specifically with boolean domain filters. This update corrects the way domain representations are handled, ensuring that approval rules function correctly when using 'not set' operators. This resolves a technical issue that could prevent users from configuring email approvals effectively.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update fixes a bug where XML invoices received via Peppol didn't display thumbnails. The preview page has been simplified to remove unnecessary elements, and thumbnails are now correctly generated for these invoices. This ensures users can easily view and manage their Peppol-based invoices.
Original PR description
Before this commit: - The preview page of XML invoices received via Peppol was split into two parts: one showing the PDF preview, and another showing the plain HTML of the PDF viewer page - Thumbnail were not generated for these XML invoices After the commit: - The second part of the preview (Text part) was removed. As the users won't be interested to see the raw XML content of the invoice, neither the plain HTML of the pdf preview page. - Thumbnails now are correctly generated for the XML invoices. Notes: This fix is part of the bug-fix task to ensure users can correctly open XML invoices received via Peppol. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update resolves an error that occurred when users attempted to initiate the Colombian Electronic Invoicing certification process without a pre-existing certificate. The fix prevents a traceback by ensuring the 'cert_sudo' variable is properly initialized, improving the stability of the certification workflow.
Original PR description
When no certificate is found in the company, clicking on ``Begin Certification Process`` raises a traceback. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data - Switch to the CO Company - Go to Invoicing > Configuration > Settings > Colombian Electronic Invoicing - Set the Testing ID for Operation mode - In Certificates, delete the existing certificate - Click on Activate the certification process > Begin Certification Process > Ok Traceback: ```py UnboundLocalError cannot access local variable 'cert_sudo' where it is not associated with a value ``` https://github.com/odoo/enterprise/blob/6294be57cf1aa577ec546a958514bc8ec6705935/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1459 The variable ``cert_sudo`` is used outside of the for loop. If no certificate is found, ``cert_sudo`` will be undefined, leading to the UnboundLocalError. sentry-7256943298
This update resolves issues with the Belgian XBRL report, specifically correcting inaccurate translations and removing irrelevant company types. The changes enhance the report's reliability and compliance, ensuring accurate financial data reporting for Belgian businesses.
Original PR description
This commit fixes several issues in the Belgian XBRL report. - Values in report like "false" were being wrongly translated. - Not all company types are valid/relevant. Removed invalid company types. task-5907118
This update resolves an issue where the system incorrectly identified the currency of multiple journals with the same IBAN. The fix ensures that CODA transactions are accurately routed to the correct journal based on its currency, improving financial reporting and reconciliation. This addresses a previous bug introduced in a related update.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108677
This update fixes an error in how Odoo calculates worked days for employees without contracts or when contracts don't fully align with pay periods. The change ensures accurate attendance and out-of-contract day calculations, particularly for new hires and those with temporary employment. Improved accuracy in payroll reporting.
Original PR description
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an…
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an employee without a contract - Create a payslip for this employee for the current month: You'll see X days of attendance (= today until the end of the payslip period) and Y days of out of contract (= number of days from the start of the payslip period until today) - Create a payslip for this employee for the previous month: you'll see ( Z_prev + Y ) days out of contract ( Z_prev = number of working days in the previous month) - Create a payslip for this employee for the next month: you'll see Z_next days of attendance (Z_next = number of working days in the next month) Case 2: - Create a new employee with a contract starting during the current month - Create a payslip for this employee for the previous month - Out-of-Contract days are incorrectly computed as: contract_start_date - previous_month_start. Case 3: - Create an employee with a contract ending during this month - Create a payslip for this employee for the next month - Out-of-Contract days are incorrectly computed as: next_month_end - contract_end_date. Solution: -------- When generating work days lines: - Explicitly handle employees without a contract. - Use adjusted date bounds when the contract does not overlap the payslip period. Several tests were added to cover these scenarios, as well as the tests the corresponding commit in odoo/odoo (PR odoo: 241978) task-5430759 Forward-Port-Of: odoo/enterprise#103207
This update corrects a warning generated during document testing related to fake PDF content. The team replaced these fake files with the standard minimal PDF used for testing, ensuring consistent and reliable test results. This resolves a technical issue that could have impacted the stability of the documents functionality.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update resolves a significant performance issue that caused slow loading times (80+ seconds) and memory errors when accessing key reporting menus. By optimizing the search process, the system now loads these menus in just 8.5 seconds, dramatically improving user experience and reducing server load.
Original PR description
### Problem Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus caused MemoryErrors and 80+ second load times on large databases. ### Root Cause `_read_group_for_accrual` loops…
### Problem
Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus
caused MemoryErrors and 80+ second load times on large databases.
### Root Cause
`_read_group_for_accrual` loops over each group result to manually sum
non-stored computed fields. On each iteration it called `search()` with
a domain containing `('invoice_to_be_issued', '=', True)`, triggering
`_get_accrual_line_ids` once per group instead of once per request.
### Fix
Move the `search()` call outside the loop so matching records are fetched
once per request. The per-group partition is then resolved using
`search_fetch` + `grouped`, which handles the field prefetching and
grouping into recordsets in one call.
### Before / After
| Metric | Before | After |
|-------------------------------|---------|--------|
| Total request time | 82s | 8.5s |
| `_get_accrual_line_ids` calls | 82 | 3 |
| MemoryError on large DBs | ✓ | ✗ |
opw-5392606This update fixes an issue where refund calculations for orders with multiple line items in the l10n_mx_edi_pos module were inaccurate due to incorrect summing of line amounts. The change ensures that refund amounts are compared correctly against the original order total, preventing errors and ensuring proper VAT processing for Mexican businesses. This improves the reliability of refund transactions.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201 Forward-Port-Of: odoo/enterprise#107446 Forward-Port-Of: odoo/enterprise#105301
This update resolves an issue where taxes weren't correctly calculated during Google Pay (GPay) express checkout using Stripe. The fix ensures that Avatax taxes are now accurately applied, aligning the displayed price with the final payment amount. This improves payment accuracy and prevents discrepancies between customer payments and the total order value.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#108957
Forward-Port-Of: odoo/enterprise#101579