**Steps to reproduce:**
* Install  `stock` module.
* Go to the > Settings*, enable *Packages* and
  *Storage Locations*(warehouse).
* Create a storable product and set *Tracking Inventory* to
  **By Quantity** and set some *barcode*
* Update the on-hand quantity for the product and assign it to one packages.
* Open *Barcode > Operations > Internal Transfer* and create a new
  transfer.
* Click the *gear icon* in the top-right corner to open the barcode
  scanning flow.
* manually enter the created product barcode and apply it.
* Click the **Back** button multiple times in quick succession.
* Go to the backend and open the created internal transfer.

**Observed behavior:**
* The internal transfer is created with *double quantities*
 compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
  `exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
  again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
  duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

 * Prevent rapidly clicking the Back button multiple times
 does not multiply quantities.

---
opw-5375899

Forward-Port-Of: odoo/enterprise#103130

**Steps to reproduce:**
* Install the **product_unspsc** module.
* Create a product with a **UNSPSC category**.
* Create and post an invoice for this product.
* Send the invoice via **Peppol**.

**Observed behavior:**
* Peppol validation fails with error **[BR-CL-13]**: *“Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.”*
* The XML uses `listID='UNSPSC'` in `cbc:ItemClassificationCode`.

**Cause:**
* The `listID` attribute was set to the literal string **'UNSPSC'**.
* According to the **UNCL7143** code list, the correct scheme identifier for UNSPSC is **'TST'**, not 'UNSPSC'.

**Fix:**
* Replace `listID='UNSPSC'` with `listID='TST'` when generating the commodity classification node.
* Update and extend tests to validate the correct scheme identifier.
* Same for CPV code from the documentation i's code is also changed to 'STI'.

ref: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/

opw-5948723

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.


opw-4879481

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#101579