Monday, September 29, 2025
23 changes · saas-18.3
Enhancements to existing features
Hong Kong Payroll now includes a button to download IR56B report files in XML format. This makes it easier for payroll teams to retrieve the required tax reporting file directly from the relevant report screen.
Original PR description
Add ir56b report download button for downloading .xml file in Hong Kong Payroll. task - 5081474 Forward-Port-Of: odoo/enterprise#95294 Forward-Port-Of: odoo/enterprise#95013
Repair creation is now faster when many quality rules are present. The change moves heavy matching work to the database and avoids oversized queries, reducing long delays or timeouts for large quality setups.
Original PR description
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when…
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when processing linear the records to compute the intersection between the all points and the points that should be associated with the repair. This commit rewrites `_create_quality_checks_for_repair` to use a `search` instead if necessary, to offload the intersection search in the database. We also split the ids to not inject a large list of ids in the query. Benchmark --------- For a database that will have 500k `quality.point` that satisfies the domain of `quality.point._get_domain`, the invocation of `_create_quality_checks_for_repair` for creating a Repair takes (excluding the `create` call time): | | Before | After | |---------|------------------|-------| | Timings | Timeout (15+min) | 1 min | Reference --------- opw-4980036 Forward-Port-Of: odoo/enterprise#95631 Forward-Port-Of: odoo/enterprise#91729
Italian electronic invoices now keep the document type from imported XML without relying on whether the entry is a customer invoice or vendor bill. This reduces duplicate document type records and helps imported invoices be classified more accurately.
Original PR description
In the FatturaPA XML, the Document Type (Tipo Documento) doesn't indicate the direction of the journal entry. A `TD01` can be an `in_invoice` or `out_invoice` depending on whether the company is set to be the seller or the buyer. That's what we consider when importing invoices from the EDI. - saved the `l10n_it_document_type` from the imported bills' XML - removed the filter in the view - removed the `l10n_it_document_type` duplicates that just differed by `l10n_it_document_type.type` - updated the invoices to point to the original `l10n_it_document_type` if there were duplicates We will have to remove the field in `master` See odoo/upgrade#8484 Forward-Port-Of: odoo/odoo#228802 Forward-Port-Of: odoo/odoo#225425
Point of Sale Epson printer settings can now use a printer serial number to automatically compute the secure certificate domain. This makes HTTPS printer configuration simpler and reduces the need to manually enter an IP address or URL.
Original PR description
On EPSON printers, we can enable an option ('Automatic Certificate Update') to get a certified (https) url resolving to the ip address of the printer. This domain is computed based on the serial number of the printer.
We updated the configuration to compute the domain if a serial number has been provided instead of an IP address or an url.
Task: 4384790
Forward-Port-Of: odoo/odoo#228844
Forward-Port-Of: odoo/odoo#228710Resolved 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#225371Orders 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
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
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
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#95586Invoice 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
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 ---
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
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
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 ---
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 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