Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input.

**Steps to Reproduce:**
1. Install the `hr_payroll_sale_commission` module.
2. Create a user and link to an employee. Set a contract for the employee.
3. Create two commission plans for the same user:
   - Use the same Payslip Input in both plans.
   - Set the Target Frequency to "Monthly" for both.
4. Generate a payslip for the employee.

Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing)

**Error:**
`ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)`

**Cause:**
When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion.

**Fix:**
This commit ensures the currency conversion is applied per commission and prevents the singleton error.

sentry-7187854690

Forward-Port-Of: odoo/enterprise#104464

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with the 'once per order' enabled, the values should be used and propagated directly on the created event.registration records, with precedence over other answers given to individual questions (not once per order)

STEPS
=====

1. Create a new event with name, email questions, once per order ticked.
2. Go to POS (reload data if needed)
3. Register and answer both questions
4. Continue the pos flow until both registrations are created
5. Go to backend > your event > registrations
6. You can see that even if the answers are propagated in the o2m field registration_answer_ids, which is expected, the attendee's name and attendee's email fields are empty. They should contain the values of step 3.

FIX
===

Align the website_event flow and precedence of OPO questions over
individual answers in pos_event. Now, the first non-null answer of an OPO
question will be used for each of the question_type values listed above,
if any, over answers to individual questions.

Also align the fact that after OPO answers, precedence should be given
to the first non-null answer to a given question type for identification
questions, and not the last as it is currently.

Task-4919080

Forward-Port-Of: odoo/odoo#231502

Link to Avalara (Avatax) documentation:
https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/

Expected Behaviour:
The itemCode sent to the AvaTax API should be 50 characters or fewer
to comply with Avalara's field length constraints.

Actual Behaviour before the Fix:
When an itemCode exceeded 50 characters, the system attempted to send
the request as-is. This resulted in the AvaTax API returning an error,
causing the transaction or tax calculation to fail.

Behaviour with the Fix:
The system now ensures that the itemCode adheres to the 50-character
limit before the API call is made, by trancating the code to the
first 50 characters if it exceeds 50 characters. This prevents API
rejection and ensures successful tax processing for items with
long identifiers.

Steps to reproduce:
1. Create or select a product/item with a reference (or barcode if
   using UPC) longer than 50 characters.
2. Trigger an action that calculates tax via the AvaTax
   integration (e.g., creating an invoice or updating a line item).
3. Observe the API response.

- Before fix: API returns a validation error regarding the
  itemCode length.
- After fix: Request is successful as the itemCode is
  properly handled/validated.

opw-5406451

Forward-Port-Of: odoo/enterprise#105017

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Journal Entry** in mobile view.
* Add a **Journal Item**, opening it in a form dialog.
* Select a tax in the **Taxes Applied** field.
* Click on the **Save and close** button.

**Observed behavior:**
* The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`.

**Cause:**
* The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected.
* When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`.

**Fix:**
* Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form.
* Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it.

**Note:**
* The crash happens when `autosave_many2many_tags` calls
  `model.root.save()` on a **new** `account.move` from within a dialog.
* In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936)
  in-memory and does not trigger form reloads or component destruction.
* As a result, the crash cannot be reproduced in tests.




opw-5497342

Forward-Port-Of: odoo/odoo#246638
Forward-Port-Of: odoo/odoo#246084

Configuration:
-------------------------
- Restaurant Mode
- Self-Order Mode: “QR + Ordering”
- Service At: Table (Online Payment)

--------------------------------------------------------------------------------
Issue 1: Extra Order word print in KOT
---------------------

Steps to Reproduce:
1. Make an order using Self Order (QR).
2. Configure and enable the Kitchen Printer.
3. Check the KOT print it shows “Order Self-Order T2”.

Cause:
- The QWeb template always prefixed “Order” regardless of order type.

Fix:
- Added a condition to skip the “Order” label for self-order references:

--------------------------------------------------------------------------------

Issue 2: “Send To Kitchen” Button Visible even order in kitchen
---------------
Steps to Reproduce:
1. Open the Restaurant
2. Place a order from mobile menu and select a table.
3. In the Restaurant UI:
   - Open that table. The "Send To Kitchen" button is still visible even
     though the order was already sent to the kitchen and printed.

Cause:
- In self-order mode  the order is not automatically synced after being sent to
  the kitchen and print.
- As a result, the system still treats it as unsent, leaving the Order button
  visible.

Fix:
- Synced the order state after sending it to the kitchen.
----------------------------------------------------

Task-5106704