Monday, September 29, 2025
39 changes · saas-18.3
Resolved issues and error corrections
This fixes an issue where custom worksheet templates left behind during a Field Service uninstall could break task setup after reinstalling the app. Custom templates are now removed during uninstall, preventing errors when users assign a worksheet template to a task.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
Support Document Credit Notes in Colombian electronic invoicing now use the required internal reference format for product identification. This prevents DIAN rejection errors when products also have barcodes or UNSPSC codes configured, improving successful submission of these documents.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140This fixes an issue where repeatedly pressing Validate for an online POS payment on a slow network could cause the order validation to fail. The button is now protected until the order has finished syncing, reducing checkout errors and improving reliability for cashiers and customers.
Original PR description
Currently, an error occurs when validating an online payment if the network is slow. **Steps to Reproduce:** 1) Install POS (with demo data) and the Demo Payment module. 2) Go to Payment Methods and…
Currently, an error occurs when validating an online payment if the network is slow.
**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module.
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.
Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')
**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.
**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.
[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17
[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87
[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26
**sentry-6849786792**
Forward-Port-Of: odoo/odoo#227967
Forward-Port-Of: odoo/odoo#225371This fix updates checks around product barcode lookup so product weight is correctly handled when available on the product form. It also corrects test permissions for product variants, helping prevent false failures in automated validation.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so we can't set them. - The variant rights were not passed correctly for the first basic test. After this commit: ----------------------- - We have updated the test and checked that weight is correctly set when present in the view. - Now we have passed the correct variant right for the test. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155 Forward-Port-Of: odoo/enterprise#95590 Forward-Port-Of: odoo/enterprise#93075
Orders paid online from the kiosk are now sent to the preparation display after payment. This prevents paid customer orders from being missed by kitchen staff, improving fulfillment reliability.
Original PR description
Currently, when using online payment with the kiosk. The order is marked as paid in the backedn but never redirected to the kitchen. Steps to reproduce: ------------------- * Create an online payment method (use demo for example) * Change the kiosk settings to use those it * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The following commit is forwarded. It had been stopped before 18.2 since orders were sent to the kitchen before being paid. That behavior was changed again in the next version thus the fix needs to be forwarded as well. https://github.com/odoo/odoo/commit/6d8ec9948f1d0924ca92e2a9492b9882ae3338c0 opw-5096094
This fixes an issue where kiosk orders paid online were confirmed to customers but not sent to the kitchen preparation display. Restaurants using kiosk online payments can now rely on paid orders appearing for preparation as expected.
Original PR description
Currently, when using online payment with the kiosk. The order is marked as paid in the backend but never redirected to the kitchen. Steps to reproduce: ------------------- * Create an online payment method (use demo for example) * Change the kiosk settings to use those it * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The following commit is forwarded. It had been stopped before 18.2 since orders were sent to the kitchen before being paid. That behavior was changed again in the next version thus the fix needs to be forwarded as well. https://github.com/odoo/enterprise/commit/bb25c6226e746f292274c77fa0c05108e6938907 opw-5096094
The bank reconciliation widget now avoids repeating the same date on every transaction line when several entries share a date. This makes the list easier to scan and reduces visual clutter while still showing the date at the start of each date group or statement.
Original PR description
When you have several transactions on the same date, it's not really necessary to repeat the date on each line. It bloats the widget. We will now only show it if it's the first transaction at that date or if it's the first of a statement. task-4749339
Greek VAT numbers that start with the common 'EL' prefix are now treated as Greek VAT numbers during validation. This ensures customer country information is filled correctly in exports such as DATEV accounting files, reducing manual corrections and reporting errors.
Original PR description
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer…
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer from Greece with VAT number EL033910442 2. Create an invoice for that customer 3. Navigate to Accounting > Reporting > General Ledger 4. Download Datev Data through the gear icon 5. Open EXTF_Customer_accounts.csv 6. Notice that EL was not recognised as the country code **Root Cause** The VAT validation logic `simple_vat_check` first tries to find a country-specific check function `check_vat_EL`, but such a function does not exist. For Greece, the correct function is `check_vat_GR` (since the ISO country code is `GR`). When `EL` is passed directly, no check function is found, validation fails, and the VAT country is left empty. **Fix** Normalize the VAT prefix before validation by mapping EL → GR, ensuring Greek VAT numbers prefixed with EL are validated with the existing check_vat_GR logic. Opw-4982164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225422
Field service tasks now use the customer’s assigned pricelist when creating service lines on sales orders. This prevents incorrect default product pricing and helps ensure customers are billed according to their agreed pricing.
Original PR description
Before this commit, the service line on the sale order ignored the customer’s pricelist and used the product’s default price. Steps to reproduce: - Assign a fixed-price pricelist to a customer. - Create an FSM task for them and add a timesheet. - Validate the task and check the service line price. After this commit, the service line correctly reflects the price from the assigned pricelist. task-4830183 Forward-Port-Of: odoo/enterprise#88039
This fixes an issue where email signature formatting could be damaged when messages were prepared for Outlook, especially for resized images. Users should see more consistent email appearance between the chatter composer and full email composer.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224985
Online store carts now keep the correct pricelist when a shopper signs in or creates an account without an address. This prevents customers from being assigned pricing that does not match their detected country, improving pricing accuracy for GeoIP-based eCommerce setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st…
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st pricelist be incompatible w/ the current GeoIP location; 5. open a cart as a public user; 6. check pricelist in back-end (should be correct); 7. go to "Sign In" & create a new portal account without address; 8. check pricelist in back-end (should still be correct); 9. go back to cart with portal account; 10. check pricelist in back-end. Issue ----- The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location. Cause ----- The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`. Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions. Solution -------- Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders. opw-5000198 Forward-Port-Of: odoo/odoo#228909 Forward-Port-Of: odoo/odoo#225582
This fix prevents UBL invoice imports from failing when an imported file contains a zero value for the base quantity. Businesses can now import affected customer invoices without interruption, improving reliability for electronic invoicing workflows.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227446
Point of Sale users can once again print invoice PDFs through connected IoT printers instead of only downloading them. The change restores expected printing behavior after a previous invoice download update and reuses a cleaner printer selection flow.
Original PR description
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself. - **[REF] iot: extract printer select into separate function** Before this commit, the printer…
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.
- **[REF] iot: extract printer select into separate function**
Before this commit, the printer selection wizard was tightly coupled to
the IoT report handler, and the call to send to the printer was
duplicated in the wizard and the handler.
After this commit, the printer selection wizard is contained in a
function that will always return the selected printers directly to the
caller, whether the dialog needs to be opened or not. The wizard is
simplified as a result and the print call always occurs in the handler.
This refactoring will allow other places to use the printer selection
wizard, namely for invoice printing.
- **[FIX] pos_iot: print invoices via IoT**
In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
bypass the `ir.actions.report` model, instead working directly via an
action on the invoice model. A side effect of this is that it broke
printing invoices via the IoT, as it relies on the report printing
action to function.
To fix this, this commit introduces an override in `pos_iot` for the
`account_move_service`, which will print the invoice PDF via the IoT
instead of downloading it directly (if a printer is associated with the
report).
task-5109814
Forward-Port-Of: odoo/enterprise#95616
Forward-Port-Of: odoo/enterprise#95586This fix prevents the website preview from briefly showing old page styling when a page reloads after theme changes. Business users get a smoother editing experience with less visual flicker when updating layouts or background colors.
Original PR description
In this [commit], fallback iframe was added to avoid flickering between iframe reloads. But the flicker still happens if we change page's style, since we do not apply the new styles to the fallback iframe. To reproduce the issue: - Open Website and start editing - Move to the 'Theme' tab - Change page layout to 'Boxed' - Set background color to a non-transparent color, e.g. red - Save, and do any action to reload the iframe, e.g. go to /contactus => The iframe flickers from the previous color to red, which shouldn't be the case. Task-4985472 [commit]: https://github.com/odoo/odoo/commit/7b19831e1c624b483008feb526ba773ec8b23009 Forward-Port-Of: odoo/odoo#221391
Invoice Analysis now calculates product quantity, average price, margin, and inventory value correctly when invoices include packaged products. This prevents misleading reporting for sales and profitability when products are sold by package rather than individual unit.
Original PR description
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost,…
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost, and it differs from sales price - In the sales sheet, add a packaging - Create a sale order - Add the product using the package - Confirm - Go to delivery, validate - Back to sale order create an invoice and confirm it - Go to "Invoice Analysis" - Go to Pivot View - In "Measures" select: - Average Price, - Inventory Value, - Margin, - Product Quantity - In "Total" select: - Product #### Current behavior: - Those fields display wrong values as they were miscalculated: - Average Price line_balance / number_of_packages * number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages / number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages / number_of_unit_in_package - Product Quantity number_of_packages / number_of_unit_in_package #### Expected behavior: - These fields should be right: - Average Price line_balance / number_of_packages / number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages * number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages * number_of_unit_in_package - Product Quantity number_of_packages * number_of_unit_in_package #### Cause of the issue: - As per the refactor of the UoM and packaging, the uom factor field is now the mathematical inverse of the previous uom factor field. This model wasn't updated and used wrong formulas. opw-5031495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227489
Payment terminal messages printed at the bottom of POS receipts now use the correct font size. This makes important payment information easier to read on printed receipts while keeping the on-screen receipt display consistent.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
This fix stops time off requests marked as worked time from appearing as time off entries in timesheets. It keeps timesheet records cleaner and avoids misleading time off reporting for employees and managers.
Original PR description
_______________________________________ ## Short functional explanation of the error When creating a leave of type "worked time", a time off timesheet is generated. ## Reproduction Steps 1. Go to time off. Hit configuration, then time off types. 2. Create a new type of time off. Set the Kind of Time off as Worked Time. Make sure the time off doesn't require allocation. 3. Hit My Time > My Time off. Click on new, and as a time off type, select the one you just created. Save then validate. 4. Go to timesheets and click on the list view. ### Expected behavior As the type of time off is set as Worked Time, it shouldn't appear as time off. It shouldn't appear at all in the timesheets if created from the time off app. ### Unexpected behavior The time off shows in the timesheets as "Time Off". ## Origin of the issue Timesheets were created for each time off request, regardless of their type. _________________________________________ opw-5050838 ---
A test for financial reports now targets the exact report being checked instead of potentially switching to a related variant. This improves confidence in report validation without changing day-to-day product behavior.
Original PR description
the test test_custom_engines_related_groupby needs a slight improvement to target the report it is called with, rather than possible variants of the report. This can be achieved using the key 'no_report_reroute'.
This update fixes a problem where reinstalling the Danish Nemhandel module could leave it broken. It helps businesses using Danish electronic invoicing keep the module reliable during maintenance or reinstallation.
Original PR description
**Description of the issue/feature this PR addresses:** Reinstalling the module breaks it. 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#228747
The barcode Kanban view now only displays existing inventory quantities instead of allowing new ones to be created. This prevents accidental inventory records and helps keep stock data accurate when users scan or enter product barcodes.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#95487 Forward-Port-Of: odoo/enterprise#94802
The Australian TPAR report now excludes unrelated customer payments from the Gross Paid amount. This prevents overstated supplier payment reporting and helps businesses produce more accurate annual taxable payments reports.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95592 Forward-Port-Of: odoo/enterprise#95029
This fix makes Turkish Nilvera e-invoice imports save progress after each document is processed. If an import times out or encounters an error, already imported documents are kept instead of being rolled back, reducing rework and improving reliability for larger batches.
Original PR description
Following bcab79c0ba9b550726164d80a22b50e689a2789c we are no longer committing changes in `_l10n_tr_nilvera_get_documents` as we loop through documents. The idea behind having that commit inside the loop was to avoid having to rollback all changes if we timeout or an error occurs. This is especially important when importing the current maximum amount of documents (30). This commit restores that behavior. No Task ID. Forward-Port-Of: odoo/odoo#228616
The web testing tool now distinguishes between different levels of errors and warnings, so issues are reported with the right urgency. This helps developers see important problems earlier while preventing expected or lower-priority test issues from disrupting test runs unnecessarily.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228674
Resetting a submitted tax return now correctly removes the previously generated tax journal entry and related attachments. This prevents old and new entries from being counted together when the return is submitted again, reducing the risk of incorrect tax amounts.
Original PR description
- Create a journal entry for a period. - In Tax return, submit the tax return for the period. - Reset the tax return (bypassing the lock date): the tax journal entry generated by the tax return is not deleted. - Resubmit the tax return: both the old and the new journal entries are taken into account for the tax return value. Commit https://github.com/odoo/enterprise/commit/123ae45cbc966f6a2c03050899058aff175f92dd (in account_return.py) mistakenly removed the line unlinking the closing move and attachments at reset. We reintroduce them here. opw-4972892
Event registration confirmation emails now keep QR codes at the correct size and proportions after the template is edited or previewed. This prevents stretched QR codes, helping attendees reliably scan their tickets or registration details.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893 Forward-Port-Of: odoo/odoo#223774
Mexican electronic invoices with external trade details can now be sent even if the USD currency has been deactivated. This prevents a blocking error during invoice confirmation and helps businesses complete CFDI invoicing without needing to reactivate an unused currency.
Original PR description
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI…
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI Certificate and activate Testing mode in PAC. 5. Create a new product with "UNSPSC Category". 6. Create an invoice with CFDI to the public and "Definitive" in External Trade. 7. Confirm and send the invoice. **Sample certificate:** Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link Private key password: 12345678a **Error:** `ValueError - Expected singleton: res.currency()` **Cause:** When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation. **Fix:** This commit handles the case when USD currency is deactivated. sentry-6860601127 Forward-Port-Of: odoo/enterprise#94179
Carbon emissions calculations now use the emission factor's unit of measure when converting quantities. This prevents inaccurate emissions values in ESG reporting, improving confidence in sustainability metrics.
Original PR description
Prior to this commit, the UoM conversion in the carbon emissions calculation was done by targeting the UoM of the account move line instead of the UoM of the emission factor. Which led to incorrect emissions values calculations. task-5107685
Users who work across multiple companies can now assign themselves to planning slots in a company where they have an employee record, even if another company is currently active. This prevents silent failures and makes planning assignments work as expected in multi-company setups.
Original PR description
_______________________________________ ## Short functional explanation of the error Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding…
_______________________________________ ## Short functional explanation of the error Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding employee in company_2. If the user selects company_1 and company_2 but keeps company_1 as his current company, and tries to assign himself a task that has been created for company_2, nothing happens. ## Reproduction Steps 1. As an admin, create a user with which you'll be able to log. Make sure that you have at least 2 companies created, and that the user has access to both. Create an employee for that user in company_2. 2. Select both companies. In planning, create a slot for company_2 and publish it. 3. Log in as the user you created. Make sure that the current company is company_1. Select company_2. 4. Go to planning and try to assign yourself to the slot you've just created as an admin ### Expected behavior Either an error message shows, or the employee is assigned to the slot for company_2 (as company_2 is selected). ### Unexpected behavior Nothing happens ## Origin of the issue When the current company isn't the one corresponding to the one the employee is in, even if another company is selected and contains the employee, self.env.user.employee_id is set at False _________________________________________ opw-4963674 ---
The employee form now shows the full count of documents stored in an employee’s folder and all related subfolders, while excluding folders themselves from the total. This gives HR users a more accurate view of available employee documents at a glance.
Original PR description
Before this commit, the documents count on the employee form view showed only the count of documents (folders included) inside the employee folder but not the ones in subfolders. This commit fix that by showing the count of every documents (folders excluded) included in the employee folder or its subfolders. Task-4944895
This fix prevents users from appearing muted unexpectedly when joining a Discuss call and ensures warning indicators remain visible during connection recovery. It improves call reliability and helps users better understand their call status when connection data is refreshed.
Original PR description
This commit fixes: - the SFU could send outdated information about our own session during the initialisation of the connection. This can lead to the microphone being muted when joining a call if the updates occur when the user rtc session is marked as mute when querying the audio stream. - the warning indicator was hidden if the connection state was undefined this could lead to a missing warning during some recovery steps when session data is reset. Forward-Port-Of: odoo/odoo#228811 Forward-Port-Of: odoo/odoo#228601
Fixes an issue where enabling VAT number verification on a non-empty EC Sales List could create duplicate validation checks and cause an error. Businesses can now run the report with VAT verification enabled without interruption.
Original PR description
Create tax return checks for a non-empty EC Sales List report when the option "Verify VAT Numbers" (vat_check_vies) is enabled implies to create 2 checks with the same code (check_partner_vies). This is forbidden and raises a traceback. opw-5079474 opw-5090602 opw-5094853 opw-5103611
This fixes a display issue where product carousel indicators could appear left-aligned on mobile when a page first loaded. The change keeps the carousel controls centered immediately, improving the shopping page experience for mobile visitors.
Original PR description
Since the introduction of interactions with [22e777c] in 18.2, the indicators on the CarouselProduct interaction were wrongly computed on mobile: on page load, the indicators appeared on the left instead of centered. This is because an explicit `updateContent()` has to be done at the end of the `updateJustifyContent` method, since it modifies a parameter that impacts the `dynamicContent`. We also take the opportunity to simplify the code of `updateJustifyContent`, which became needlessly complicated after [22e777c]. [22e777c]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba task-5080057 Forward-Port-Of: odoo/odoo#226632
Printed invoices now show the early payment discount amount after applying cash rounding. This prevents customers from seeing a slightly incorrect amount due when both early payment discounts and cash rounding are used.
Original PR description
**Steps to reproduce** - Create a tax of 8.1% - Activate and create a cash rounding with rounding precision 0.05 - Use the existing '2/7 Net 30' payment term (or create a new 2% early discount one) - Create a new invoice: - Add payment terms - Add cash rounding method - Add line with price 50, 8.1% tax - Invoice total will be 54.05 **Issue** Print the invoice: The invoice will show "$ 52.97 due if paid before 09/12/2025" However 52.97 is the amount with just the 2% early payment discount applied With cash rounding applied, it should display 52.95 This occurs because when retrieving the amount from the invoice template the system applies only the early payment discount opw-4914545 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4914545) Forward-Port-Of: odoo/odoo#228677 Forward-Port-Of: odoo/odoo#225759
Google Calendar account resets now apply the same safeguard to all related calendar event updates. This prevents reset operations from failing unexpectedly because of event permission checks, making account reconnection and cleanup more reliable for users.
Original PR description
This commit adds the last context key "skip_event_permission" to the remaining writes done to `calendar.event` records at the reset of google_calendar account, created at odoo/odoo#227991. By adding it, we'll no longer face any possibility of triggering a ValidationError during account resets of google_calendar. task-5103918 Forward-Port-Of: odoo/odoo#228520
The Spanish Mod 349 tax report now correctly displays the underlying invoice details when users audit the summary line for intra-EU operations. This helps accounting teams verify reported amounts more easily and avoid confusion during tax report review.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
This fix prevents users from creating or keeping unsupported account types in ESG emission factor assignments. It helps keep ESG reporting data consistent by warning users before account type changes and cleaning up affected assignment lines or journal item emission factors when needed.
Original PR description
Before this PR, it was possible to create on the fly an account from the assignation lines list view of another type than "Expense" or "Fixed Assets". This is not desired, as this type of account is not part of the domain of the `account_id` field of the `esg.emission.factor.line` model. We prevent creation of such accounts from ESG in general, to avoid confusion and ensure data integrity. Moreover, when changing the account type of an existing account, if this one is changed to a type other than "Expense" or "Fixed Assets", we verify if there are some assignation lines linked to this account and/or journal items linked to that account. If so, we raise a warning to the user and if he wants to proceed, we remove the assignation lines linked to this account and remove the emission factors of journal entries linked to that account. task-4859806
Closed point-of-sale self-order sessions now remove their temporary database sequence when it is no longer needed. This helps prevent unnecessary database clutter over time and supports smoother system maintenance.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228813 Forward-Port-Of: odoo/odoo#223758
Nuvei payments no longer fail when a customer has a first or last name longer than Nuvei allows. Odoo now shortens those names before sending the payment request, helping customers complete sales order payments successfully.
Original PR description
Steps: - Install sales and payment Nuvei. - Set up payment Nuvei. - Set customer long name and last name. - Try to pay that SO with Nuvei. Issue: - Error. Cause: - Nuvei only accept 30 character for first_name and 40 for last name Fix: - Truncate first and last name to only take required character. opw-5083827
The partner ledger now keeps names and expand arrows properly aligned on phones and tablets. This makes financial reports easier to read and use on smaller screens.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317