The current implementation of l10n_se_sie4_export does not follow 
the SIE4 specification (version 4C, 2025-08-06) in several critical 
areas, causing exported files to be rejected by Swedish audit software, 
accounting systems and Skatteverket's own tools.

This PR corrects all known spec deviations and completes the 
implementation of optional but commonly required identification posts.

Note: The character encoding was set to ISO-8859-1. 
The SIE4 specification §5.8 explicitly requires IBM PC 
Codepage 437 (CP437). Files generated by the current 
implementation cannot be correctly read by any SIE4-compliant 
receiving system.

Some identification posts are optional per the SIE4 specification, 
but required in real world use by Swedish audit software, accounting 
systems and government filing tools.

The exported file has been validated against the official SIE4 
validator at https://sietest.sie.se and passes all checks.

**Specification reference:** 
https://sie.se/wp-content/uploads/2026/02/SIE_filformat_ver_4C_2025-08-06.pdf

**Fixes:**
- CP437 encoding per spec §5.8
- Amount format max 2 decimals per spec §5.9  
- Identification posts in correct order per spec §5.12
- #VER sequence number per serie per spec §11
- #VER with all 6 fields per spec §11
- partner_id.company_registry as canonical source
- stdnum.luhn for org number validation (v1.17/v1.19 compatible)
- _escape_sie on all string values
- Correct implementation order

**Feature completion:**
- #ORGNR with Luhn validation and report header warning
- #ADRESS, #FNR, #GEN with username
- #KPTYP hardcoded EUBAS97 (Odoo Swedish chart)
- #VALUTA always written
- #PROSA support
- #KSUMMA per spec §10
- #OMFATTN for partial period export
- Import key in #VER sign field (move.name)
- 7 tests including encoding, round-trip and KSUMMA

The current implementation of l10n_se_sie4_export does not follow 
the SIE4 specification (version 4C, 2025-08-06) in several critical 
areas, causing exported files to be rejected by Swedish audit software, 
accounting systems and Skatteverket's own tools.

This PR corrects all known spec deviations and completes the 
implementation of optional but commonly required identification posts.

Note: The character encoding was set to ISO-8859-1. 
The SIE4 specification §5.8 explicitly requires IBM PC 
Codepage 437 (CP437). Files generated by the current 
implementation cannot be correctly read by any SIE4-compliant 
receiving system.

Some identification posts are optional per the SIE4 specification, 
but required in real world use by Swedish audit software, accounting 
systems and government filing tools.

The exported file has been validated against the official SIE4 
validator at https://sietest.sie.se and passes all checks.

**Specification reference:** 
https://sie.se/wp-content/uploads/2026/02/SIE_filformat_ver_4C_2025-08-06.pdf

**Fixes:**
- CP437 encoding per spec §5.8
- Amount format max 2 decimals per spec §5.9  
- Identification posts in correct order per spec §5.12
- #VER sequence number per serie per spec §11
- #VER with all 6 fields per spec §11
- partner_id.company_registry as canonical source
- stdnum.luhn for org number validation (v1.17/v1.19 compatible)
- _escape_sie on all string values
- Correct implementation order

**Feature completion:**
- #ORGNR with Luhn validation and report header warning
- #ADRESS, #FNR, #GEN with username
- #KPTYP hardcoded EUBAS97 (Odoo Swedish chart)
- #VALUTA always written
- #PROSA support
- #KSUMMA per spec §10
- #OMFATTN for partial period export
- Import key in #VER sign field (move.name)
- 7 tests including encoding, round-trip and KSUMMA

**Problem:**

Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date.

This introduced an unnecessary dependency chain:
```
contract_start_date -> employee_version_id -> contract_template_id -> wages and other offer fields
```

As a result, updating `contract_start_date` invalidates and recomputes the whole chain, even when `employee_version_id` does not actually change.

In addition, offer fields were coupled in a single compute, causing unrelated fields to be reset to template values when only one field required recomputation.

**Fix:**

- `contract_template_id` compute now depends on `employee_id` instead of `employee_version_id`, and directly uses the employee's `version_id`, breaking the chain while preserving default behavior.
- The offer fields computations were also split to avoid unintended recomputations and field resets.
- Simplified `_get_version` by always copying values from the template to the currently active version.
---

**Additional fix:**

The `is_hr_payroll` context flag is used to distinguish payroll vs recruitment flows when creating an offer with both `employee_id` and `applicant_id` unset.

A recent change in [Task #6094737](https://www.odoo.com/odoo/project/1251/tasks/6094737) did not account for this flag, causing both fields to be hidden when opening the form from Payroll (a new feature added in saas-19.3).

This is fixed by properly considering `is_hr_payroll`, restoring consistent behavior across all versions.

Task: 6158245

Issue:
Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobilira CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button).

opw-5432421

Forward-Port-Of: odoo/enterprise#108355

**Steps to reproduce:**
* Install Peru - Accounting Reports (l10n_pe_reports).
* Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047).
* Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4).
* Export the TXT file and open it.

**Observed behavior:**
* Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code.
* SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes.

**Cause:**
* `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235".
* The same incorrect value was also written to field 28 (aduana_code).
* ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

**Fix:**
* For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value).
* Apply the same logic to field 28 (aduana_code) for consistency.

opw-6157662

Forward-Port-Of: odoo/enterprise#115406

…lit for same-product lines

When doing an intercompany Sale->Purchase with multiple lines having the same products, the receipt picking would be incorrectly assigned:
- Enable Inter-Company Transactions on both companies (Create and validate)
- Create SO in company A to company B with 2 lines having the same product P, Confirm. => Delivery in company A, Purchase and Receipts in company will be created => The SO/PO/Delivery/Receipt will all have 2 lines
- Validate delivery => On the receipt, the 2 units of P are reserved on the 1st move, and the 2nd move is not reserved.


https://github.com/user-attachments/assets/b4816051-120e-4226-9228-fd552649d5ef


---

### Test result without fix:
```
2026-04-23 13:16:44,577 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: Starting TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product ... 
2026-04-23 13:16:44,949 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: ====================================================================== 
2026-04-23 13:16:44,949 48027 ERROR oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: FAIL: TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/sale_purchase_stock_inter_company_rules/tests/test_inter_company_so_to_po.py", line 109, in test_02_inter_company_multiple_lines_with_same_product
    self.assertRecordValues(purchase_from_a.picking_ids.move_ids, [
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/tests/common.py", line 709, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'pr[18 chars]0, 'quantity': 1.0}, {'product_uom_qty': 1.0, 'quantity': 1.0}] != [{'pr[18 chars]0, 'quantity': 2.0}, {'product_uom_qty': 1.0, 'quantity': 0.0}]

First differing element 0:
{'product_uom_qty': 1.0, 'quantity': 1.0}
{'product_uom_qty': 1.0, 'quantity': 2.0}

- [{'product_uom_qty': 1.0, 'quantity': 1.0},
?                                       ^

+ [{'product_uom_qty': 1.0, 'quantity': 2.0},
?                                       ^

-  {'product_uom_qty': 1.0, 'quantity': 1.0}]
?                                       ^

+  {'product_uom_qty': 1.0, 'quantity': 0.0}]
?                                       ^

```

OPW-6145683

Forward-Port-Of: odoo/enterprise#118548
Forward-Port-Of: odoo/enterprise#114873