Monday, September 29, 2025
30 changes · saas-18.4
Enhancements to existing features
Hong Kong Payroll users can now download the IR56B report as an XML file directly from the relevant payroll screens. This makes statutory reporting preparation easier by reducing manual steps to retrieve the required file.
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 orders now create required quality checks much faster when many quality rules exist. This reduces long delays or timeouts in large databases, improving day-to-day repair processing performance.
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 e-invoice imports now keep the document type from supplier bill XML without relying on whether the entry is an incoming or outgoing invoice. This reduces duplicate document type records and helps imported invoices be classified more consistently.
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
Restaurant point-of-sale users can now retry kitchen receipt printing when a printer issue occurs. The retry only sends the receipt to printers that failed previously, avoiding duplicate prints from printers that already succeeded.
Original PR description
Before this commit: = - There was no option to retry printing kitchen receipts if a printer failed. After this commit: = - Users can now manually retry printing kitchen receipts that failed due to printer issues. - The `Retry` button targets only the printers that previously failed, ensuring other successful prints are not repeated. Task: 4717776 Forward-Port-Of: odoo/odoo#206432
EPSON receipt printer setup can now derive the secure printer address from the printer serial number when no IP address or URL is provided. This makes configuration easier for businesses using EPSON's Automatic Certificate Update option and helps support HTTPS connections without manual address entry.
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 fix prevents Field Service tasks from failing when a previously created worksheet template remains after the app is uninstalled and reinstalled. User-created worksheet templates are now cleaned up during uninstall, avoiding broken template references and improving reliability for teams using worksheets.
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
This fix stops cashiers from repeatedly pressing Validate while an online payment order is still syncing on slow networks. It prevents payment validation errors and makes point-of-sale checkout more reliable when connectivity is poor.
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#225371Support Document Credit Notes in Colombian electronic invoicing now use the required internal reference identification format, avoiding DIAN rejection errors. This helps businesses submit these credit notes successfully even when product barcodes or UNSPSC codes are configured.
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#94140Employees and contract templates using a working schedule now require Working Hours before saving. This prevents errors in employee forms and version lists, helping HR teams keep work entry data complete and reliable.
Original PR description
#### Steps to Reproduce 1. Go to Employees. 2. Select an employee with Work Entry Source = "Working Schedule". 3. Clear the "Working Hours" field. 4. Try to save. #### Issues Fixed - Traceback in employee version list view (`hr.version`) when "Working Hours" is empty for calendar-based employees. - Traceback in employee form view when saving without a working schedule for a calendar-based employee. - Resource Calendar (`resource_calendar_id`) is now required conditionally in: * Employee form view * Contract template form view * Version list view #### Fix Made `resource_calendar_id` required conditionally in the inherited `hr.employee`, `hr_contract_template` and `hr.version` views and added a placeholder. task-5068798
Invoice and report lines now show both the product name and the added description instead of replacing the product name with the description. This helps customers and staff identify billed items more clearly on printed documents.
Original PR description
Step to reproduce: - install account - create a invoice with any product - add description - print any report Observation: - We see that only description is printed, not the name of product in…
Step to reproduce: - install account - create a invoice with any product - add description - print any report Observation: - We see that only description is printed, not the name of product in description column of report Expected: - The name and description, both should be printed Cause: - the `ProductNameAndDescriptionField` component is introduced in [1] sets label as only description or product name, instead of including it both if they are available https://github.com/odoo/odoo/blob/f74cdf84ffbaccea2fbf03bfb17a9e7bfcaae524/addons/product/static/src/product_name_and_description/product_name_and_description.js#L131-L136 Fix: - we fix the `updateLabel` method for `ProductNameAndDescriptionField` to get the expected outcome i.e `productname+\n+description` Before: <img width="297" height="175" alt="image" src="https://github.com/user-attachments/assets/803b53ce-c031-4192-874c-11ebfd8c7e9b" /> After: <img width="281" height="184" alt="image" src="https://github.com/user-attachments/assets/0dce4f67-94bf-42f2-bf09-c03a07c800d0" /> [1]: https://github.com/odoo/odoo/commit/7e553d25890d1e236123f0fa7e11ce86f59448ab opw-5063048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where an online order could switch to the wrong pricelist after a shopper created an account without an address. The website now keeps using the shopper's detected country when recalculating prices, helping ensure country-specific pricing remains accurate.
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
Rental orders can now be confirmed even if a planned resource is unavailable, as long as rental-to-shift synchronization is turned off. This prevents unnecessary blocking in the portal and rental app for businesses that do not use shift synchronization.
Original PR description
Step to reproduce: - Set up a role with a resource not available this week - Not activate the option to sync Rental order - Shift - Set up a rental-service product, with an auto-plan for this role Issue: - Rental orders could not be confirmed from the portal or the rental app if the required resource was unavailable, even when the `sync_shift_rental` option was not disabled. Cause: - The logic in `_planning_slot_vals_list_per_sol` treated all unavailable resources as problematic, without checking whether the shift synchronization was enabled (`sync_shift_rental`), resulting in unnecessary blocking of the order confirmation. Solution: - Added a condition to check if `sync_shift_rental` is enabled before marking a service as problematic. This allows rental orders to be confirmed when shift sync is disabled. task-5072920
This fixes a rounding mismatch in Mexican electronic invoice validation, where Odoo calculated totals with more precision than the XML validation expected. The change helps prevent valid invoices from being rejected due to tiny decimal differences.
Original PR description
The validation in the XML are made based on values rounded to 6 digits. However in Odoo, we do the computation without any rounding. 352.2413793103448 + 876.7435344827586 + 162.92327586206898 + 198.73706896551727 + 526.0383620689655 + 17.241379310344826 = 2133.925 ~= 2133.93 352.241379 + 876.743534 + 162.923276 + 198.737069 + 526.038362 + 17.241379 = 2133.924999 ~= 2133.92 != 2133.93 opw-5096249 Forward-Port-Of: odoo/enterprise#95413
Invoice Analysis now calculates product quantities, average prices, margins, and inventory values correctly when invoices include packaged products. This helps businesses rely on accurate reporting for sales performance, profitability, and stock valuation after the unit-of-measure packaging changes.
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
Point of Sale kitchen and preparation tickets now handle order notes consistently across multiple printers. This prevents printing failures caused by different note formats, helping restaurant staff receive complete tickets without interruption.
Original PR description
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers. Steps to reproduce:…
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers.
Steps to reproduce:
-------------------
* Configure two preparation printers for a pos_restaurant with food categorie.
* Create an order with a note in that restaurant.
* Send the order to the kitchen.
> Observation:
The second printer fails to print the ticket with an (uncaught) JSON parse error (Unexpected token), while the first prints correctly.
Why the fix:
------------
`getStrNotes()` assumed notes were always JSON strings like [{"text":"...","colorIndex":0}]. In practice, notes can be plain strings or already-parsed arrays depending on the update path and last printed changes.
The function now:
- returns joined texts for arrays,
- tries to parse JSON strings and joins texts if it’s an array,
- falls back to the raw string if parsing fails. This makes note rendering stable across printers and prevents the error, ensuring tickets are printed consistently.
opw-5029870
Forward-Port-Of: odoo/odoo#227430The Time Off calendar now shows the selected employee's working schedule instead of the schedule of the person viewing it. This prevents incorrect day-off visibility when managers or HR users review employees with different work patterns.
Original PR description
Steps to reproduce: - In the Employee app, select an employee with a different working schedule than yours - Click on the "Time Off" smartbutton - Switch from Kanban to Calendar view - The displayed working schedule is yours and not the employee's (easier to see if you and the employee have different days off) Reason: The employee_id field in the context used by the Python method was null instead of an ID, which caused the Python method to default to not use the employee's working schedule but the working schedule of the user viewing it. How it was fixed: By using a different field already present in the context, the employee's ID is correctly retrieved and used to display the calendar. Task ID: 4987732 Forward-Port-Of: odoo/odoo#225839
Turkish Nilvera e-invoice imports now save progress after each document is processed. This reduces the chance of losing all imported documents if a timeout or error occurs during larger imports.
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
This fixes a restaurant point of sale issue where newly added items could appear saved but not be fully synced before being sent to the kitchen printer or preparation display. Staff should no longer encounter the "Order Outdated" error in this workflow, reducing ordering disruptions and inconsistencies.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228680 Forward-Port-Of: odoo/odoo#227824
The Australian Taxable Payments Annual Report now calculates gross paid amounts without incorrectly including customer payments. This helps businesses report supplier taxable payments more accurately and avoid overstating TPAR figures.
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 prevents Mexican electronic invoices with external trade details from failing when the USD currency has been deactivated. Businesses can continue confirming and sending affected CFDI invoices without needing to manually reactivate USD first.
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
This fix makes call status indicators more reliable when joining or recovering a discussion call. It prevents outdated session information from incorrectly muting a user's microphone and ensures warning indicators remain visible when connection data is temporarily reset.
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
This update fixes invoice printing for Point of Sale setups that use IoT-connected printers. When an invoice printer is configured, invoices are now sent to the printer instead of only being downloaded, helping cashier workflows continue as expected.
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#95586Sign requests opened from a record's chatter now show their related documents in the download menu. This prevents users from seeing an empty download dropdown and ensures they can access the correct signed documents regardless of how they open the request.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign request from 'request signature' activity. - From the chatter of the related record, open the sign request. - It will redirect to form view of that sign request. - click on download dropdown button. Before: - The download dropdown was empty. - This happened because the 'sign_request_documents_dropdown' widget tried to use 'active_id' from the context, but 'active_id' was missing when the sign request was opened from chatter. After: - The download dropdown correctly shows the related documents. - When active_id is not in the context, the widget now uses the sign request id from evalcontext, so it can fetch the right documents. Impact: - Users will always see the correct documents in the download dropdown, even when opening a sign request from chatter. task-5089829
Printed invoices now show the correct early-payment amount when both an early payment discount and cash rounding are applied. This prevents customers from seeing a slightly incorrect amount due on invoice documents.
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
Self-service and kiosk orders paid online will now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring confirmed orders reach the preparation screen even when customers leave through the payment portal.
Original PR description
pos_*= pos_online_payment, pos_online_payment_self_order, pos_self_order Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Enterprise PR: https://github.com/odoo/enterprise/pull/95312 Backport of https://github.com/odoo/odoo/pull/213493, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228687 Forward-Port-Of: odoo/odoo#228189
Orders placed through self-service or kiosk online payment now wait for payment confirmation before appearing on the preparation display. This prevents staff from preparing unpaid orders while still ensuring confirmed orders are sent correctly, including when customers leave via the payment portal exit flow.
Original PR description
pos_*= pos_online_payment_self_order_preparation_display, pos_self_order_iot Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Community PR: https://github.com/odoo/enterprise/pull/87173 Backport of https://github.com/odoo/odoo/pull/87173, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal Forward-Port-Of: odoo/enterprise#95583 Forward-Port-Of: odoo/enterprise#95312
Creating a related monetary field in Studio now also creates a linked currency field, so the monetary value remains usable and consistent. This prevents business data entry and reporting issues caused by amounts without a proper currency reference.
Original PR description
Before this commit, when creating a related field to a monetary, the created currency field was not stored and not related either, so the monetary was unusable. This was because of 5cf5a35a0a8f78655989009d0eddcf39f8430965 , b177b058be1531c3d2af2b591c22591c19240d33 and in general the changes in read_group that largely improve the situation. After this commit, we create a currency field related to the currency field of the related monetary to ensure that the monetary's value is coherent. This is made possible by the above mentionned improvements in read_group opw-5094619
Scanning a loyalty card barcode in Point of Sale now correctly selects the customer linked to that card instead of showing an invalid code error. This helps cashiers apply loyalty benefits smoothly and reduces checkout friction.
Original PR description
When scanning the barcode of a loyalty card, there was an error saying the code is invalid. Instead it should select the partner linked to the card if there is one. Steps to reproduce: ------------------- * Create a loyalty program, and a loyalty card with a partner * Copy the barcode of the loyalty card * Open the POS, and scan the barcode of the loyalty card > Observation: The error "Invalid code" appears, and the partner is not selected opw-4653983 Forward-Port-Of: odoo/odoo#215894 Forward-Port-Of: odoo/odoo#213831
Carbon emissions are now calculated using the unit of measure from the emission factor rather than the invoice line. This prevents inaccurate emissions figures and improves the reliability of ESG reporting.
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 Forward-Port-Of: odoo/enterprise#95468
This fixes an issue in the mail module where replacing one item in a related record list could accidentally remove another item. The change helps keep message-related lists consistent and prevents unexpected data loss in affected workflows.
Original PR description
Before this commit, when doing an indexed assignment (`array[index] = record`) on a Many field, it produces an incorrect result where an extra element of the record list would be deleted. This happens because we call a high-level delete on the inverse record before replacing the record, causing the list to shrink in size and causing the indexed assignment to replace the wrong record. This commit fixes the issue by changing the order of the assignment and deletion. fixes task-5090802