Steps to reproduce the bug:
- unarchive the subcontracting route
- Create a storable product C1 with the following route:
    - Buy + Resupply Subcontractor on Order
- Create a storable product P1 with:
    - BoM type: Subcontracting - Type: subcontracting - Subcontractor: Azure Interior - Component: C1

- Create a purchase order for 20 units of P1
- Confirm the purchase order
- Validate the resupply transfer
- Go to the receipt of P1
- Record 19.8 units of the component (ignore the remaining 0.2)
- Validate the receipt with no backorder

Problem:
A user error is raised:
```
The operation cannot be completed: The quantity to produce must
be positive!
```

When clicking No Backorder, the `process_cancel_backorder`  method is
called:

https://github.com/odoo/odoo/blob/18.0/addons/stock/wizard/stock_backorder_confirmation.py#L75-L77

This triggers the validation of the picking, so updates the subcontract
order quantity:

https://github.com/odoo/odoo/blob/16a1d9b19b8b07435a9c4b4db2cad3c1e37e4e17/addons/mrp_subcontracting/models/stock_picking.py#L53

At this stage, we check whether it should reduce the MO quantity or
cancel the order entirely. However, the logic compares the quantity to
remove against the initial order quantity without using `float_compare`,
which leads to minor rounding differences. This results to update the
MO quantity to zero instead of canceling it, which then triggers an SQL
constraint error because the MO quantity cannot be zero:

https://github.com/odoo/odoo/blob/e7e2a088495eed3c2886a69054af689c01628f32/addons/mrp_subcontracting/models/stock_move.py#L304-L311

https://github.com/odoo/odoo/blob/29d1f637d3ec6f3ebb218d103001a6182af1b8a4/addons/mrp/models/mrp_bom.py#L93-L95

opw-4905031

Forward-Port-Of: odoo/odoo#221273
Forward-Port-Of: odoo/odoo#219650

Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report

For products using multi-step delivery routes, the `_compute_quantities_dict()` method incorrectly treated internal moves as outgoing moves As a result, the same outgoing quantity was added multiple times, leading to an overestimation of the available stock

This commit adds a filter to the `domain_move_out_done` domain used for past dates, excluding internal moves based on `location_dest_usage``

## Steps to reproduce:
- Create a new product
- Active the multi-step routes in Settings
- Set the Warehouse's Outgoing Shipments to Pick, Pack, then Deliver
- Create a RFQ for 100 products and Receive Products
- Create a Quotation for 20 products
- Validate each delivery steps
- Go to Inventory -> Report -> Stock
- Click on Inventory At
- Set the date to 2025-01-01
- Search for your product
- The `In Hand` quantity should be 0 but is 40 before the fix

opw-4848473

Issue:
currently, when a user initiates applying a promo code but then discards
it before completing the process. the system still marks the
code as used,

https://github.com/odoo/odoo/blob/204eb9b0737634826c4666f85d0b9d39aeed0ee6/addons/sale_loyalty/models/sale_order.py#L1378-L1379

resulting in a false-positive validation on subsequent attempts
https://github.com/odoo/odoo/blob/204eb9b0737634826c4666f85d0b9d39aeed0ee6/addons/sale_loyalty/models/sale_order.py#L1352-L1355

to reapply the same code.

Steps to reproduce:
- Create a record in "Discount & Loyalty"
- select "Discount Code" in program type field.
- From the conditional rules, copy the discount code.
- Create a sale order and select a product.
- Click on Coupon Code button and paste the code copied in step 3 in Coupon Code
 field.
- Click Apply.
- A wizard of Available Rewards will be opened. Now click the Discard button.
- Repeat last 3 steps

Observation:
- It gives a Validation Error: "This promo code is already applied."

Fix:
- we introduce action_discard() method, which will un-use the coupon , in case user discard the reward dialog box.

opw-4961738

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Issue:
When the "Lock Confirmed Sales" setting is enabled, adding a product to a Field Service task would lock the associated sales order before its picking could be created. The confirmation process locks the order first , and the subsequent step to create stock moves (`_action_launch_stock_rule`) explicitly skips locked orders.

Reproducible on 17.0~master
[Task](https://www.odoo.com/odoo/action-4043/4633977)
Odoo 17:
https://drive.google.com/file/d/1qmAYhSu6gU91efuJEDF-Irn2cLGUQP0A/view?usp=drivesdk

Odoo 18:
https://drive.google.com/file/d/1x8IeXwT7ZFM7Av9Vp6GSvGIbOaEGfmVx/view?usp=drivesdk


Steps to reproduce:
1. In Sales > Configuration > Settings, enable "Lock Confirmed Sales".
2. Go to a Field Service task.
3. In the kanban view via the "Products" smart button, add a product.
4. Come back to the task, refresh the browser, open the linked Sales Order from the smart button.
5. **Before this fix:** The SO is locked, no picking is created, and SO lines will have delivered_qty set even though we haven't delivered anything.
6. **After this fix:** The SO is not locked, and a Delivery smart button is correctly displayed, linking to the generated picking.

This behavior left the sales order in an inconsistent state: it was locked, but had no corresponding delivery order. As a result, users were blocked from removing or modifying the products added to the task, as the system prevented edits on a locked order with no picking to cancel.

Let's step through what's going on here;

0. We enable "Lock Confirmed Sales" option.
1. Add a product to the Field Service(FS) task https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L19-L42
https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L38
2. set_fsm_quantity() is invoked, which will create a SO for the FS task https://github.com/odoo/enterprise/blob/35e1f47160d5840e8701fc0ad43ec42bbfaf9e36/industry_fsm_sale/models/product_product.py#L144
3. `_fsm_create_sale_order()` will immediately `action_confirm()` the new SO, because of the reasons in the function description. 
( Since we are immediately confirming newly created SO, I think we should consider not applying the "Lock Confirmed Orders" option to FSM SOs.)
https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L124-L134 https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L134
4. `odoo/addons/sale/models/sale_order.py/action_confirm()` will lock SO because we enabled 'Lock Confirmed Sales'
https://github.com/odoo/odoo/blob/863c064fd911cb4eeedad0abec82adb4690128f6/addons/sale/models/sale_order.py#L964
6. `_action_launch_stock_rule()` is invoked, is in charge of creating Pickings for SOs 
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L303
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L343-L344
7. But, since `line.order_id.locked` , the system do not create Pickings for the SOs. https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L315-L316
The line was introduced by
https://github.com/odoo/odoo/commit/17bece3e797913bcba8dd7e07fc8541c0a45e3f7

This commit resolves the issue by passing a context key `fsm_create_sale_order=True` when confirming a sales order that is being created from a Field Service task. The `_should_be_locked` method on the sale order is overridden to check for this context key. If the key is present, it prevents the order from being locked within that specific transaction, allowing the stock rules to execute correctly and create the necessary picking. The order will be locked for any subsequent operations as intended.

Tradeoff here;
We are sacrificing the universal application of one feature (automatic lock on confirmed sales order) to fix a critical bug that makes the entire FSM delivery process unusable.

---
EDIT: 
Without this change, all of [test_fsm_stock](https://github.com/odoo/enterprise/blob/17.0/industry_fsm_stock/tests/test_fsm_stock.py)'s test cases that use `_fsm_ensure_sale_order()` will fail if the setting is on. (around ~20 test cases). 

[In the past, similar issue occurred for Subscription Orders, and the PO confirmed that the "Lock Confirmed Order" setting should never affect the subscriptions. ](https://github.com/odoo/enterprise/commit/e4f9d76c0a58f3cc226a2372f3936cea4547312e). This commit takes the same approach to ignore the setting upon SO confirmation. 

opw-4633977
opw-4749653
opw-4880664

Forward-Port-Of: odoo/enterprise#88855

When importing a winbooks file the following issues and or inconsistencies may be found

**Issue 1**
We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80

*Note*
Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines

**Issue 2**
Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal

**Issue 3**
Account created during import may be marked for deprecation, which occurs at the end of the import process.
However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error.
https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028

opw-4850314

Issue
-----
On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu.

Steps to reproduce
-----
- Open barcode
- Click the center scan button
- Scan a barcode

--> Traceback

Discussion
-----
There are 2 issues occuring here.

1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value

This means that when we do

https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37

We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy.

To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail:

https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46

2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors.

-----
Ticket:
opw-4820022

**Issue**:
The expiration date displayed in the barcode app's scan screen may appear incorrect.

**Steps to reproduce**:

- Go to Settings > Inventory, and enable the `Expiration Date` field
- Open the Purchase app
- Create a new Request For Quotation
- Select a product that:
	- is a good tracked by lot
	- has the `Expiration Date` field enabled (Inventory tab > Traceability)
- Confirm the RFQ
- Click the `Receipt` smart button
- Click the `hamburger button` and enter an expiration date at midnight.
- Go to the Barcode application > Operation > Receipts
- Open the corresponding RFQ
- Click Edit and increase the quantity to 1, then Validate
- Observe that the date is displayed as one day earlier

**Cause**:
The code https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L17 assumes that the date is encoded using the local while the date comes from the server https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L13, and thus is utc encoded. So for example, if the user's timezone is `Europe/Brussels`, a midnight timestamp will appear as 10 PM the previous day.

**Solution**:
To solve this issue, use this method https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L619-L622 instead of https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L514-L516. This way, it would parse the utc-base server date as a utc-base date.

opw-4865513

Forward-Port-Of: odoo/enterprise#88526