This commit aims to make the invoice line tax drop-down cleaner and more
straightforward.
The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes
and `0% Not Subject to VAT` is visible with the other `0%` taxes such as
`0% EX G`, etc. The users were incorrectly selecting the `0% Not Subject to VAT`
instead of the actual `0%` taxes according to the characteristics of the supply;
leading to non-compliance with the ZATCA rules.

Before this commit:
- `15% PH PE HS` tax was `active`.
- `0% PE & 0% PH` had distribution for invoices: `base tax grid = 3(B)` and
  distribution for refunds: `base tax grid = 3(B)`.
- `0% Not Subject to VAT` tax was `active` and had distribution for invoice:
  `base tax grid = 3(B)` and distribution for refunds: `base tax grid 3(B)`
- `0% IT G and 0% QT` taxes were `active`.

After this commit:
- `15% PH PE HS` tax is `inactive`.
- `0% PE & 0% PH` taxes have distribution for invoices: `base tax grid = 2(B)`
  and distribution for refunds: `base tax grid = 2(B)`
- `0% Not Subject to VAT` tax is set to `inactive`, `sequence = 17` and tax grid
  has been removed.
- `0% IT G and 0% QT` taxes have been set to `inactive`.

task-5959979

Forward-Port-Of: odoo/odoo#253598

When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag.
The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.
This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices.

Two issues:
- We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`.
- When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678`

ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf

Ticket [link](https://www.odoo.com/odoo/project.task/6148039)
opw-6148039

Forward-Port-Of: odoo/odoo#262339
Forward-Port-Of: odoo/odoo#261964

**Steps to reproduce**:
- Activate analytic accounting on the settings
- Create an Analytic distribution models for a partner
- Create a product P with a cost and Inventory Valuation set to Perpetual
- Create a location L with a Location Type set to Inventory Loss and a Loss Account
- Create an internal transfer from Stock to location L for product P
- Confirm it
- Check the associated journal entry:
-> The analytic distribution is not set of the move lines

**Cause**:
While validating the picking:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock/models/stock_picking.py#L1426 An account move is created without specifying `partner_id`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L178 https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L200-L205 This leads to the creation of account move lines, triggering `_inverse_analytic_distribution`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1416-L1417 The method accesses `analytic_distribution` of the `move_line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1410 which triggers its associate compute method:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1213

To retrieve the right `analytic_distribution`:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1224 By defining this search domain:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L85

if `partner_id` is not in the `vals`, it falls back to False: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L79 As a result, the distribution linked to the `partner_id!` is not found, since the `partner_id` of the vals is determined from the `account.move.line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1237 which is False since it is not specified while creating the account move.

opw-5918058

Forward-Port-Of: odoo/odoo#261713

## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**

## Cause
The condition to raise the error message does not take into account the state of the leave:

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204

This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.

(related to)
opw-6089990

Forward-Port-Of: odoo/enterprise#115765

### Steps to reproduce:

- Create and confirm an MO for 1 unit of product without bom
- Set the producing quantity to 1
- Add a new component line for a product tracked by SN
- Click on details operation and add a lot > Save
- Produce all
#### > The quantity is of the component move is reset to 0 and the lot erased

### Cause of the issue:

Setting the producing quantity to 1 will set the state of the of the MO to `to_close`. After which, adding a new move will add it in the appropriate `picked` state so that the move is considered when validating the MO:
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/mrp/models/stock_move.py#L269-L270 
However, clicking on the detailed operation and selecting a lot will create a new `move_line` without set `picked`. As such the related picked compute method of the stock move will be launched:
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L123-L127
resetting the picked state of the move to False as a new move line was added (triggering a dependency of its compute method):
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L126
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move.py#L280-L286

Additional change:

The test `TestSubcontractingBasic.test_flow_tracked_1` underlined that the `auto_pick_move_lines` context key added to `action_show_details` had to be cleaned in subcontracting flows before synchronizing the subcontracted productions:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/mrp_subcontracting/models/stock_move_line.py#L34-L38
Otherwised, if a receipt for tracked subcontracted product is picked and additional move lines are added via the detailed operations, the subcontracted backorders created to fulfill the additional demand will will pick each of their move leading to subcontracted MO's that will avoid assignment:
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L1914-L1916
and be cancelled at the picking validation:
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/mrp/models/mrp_production.py#L1924
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L2107-L2109
This can be checked by launching the test without the `clean_context`.

We also improve the `TestSubcontractingBasic.test_flow_tracked_1` test as it is not possible to edit moves to be picked prior to confirmation and since move lines can not manually be created in picked state.

### Fix:

Note that we rely on a context key to adapt the compute method of the picked field of the `stock.move.line` instead of adding a `default_picked` context in the `action_show_details` because the new move lines added to the list view of the `move` form are generated via the UI by opening a list of `stock.quant` which cleans the `default_context` key prior to generation of the `new` move line. In particular, the exact UI flow can not be tested by relying on the `Form` class of stock moves since the new move lines will then be created by via the `O2MForm` class:
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L642-L658
and an onchange of the stock move line will be triggered to determine its value relying on the `default_picked` context key to create the new move line in picked state:
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L332-L339
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L579
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/addons/web/models/models.py#L2005-L2008
By contrast performing the flow from the interface will highlight that the `default_picked` context key does not solve the issue.

opw-5991985

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

Forward-Port-Of: odoo/odoo#258935

**Steps to reproduce**
- Settings: Timesheets > Invoicing policy = only validated TS.
- Have a service product with an invoicing policy based on timesheets.
- Create a sales order using this product.
- From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them.
- Invoice the SO, using a timesheets period that includes both TS.
- Notice that the quantity of the invoice line includes the non-validated timesheet.

**Cause**
The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1

**Change**
Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain.

opw-6116670

Forward-Port-Of: odoo/odoo#261835
Forward-Port-Of: odoo/odoo#259224

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Forward-Port-Of: odoo/enterprise#115723
Forward-Port-Of: odoo/enterprise#114429

**Steps to produce:**
- Install `sale_management` without demo data.
- In settings > Under Taxes > Set `Tax Prices` as `Tax Included`.
- Create a product with a sales price of 10.
- Create a quotation with this product.
- Confirm the line amount shows 10 (tax included).
- Click on preview.

**Observation:**
- In the preview, the product line amount is shown as tax excluded.

**Root cause:**
- At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`.
- This logic is not applied in the portal preview and PDF report.

**Solution:**
- Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`.

[1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663

Before:
---
<img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" />

After:
---
<img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" />

opw-6089473
---

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

Forward-Port-Of: odoo/odoo#261892
Forward-Port-Of: odoo/odoo#258551

Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45

Steps to reproduce:
- Create a new database with only the Purchase module installed
- Enable the "Units of Measure & Packagings" option
- Create a storable product "P1" with the following vendor pricelist:
  - Vendor: Azure Interior (1 pack of 6 for $10)
- Create a purchase order:
  - Vendor: Azure Interior
  - Quantity: 3 packs of 6 of P1
- Confirm the PO
- Click the Receive button (available without the Stock module since v19.1)

Problem:
1:/
Expected behavior: qty_received = 3 (in purchase UoM: packs of 6)
Actual behavior:   qty_received = 18 (product UoM: units)

`product_uom_qty` (expressed in the product's UoM) was used instead of `product_qty` (expressed in the purchase line's UoM) when computing `qty_received`. Since `qty_received` feeds into `quantity_to_invoice`, this caused the invoicing autocomplete to suggest 18 packs of 6 instead of the correct 3 packs of 6.

2:/
The parameter `invalid_targets` was not properly passed to the
translation function in the error message, causing a traceback
when trying to receive a PO in an invalid state.

opw-6080527

Forward-Port-Of: odoo/odoo#260163