Step To Reproduce:
- have a product with cost price
- settle a order in pos with that product and refund it
- go to reporting > orders > pivot view
- check margin for that refund order

Observation:
- the margin is calculated wrong, as we do not consider order sign
- as `margin = price_subtotal - total_cost`
- so with price_subtotal `200` and total_cost `-100` margin becomes 300

Fix:
- consider order sign i.e. -ve for refund order else +ve for `price_subtotal`
- so with price_subtotal `-200` and total_cost `-100` margin becomes -100

**Before**
<img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" />

**After:**
<img width="343"  alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" />



Note: for this to be applied, app update is needed

opw-5418964


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

Forward-Port-Of: odoo/odoo#241870

Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number

Current behavior before PR:
If you have two incoming vendor bills (over a period of time) where the first bill has these details:
- VAT number: `BE0477472701`
- Name: `Odoo`

And the second bill (e.g three months later) has these details:
- VAT number: `BE0477.472.701`
- Name: `Odoo S.A`

Odoo will do something interesting and will create a second new contact.
The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo".
However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701".
Throughout Odoo however VAT numbers are parsed and stored without dots in it.
The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots.
Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same.

Desired behavior after PR is merged:
Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different.


P.S: please find two sample XML's here: 
[sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml)
[sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml)

If you upload both back to back on a default V19 you will see two contacts.
After this code change you will only see one contact where both bills are mapped to the same contacts.

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

Forward-Port-Of: odoo/odoo#244572

### Issue:
When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError
This happens because these entities often use a TAN (Tax Deduction and Collection Account Number) instead of a PAN as the base for their GSTIN

### Cause:
In 19.0, PAN handling was refactored using the new `pan_entity` mechanism
With this change, PAN values are validated through `_check_pan_name()`, which incorrectly raises a `ValidationError` for GSTINs that rely on a TAN instead of a PAN:
`The entered PAN seems invalid. Please enter a valid PAN.` The PAN entity shouldn't be created for non PAN number

### Steps to reproduce:
- Install `l10n_in` and `contacts`, then switch to IN Company
- Create a new contact with GSTIN: `07DELN10357E1DH`
- Save and the Error is raised

### Notes:
At the same time, we'll set the TAN if the GSTIN is based on it
The documentation for the TAN structure:
https://incometaxindia.gov.in/tutorials/23.%20tan.pdf

opw-5461356

Forward-Port-Of: odoo/odoo#243737

*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock

### Issue: 

The partner_id (contact field) of stock move is no longer propagated in pull chain since the procurement/reference refactoring of 19.0 see 2713876dbc70d3984e584a9037a2206dcda4e84a

#### Steps to reproduce:
- In the settings enable Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse in two step deliveries
- Modify the routes to have two pull rules: Stock -> Out -> Customer
- Create and confirm an SO, 1 unit of a storable product for a customer
#### > While the customer is set on the ship move and picking it is not on the pick move and picking.

### Cause of the issue:

Due to the configuration, the ship move is created by the `action_launch_stock_rule` and linked to the customer via the procurement created from the sale order line:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295 Then, the confirmation of the ship move generates a second procurement for the pick move creation. Prior to 19.0, the partner_id of this second procurement was set to the customer via the procurement group: https://github.com/odoo/odoo/blob/712cd806c38e193acdb966e4d3b339ab780f158e/addons/stock/models/stock_rule.py#L333 However, since procurement groups have been removed by the reference refactor 2713876dbc70d3984e584a9037a2206dcda4e84a, the partner id is now expected to be set from the procurement values:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332 As it is not set by any mean in this procurement values it will therefore not be propagated.

### Additional changes:

1. The `partner_id` of the procurement values needs to be harmonized are some methods set a recordset and others a record id:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/point_of_sale/models/pos_order.py#L1707
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/mrp_subcontracting_dropshipping/models/stock_orderpoint.py#L10-L13
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295
The correct behavior is to set an id since the `partner_id` value of the procurement group is used in the `_get_stock_move_values` and written in its "raw state" as the `partner_id` values for the stock move for creation (when sale_stock is installed):
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/stock.py#L171-L174
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L378-L381

2. The `partner` key of the procurement values is set by to `partner_id` in every overrides but since 2713876dbc70d3984e584a9037a2206dcda4e84 was incorrectly cahnged to `partner`:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332
We change back this key to the expected `partner_id` and revert the associated pos  fix 203f807a2b764821ec4673515dd29f392ec37b3a using the changed `_get_partner_id` method.

3. In certain use cases, such as inter-warehouse transfer the the `partner_id` should not be propagated by the pull chain as it is expected to be set by the `_get_stock_move_values`:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/stock/models/stock_rule.py#L339-L346

4. Since the `partner_id` is used to set the `dest_address_id` here:
https://github.com/odoo/odoo/blob/92486bab9b73f4370629452c454c25371d5063ac/addons/purchase_stock/models/stock_rule.py#L350
But is suppose to be reset for non dropshipping use case:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/purchase_stock/models/purchase_order.py#L80-L82
We need to modify the fix of 3fb81df557553d471ff72998200097b3a0ea666f in order for the value set by th epartner_id to be reset in case we are not in a dropshipping use case.
Similarly, we should only add the `partner_id` of the procurement value as a possible `dest_address_id` in the dropship use case:
https://github.com/odoo/odoo/blob/2c0c26e6cc61f70c91617617ef77f23cfaa1dde6/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L19-L23

5. Since we are setting a default falsy 'partner_id' values in the `_prepare_procurement_values` of stock moves (e.g.`self.partner_id.id`) we needed to slightly alter the `_prepare_purchase_order` of the `mrp_subcontracting_dropshipping` module so that it sets the partner of the subcontractor when the move sets it to `False` rather than unset:
https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L10-L11

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

Forward-Port-Of: odoo/odoo#243028

### [[FIX] web: cleanup string-related utils](https://github.com/odoo/odoo/pull/241068/changes)

This commit cleans up several utility files relating to string-parsing
and translations. Main changes are:

- fixed `sprintf` and related functions: before this commmit, string
substitutions were incorrectly inserted in the template string, and it
was actually reflected in a test (template : `"<p>%s</p>%s"` => test
incorrectly asserted that both strings were inserted in the first "%s"
and "undefined" was inserted in the second);

- to replicate the Python homonymous behaviour: "%s" characters can now
be escaped in "sprintf-ed" strings by adding an additional "%" sign
before the expression;

- unification of translations via a TranslatedString class (which will
also simplify external overrides);

- unified API for some utility functions sharing the same purpose
(typically: accepting an iterable instead of a list, etc.);

- filling missing docstring, re-ordering functions and constants for
clarity;

- added "headless" tag to some utility functions' tests, when UI is not
needed.

Enterprise: https://github.com/odoo/enterprise/pull/104939

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

Forward-Port-Of: odoo/odoo#241068

**Issue**
When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total.

**Steps to Reproduce**
1. Install the Accounting app and the Argentinian localization (l10n_ar)
2. Set the 21% VAT Purchase tax as Included in Price
3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes
4. Open the VAT summary report for that bill

Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once.

**Root Cause**
The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist.

**Fix**
The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals.

opw-4776861

Forward-Port-Of: odoo/enterprise#98933
Forward-Port-Of: odoo/enterprise#85873