Daily updates from Odoo
Wednesday, March 4, 2026
13 changes · master
Resolved issues and error corrections
This update resolves an issue where taxes weren't correctly calculated during Google Pay (GPay) express checkout using Stripe. Specifically, Avatax calculations were missing, leading to discrepancies between the displayed price and the actual payment amount. This ensures accurate tax reporting and customer pricing.
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#109121
Forward-Port-Of: odoo/enterprise#101579This fix resolves an error that occurred when no tax type was selected in Argentinian reports (like ARBA profits). Previously, the system would crash. Now, the report functions correctly even without a tax type selection, ensuring accurate reporting for Argentinian businesses.
Original PR description
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report.…
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view The error was this one: Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Forward-Port-Of: odoo/enterprise#100457
This update resolves an issue where the call method selection dialog wasn't appearing on mobile devices after adding a new call. The fix ensures the dialog is displayed correctly above the softphone, preventing errors and improving the user experience. It also includes a safety check to prevent errors when the dialog isn't immediately available.
Original PR description
After add-call PR: https://github.com/odoo/enterprise/pull/92835 when the user tries to add another call on mobile, they don't get the dialog that asks for the call method. This is because it was showing behind the softphone which also led to traceback when you click on it after ending the current call/s. This commit fixes that by making sure it's showing above the softphone in the calling state. Also, it adds a null check in the querySelector result before destructuring so that it returns instead of thrwoing an error if it was null (what happens when you click on it after you end the call). Task-5999040
This update ensures the IEPS (tax) breakdown is correctly displayed on Mexican CFDI invoices, aligning with SAT regulations. Specifically, it now only shows the IEPS if the invoice is a 'global invoice' or uses tax object 07, addressing previous inconsistencies. This ensures accurate tax reporting for Mexican businesses using Odoo.
Original PR description
This commit targets to modify the behaviour of IEPS breakdown on CFDI to follow on what is specified on SAT cfdi Tax Object Catalog. Now the IEPS will be displayed only considering if the CFDI is a global invoice, the value of the tax object and whether the check is set. The general idea is: - Is a global invoice? -> show IEPS - Is tax object 07? -> show IEPS - Has ieps breakdown but is not tax object 08? -> show IEPS - Anything else, don't. task-5953499 target: saas-18.4 -> master Forward-Port-Of: odoo/enterprise#109318 Forward-Port-Of: odoo/enterprise#108555
A recent issue causing a crash when clearing booking dates in the restaurant appointment booking flow has been fixed. This update ensures the system correctly handles empty date values, preventing disruptions to the user experience. The fix improves stability and reliability for restaurant bookings.
Original PR description
Clicking the 'Clear' button in the booking date picker caused a crash because the system didn't expect the date fields to be emptied. This fix allows the booking popup to handle empty date values correctly without crashing. task-id: 5964417
This update corrects a bug where salary inputs weren't properly copied when creating duplicate selections. Previously, this prevented certain salary calculations from working correctly. The fix ensures that all necessary selection options are now accurately reflected, improving payroll accuracy and functionality.
Original PR description
When having a salary input avaiblable for employee and payslip, and using it in an employee made it unavailable in payslips. This is unwanted behaviour and is due to the domain restricting existing_ids in employees. This was extracted from the action and is set in each separate model according to the needs. task-5909636 Forward-Port-Of: odoo/enterprise#109277 Forward-Port-Of: odoo/enterprise#106488
This update fixes an issue where payroll reports and payment exports incorrectly displayed employee names instead of the actual account holder's information. The change ensures payment records accurately reflect the bank account partner, improving data accuracy and compliance across various localized payroll modules (AU, BE, CH, IN, SA, US).
Original PR description
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip…
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV). 4. Observe that the employee's name is displayed instead of the account holder's information. Issue: Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder. Solution: Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner: - Updated QWeb templates to display bank.partner_id.name for account allocations. - Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID. - Ensured a fallback to the employee's legal name remains in place. opw-5357652 Forward-Port-Of: odoo/enterprise#108785 Forward-Port-Of: odoo/enterprise#106718
This update resolves a stability issue in the invoice processing cron job for Brazilian tax documents. Previously, a single error would halt the entire process, wasting credits. The fix now processes invoices in smaller batches, committing changes after each, ensuring progress is preserved and preventing disruptions.
Original PR description
The cron searched with limit=batch_size and only retriggered when >batch_size records were found which never happens. It also ran all invoices in a single transaction so one failure rolled back all progress while IAP credits were already consumed. Search batch_size + 1 so remaining invoices are detected, and commit after each invoice to preserve progress. opw-5954211 Forward-Port-Of: odoo/enterprise#109315 Forward-Port-Of: odoo/enterprise#108191
This update simplifies the process of adding employees to workorders in Odoo Enterprise. Previously, the automatic employee creation for admins was removed, causing issues. Now, a popup allows quick employee creation with the current user's ID pre-filled, and automatically creates an employee if needed during shopfloor operator editing.
Original PR description
In 19.1, the automatic creation of an employee profile for the admin user has been removed. This causes issues when the admin wants to start a workorder or mark it as done, so we added a popup to create a new employee profile with the user_id already filled with the id of the current user. Also, if no employee exist when editing operators in the shopfloor, the popup proposes to directly create a new employee linked to the current user if they have HR access. This new employee will be directly logged in the shopfloor operators. see https://github.com/odoo/odoo/pull/250607 to make `action_create_employee` return an employee record. task 5932500 Forward-Port-Of: odoo/enterprise#107439
This update fixes an issue where worked days were incorrectly calculated for employees with no contract or contracts that didn't fully align with pay periods. The changes ensure accurate attendance and out-of-contract day calculations, particularly for new hires and those with contracts starting or ending mid-month. New tests have been added to verify this fix.
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#109237 Forward-Port-Of: odoo/enterprise#103207
This update resolves an issue where foreign vendor VAT invoices were not correctly identifying the country of origin. The team has implemented a fix to ensure the correct country code is applied to vendor bills, improving accuracy in JPK reports. This ensures proper tax reporting for international suppliers.
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264) Forward-Port-Of: odoo/enterprise#109080
This update resolves a problem that prevented Italian fiscal printers from working correctly. The fix ensures the order is fully synced before printing the ticket, preventing errors related to missing currency information. This improves the reliability of the Italian POS system for businesses.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced. Forward-Port-Of: odoo/enterprise#108144 Forward-Port-Of: odoo/enterprise#106455
A server error occurred when deleting mailings linked to marketing activities. This update corrects a technical issue caused by a change in Odoo's codebase, ensuring users receive a standard error message when attempting to delete mailings that are still in use. This prevents unexpected application crashes and improves the user experience.
Original PR description
How to reproduce ------ 1. Open the Marketing Automation app 2. Create a new campaign 3. Click on Add new activity to create a new activity (in the previously created campagin) 4. Set the Activity…
How to reproduce ------ 1. Open the Marketing Automation app 2. Create a new campaign 3. Click on Add new activity to create a new activity (in the previously created campagin) 4. Set the Activity Type to email 5. In the Mail Template option, select or create a mailing 6. Open the selected/created mailing (using the Templates smart button) 7. Click on the gear icon and then click Delete (either one or multiple together) DEMO: https://www.awesomescreenshot.com/video/50021531?key=18a341a6939e6ff8deb847fc251db570 Current behavior ----- Odoo Server Error is displayed. Expected behavior ------ Normal user error indicating that the mailing(s) being deleted is still linked to an activity (or marketing campaign). Cause ------ When formatting the user error, we used the attribute `name`, to get the mailing's display name, which does not exist in `mailing.mailing` model. Therefore, a KeyError is raised. The `name` attribute was an attribute in a class named `UtmSourceMixin` in the utm module, of which `mailing.mailing` was inheriting. In saas-19.2, that class was removed and hence the `name` is no longer available for `mailing.mailing`. The commit in which the metioned class was removed is: https://github.com/odoo/odoo/commit/93f8bb821ab86612d95d93ae0fdca5a08a12e2d5 (See utm_source.py) Solution ------ Change the `name` to `mailing.display_name`. DEMO: https://www.awesomescreenshot.com/video/50049334?key=a34a525ef38bdf2dc8037f2dcfa68761 task-5999999 Forward-Port-Of: odoo/enterprise#109400