`*` = `ewaybill_Stock, sale_stock, purchase_stock`

**Steps to reproduce:**
* Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`.
* Set the Default Tax Price Setting to "Tax Included".
* Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order.
* Generate an E-Way Bill from the Delivery Challan.

**Observed behavior:**
* The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON.
* The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it.

**Cause:**
* `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped.
* `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24).

**Fix:**
* Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before.

opw-6273101

Forward-Port-Of: odoo/odoo#271492
Forward-Port-Of: odoo/odoo#268504

When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db.

**Steps to reproduce**

* In settings activate:
  - Lots & Serial Numbers
  - Units of Measure & Packagings
  - Storage Locations
  - Barcode Scanner : GS1 nomenclature
* Create a Product tracked by lot with
  - barcode: 00001234567895
* Add on hand quantity:
  - 100 kg in lot : 10002002303-4
  - 100 kg in lot : 11002002303-4
* Go to barcode>Operation>Internal Transfer>New
* Scan 02000012345678951010002002303-4#3100000100 meaning:
  - 02 following 14 characters are the product barcode
  - 10 following characters are the lot number
  - "#" separator
  - 3100: means the units are kilograms, 
  - 00100 means 100 units. 

-> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot)

**Observation**

When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717

- First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14
- Check if the data is in the cache, if not, set it to retrieve after
- Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search:
https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 
-> Since our barcode start with a 10, it will erase it, which lead to a miss in the search.


It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298

opw-6207120

Forward-Port-Of: odoo/enterprise#118828

**Steps to reproduce:**
- Create a database in version 19.0 and install Point of Sale.
- Create a sequence with a prefix or suffix using placeholders like %(year)s.
- Assign this sequence to a POS configuration.
- Create a new POS order and confirm payment.

**Issue:**
- POS order `sequence_number` must be an integer, but when using dynamic prefixes/suffixes (e.g., %(year)s), `_next()` returns values like `POS/2026/` while the configured prefix remains `%(year)s`.
- Due to this mismatch, [`_update_sequence_number`](https://github.com/odoo/odoo/blob/ab6cfabf0086afced2d035eb2207a0acab655540/addons/point_of_sale/models/pos_order.py#L561) fails to correctly remove the prefix/suffix.
- The root cause is that placeholders such as `%(year)s` are not interpolated before applying prefix/suffix removal logic, causing string mismatch and failure in extracting the numeric part.<img width="1920" height="959" alt="image" src="https://github.com/user-attachments/assets/d331fb7a-3c0f-4e34-a33e-6ec906be77bb" />

**Solution:**
- Interpolate prefix and suffix before removing them from the generated sequence.
- Convert placeholders like %(year)s into actual values (e.g., 2026).
- Then apply prefix/suffix removal logic.

opw-6150204

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

Forward-Port-Of: odoo/odoo#262427

Steps to reproduce:

- Create a storable product with a BoM, routes MTO + Manufacturing,
  costing method FIFO + Perpetual (at invoicing)
- Confirm a sale order for 1 unit → a manufacturing order is created
- Set a Delivery Date on the SO (Other Info tab)
- Increase the SO line qty to 2
- Validate the MO → traceback on finished_move.ensure_one()

Problem:
When a delivery date is set on the SO, it propagates to the MO's
finished move via date_deadline. However, `production.date_deadline\
was not updated (guarded by `if not production.date_deadline`) because
the MO already had a deadline set at planning time:
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L476

When the SO qty then increases, change_production_qty copies the
finished move to create a delta move. That delta move receives
production.date_deadline (the stale planning date) instead of the
delivery date, so the two finished moves end up with different
deadlines and cannot be merged:

https://github.com/odoo/odoo/blob/19.0/addons/mrp/wizard/change_production_qty.py#L43

Solution
- always update production.date_deadline from its finished moves
- link the new delivery move to the finished move after the qty
  wizard runs so it gets reserved after MO validation

opw-6273076

Forward-Port-Of: odoo/odoo#269405

Steps to reproduce:
-------------------------------------------------
1. Install `planning_field_service_worksheet` module with demo data
2. Go to Worksheet Templates
3. Open First Worksheet > Observe `+ Add Property` button at bottom
4. From the Navigation button, move to the next Worksheet Template
5. Come back to First Template using the same navigation button

Observation:
-------------------------------------------------
The '+ Add Property' button and property edit buttons disappear after navigating away from and back to the first worksheet template.

Issue:
-------------------------------------------------
`PropertiesDefinitionField.setup()` sets
`this.state.isInEditMode = this.definitionRecordId` only once during component initialization.
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_definition_field.js#L9-L12

When the user navigates via the pager, `FormController.onWillLoadRoot` resets `propertiesState.editable` to `false` and fires a `PROPERTY_FIELD:EDIT` bus event with `{ editable: false }`, which calls `setEditMode(false)` https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/form/form_controller.js#L407

After the new record loads, the parent's `useEffect` (which watches the definition record field) should restore edit mode, but it short-circuits when both `isInEditMode` and `editMode` are `false`
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_field.js#L115-L117

Since `setup()` doesn't re-run on record navigation and nothing else restores `isInEditMode`, it stays `false` permanently. This hides the parent template's 'Add Property' button
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_field.xml#L86-L90

Solution:
-------------------------------------------------
* Replace the one-time assignment in `setup()` with a `useRecordObserver` that sets `this.state.isInEditMode` whenever the record changes. This hook fires both on initial setup (via `onWillStart`) and on every record change (via `onWillUpdateProps`) ensuring `isInEditMode` is correctly restored after pager navigation

* Using `record.data.id` rather than `true` preserves the existing behavior of disabling edit mode for unsaved records (where `id` is `false/falsy`)

opw-6264361

Steps to reproduce:
-------------------
1. Create a product with a tax (e.g. 15%).
2. Create a pricelist that changes the price (e.g. 100 to 200).
3. Create a fiscal position mapping the tax (e.g. 15% to 30%).
4. Add the pricelist and the fiscal position in PoS.
5. Add the product to the cart, and select the tax and the pricelist created in the previous steps.
6. Long press on the product to see its info.

The price should be 200 now after selecting the pricelist. Also the tax should be 30% bc of the FP mapping, i.e. total price should be 200 + 30% = 260.

However, we observe that VAT shows 15 (15%) instead of 60 (30%), and Price incl. Tax shows 230 instead of 260.

What's happening:
-----------------
On the frontend, `getTaxDetails()` is called with no options, so it uses the product `list_price` (100) and `taxes_id` (15%), giving VAT = 15.

Alos, on the backned, `self.taxes_id` is used directly to compute the taxes, even though the pricelist price is correct (200), fiscal position is ignored, hence 200 + 15% = 230 instead of 200 + 30% = 260.

The fix:
--------
On frontend, we pass the pricelist and fiscal position to `getTaxDetails`, and compute the tax name from the mapped taxes.

On the backend, we read the `fiscal_position_id` from the context and apply the tax mapping, so the correct taxes are used.

opw-6200632

Forward-Port-Of: odoo/odoo#266012

Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe

Steps to reproduce the bug:
- Create a product with a BoM with operation dependencies enabled
- Add 4 operations on the same workcenter:
    - opA: no blocker
    - opB: blocked by opA
    - opC: blocked by opA
    - opD: blocked by opC
- Confirm a manufacturing order from this BoM
- Click Plan

Problem:
opA was scheduled after opB, violating the dependency.

`_plan_workorders` starts planning from the "leaf" workorders (those with no dependents). Given the structure above, the initial set is [opB, opD]. Processing opB first correctly plans opA then opB. But processing opD triggers a recursive chain opD→opC→opA which calls `action_unplan(opA)` and replans it from scratch. By then, opB already occupies the workcenter slot that opA originally held, so opA ends up scheduled after opB.

Solution:
Add `and not wo.is_planned` to the filter on `blocked_by_workorder_ids` in the recursive call inside `_plan_workorders`. Workorders that are already planned are skipped instead of being unplanned and replanned, preserving the correct order.

opw-6299179