France’s electronic invoicing reform : The tax administration  needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C.

This creates two complementary obligations:

- **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow.
- **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based).

## Scope

Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information.

Flux 10 is introduced for transactions that must be reported separately:

- B2C transactions, where there is no buyer-side e-invoice exchange.
- International B2B transactions, where the counterparty is outside the French domestic B2B mandate.
- Payment reporting when VAT exigibility depends on collection.

The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines.

## Corrections and Lifecycle

Flux 10 supports both:

- **Initial reports**, for the first declaration of a period.
- **Rectificative reports**, when already reported data must be corrected or completed.

This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted.

## Security and Eligibility

This PR also enforces stronger safeguards before using PDP/PA services.

- **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app.
- **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure.

Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform.


Task-4603708

Forward-Port-Of: odoo/odoo#239576

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#117283

Steps to produce:
---
- Install `website_sale` with demo data.
- Go to `website > ecommerce > products > ecommerce categories`.
- Open `Desks/Components` category > Set website to `My website 2`.
- Open the shop page on website > Click on Desks category.

Issue:
---
- The Components subcategory is still displayed on Website 1.
- Clicking on it leads to a Not Found page since the category is not assigned to that website.

Root cause:
---
- At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access.
- As a result, categories restricted to another website are still shown.

Solution:
---
- Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed.

[1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769

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

Forward-Port-Of: odoo/odoo#266637
Forward-Port-Of: odoo/odoo#262410

Step to reproduce:
- install "pos_settle_due"
- create a pos order, set order price = 0, select a customer
- go to payment page, select "customer account" as payment method
- here you can set any amount to pay, ex 100$
- fulfill the  order.

Observation:
- the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer)
- As per PO, this flow doesn't make sense

Issue:
- customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] 
- [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35

Fix:
- we hide payment method of type "pay_later" in case of 0 price order

opw-6123699

Forward-Port-Of: odoo/enterprise#118296
Forward-Port-Of: odoo/enterprise#116556

### Description of the issue / feature this PR addresses

The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key:

\`\`\`python
# addons/hr_org_chart/controllers/hr_org_chart.py:35
write_date=int(employee.write_date.timestamp()) * 1000,  # to have it in milliseconds for js
\`\`\`

When \`hr_employee.write_date\` is NULL the ORM returns \`False\` for the field, so the unconditional \`.timestamp()\` call raises:

\`\`\`
AttributeError: 'bool' object has no attribute 'timestamp'
\`\`\`

This crashes the employee form view on click for any record with NULL \`write_date\`. NULL audit columns can occur in legacy databases — records inserted via direct SQL by data-loaders, rows carried forward from very old Odoo versions that did not always populate \`_log_access\` columns, or data restored from anonymised backups. The ORM's \`vals.setdefault\` defaults in \`_log_access\` do not override an explicit falsy value passed by callers.

This is a regression vs 18.0 — the 18.0 \`_prepare_employee_data\` did not include \`write_date\` at all.

### Behaviour before this PR

Opening the form view of an employee with NULL \`write_date\` (any affected employee record) raises \`AttributeError\` and the org chart fails to load.

### Behaviour after this PR

The controller falls back to \`0\` when \`write_date\` is missing — the same defensive pattern already used in \`odoo/addons/base/models/avatar_mixin.py:67\`:

\`\`\`python
bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp() if self.create_date else ""))
\`\`\`

The org chart loads; the JS cache key for that one record is \`0\` until the record is next written (which will set \`write_date\` via the normal ORM path). No user-visible regression on healthy rows.

Forward-Port-Of: odoo/odoo#264591

**Steps to reproduce:**
- Install documents_account
- Set up alias to catch incoming mails
- Receive a mail with xml attachement which can be previewed as pdf
- Go to Documents app
- Click on the document preview
- Preview is split in two iframes, both with the same content (pdf)

**Issue:**
Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`.
```
<iframe t-if="state.file.isPdf" ...
<iframe t-if="state.file.isText" ...
```

It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file.

**Fix:**
Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`.

Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: 
`<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">`
which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b

related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450

opw-6018536

Forward-Port-Of: odoo/enterprise#118041
Forward-Port-Of: odoo/enterprise#112041

This commit fixes the test "waitForTimeout does not trigger update if
interaction is not ready yet", which could very rarely fail on runbot.

**Origin of the problem**
The test relies on precise timings, but the helper `advanceTime` could
introduce a non-deterministic lag because, when called with default
options, it awaits for an animation frame. If the lag happens to be too
long, the second `verifySteps` is called too late and the test fails.

**Fix**
The helper `advanceTime` is now called with the option `animationFrame`
set to false to avoid awaiting for an animation frame. For additional
safety, the waiting time is also reduced.
Two changes not directly related to this problem have been applied to
improve the test: 1. an unnecessary `await` in `willStart` has been
removed; 2. the `animationFrame` has been set to false also on the
second `advanceTime` (a non-deterministic lag here can't fail the test,
but still there is no reason to await for the animation frame).

runbot-243515

Forward-Port-Of: odoo/odoo#266432

**Problem:**
When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error.

**Steps to Reproduce:**
- Make a branch of "My Company (San Francisco)"
- Set user "Marc Demo" to only have access to the branch
- Add a new bank journal set to "EUR" currency
- Switch to Marc Demo
- Try to add a transaction in the new bank journal

**Root Cause:**
When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error.

**Solution:**
Call the currency conversion with sudo() to ensure access to the relevant companies.

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

Forward-Port-Of: odoo/odoo#263968
Forward-Port-Of: odoo/odoo#263425

**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

### Description of the issue/feature this PR addresses: 
**Issue:** When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue.

**Solution:** This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds.

### Current behavior before PR:
A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue.

### Desired behavior after PR is merged:
The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created.

opw-6179479

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

Forward-Port-Of: odoo/odoo#266180

**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

Forward-Port-Of: odoo/enterprise#115408

## Issue
When scheduling a sign request, the request appears immediately on the portal for the requested signer.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Create and send a sign request
    - Signer 1: Any portal user (e.g., Joel Willis)
    - Use the clock icon to schedule the signature request to a future date
3. Log in as the portal user used in step 2
4. Navigate to Signature Requests
5. **The signature request already appears in the list, even though it was scheduled for a future date.**

## Cause
The portal filters the sign requests shown based on the `is_mail_sent` field, which does not properly reflect when the signature request is shared to the user.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/controllers/portal.py#L40

In fact, when scheduling a signature request, the `is_mail_sent` field is unconditionally set to `True`, even if the signature request will only be sent later.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request_item.py#L289

## Fix
Since the `"scheduled"` `sign_request_item.state` option introduced by https://github.com/odoo/enterprise/commit/ed8d5a653e01b1378f0020e2f7a7c2d39fadf3e9 in 19.1, we can easily filter out the sign request items that are scheduled. That state is automatically updated by the `_cron_update_state`, introduced by the same commit as the `"scheduled"` option.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request.py#L493-L503

opw-6227472

…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

**Steps to reproduce:**
- Accounting > Configuration > Settings > Default Accounts > Product Accounts
- Change the default expense account (and income account)
- Create a new product category
- category still proposed the old accounts

Affected versions: from 18.2 till 19.2

**Cause:**
`ir.default` for `product.category` (`property_account_expense_categ_id` and `property_account_income_categ_id`) was not updated when `res.company.expense_account_id` / `income_account_id` changed, so new categories kept using stale defaults.

and in 19.0
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L490
and
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L753
calls
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L1136-L1139

However, when stock_account is installed

https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/stock_account/models/res_company.py#L361-L366

this gets called, without calling super, that's why it didn't work although the fix is there, we will need to adapt another fix in 19.0+

**Solution:**
Call `_set_category_defaults()` in `res.company.write()` so `ir.default` stays aligned with the company's current product default accounts.

opw-6145491

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

Forward-Port-Of: odoo/odoo#265052
Forward-Port-Of: odoo/odoo#261594

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

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

Forward-Port-Of: odoo/odoo#267081
Forward-Port-Of: odoo/odoo#266374

**Steps to reproduce:**
- Install Sales app
- Create a Sales Order
- Click on the 'Send by Email' action
- Add an attachment and send it
- Open the chatter to create a log note
- Attachment is attached to the new message
- It disappears on refresh

**Issue:**
Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`.

Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers.

But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`.

**Fix:**
Restrict the attachment save to the full composer using context.

[1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027
[2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3

opw-5164504

Forward-Port-Of: odoo/odoo#266530
Forward-Port-Of: odoo/odoo#265736

### Description of the issue/feature this PR addresses:
This PR introduces batch processing to the VAT Books ES (Libros de IVA) report generation. When attempting to export the report for periods containing a massive volume of invoices, the ORM cache continuously accumulates records, leading to severe memory consumption. By implementing batching and explicitly clearing the environment cache, use memory use will remain stable and efficient.

### Current behavior before PR:
Generating the VAT Books report loads all account move lines into memory at once. Because the ORM cache is never cleared during the iteration, RAM usage spikes continuously. On databases with tens or hundreds of thousands of invoices in a single period, this leads to significant performance degradation, worker timeouts, or complete Out-Of-Memory (OOM) crashes.

### Desired behavior after PR is merged:
The report engine now splits the recordset into manageable batches (e.g., 50,000 accounts per batch). After processing each chunk to extract the income and expense line values, invalidate_model() is called to flush the ORM cache related to the searched records. This frees up memory continuously, keeping the server's RAM usage flat and allowing the successful export of massive datasets without crashing.

### Benchmark:
The model is iterating through ~1.1M account move lines when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 385 MB | 666 MB |
| ~340,000 account move lines |1.2 GB | 1.5 GB |
| ~1.2M account move lines | MemoryError | 1.5 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 32s | 12s |
| ~340,000 account move lines | 2:29min | 1:11min |
| ~1.2M account move lines | MemoryError | 4:11min |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#116139

When the stock valuation closing report computes FIFO valuation at a
historical date, it recomputes each move's value via
`move._get_value(at_date)`. For moves without a purchase link (inventory
adjustments, initial inventory), the value falls through to
`_get_value_from_std_price()` which uses the current `standard_price`.

For FIFO products, `standard_price` is recalculated on every stock
operation (`total_value / qty_available`), so the historical valuation
drifts as new operations are processed.

This is the same root cause as https://github.com/odoo/odoo/commit/d2934b59e49ef943d957a80e53cca835a59fabef which fixed it for AVCO's
`_run_average_batch` by passing `forced_std_price`. This commit fixes
the FIFO path by using `move.value / move._get_valued_qty()` (the unit
price stored at validation time) as the fallback in
`_get_value_from_std_price` when `at_date` is set and no std_price was
explicitly forced.

Steps to reproduce (in `odoo-bin shell`, using freezegun's `freeze_time`
to backdate two operations to different dates, e.g. date1 = two days ago
and date2 = yesterday):

1. Create a FIFO periodic product with `standard_price = 10`
2. With `freeze_time(date1)`: apply an inventory adjustment of 10 units
3. With `freeze_time(date2)`: receive 10 units at unit cost 20
   > standard_price shifts to 15
4. Check `product.with_context(to_date=date1).total_value`
   > Before fix: 150 (drifted with current standard_price)
   > After fix:  100 (stable, uses stored move value)

closes opw-6081736

Forward-Port-Of: odoo/odoo#262127

### Description of the issue/feature this PR addresses: 
**Issue:** A recent update to support `certificateFingerprint` introduced a regression for existing users authenticating with standard certificates (AKA `certificateSubject`). Because the matching logic strictly checked for the company NIP within the certificate subject, it failed for users using personal PESEL certificates to act on a company's behalf. 

**Previous PR:** https://github.com/odoo/odoo/pull/264851 

**Solution:** Expanded the string-matching heuristic in the XML signer to strip formatting characters from the NIP and explicitly checks for standard Polish qualified certificate prefixes (VATPL and PNOPL) to accurately get the identifier type.

### Current behavior before PR: 
When a user logs in via a personal PESEL certificate for a company context, the NIP check fails and miscategorizes the payload as a `certificateFingerprint`. KSeF rejects this mismatch, causing a 400 error for previously working setups.

### Desired behavior after PR is merged: 
The authentication flow distinguishes between `certificateSubject` and `certificateFingerprint` by checking for valid Polish prefixes or exact cleaned NIP matches. Existing customers are restored to working order natively, and new customers using manual fingerprints are still supported without requiring any database or UI changes.

opw-6251153

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

Forward-Port-Of: odoo/odoo#267060

When we create a product variant and have a pricelist 
which is based on the cost price, and change the cost price, 
the on_sale_price doesn't update. You have the change the price 
list to other and back to the one you want for it to trigger 
change because the _onchange_compute_pricing only gets 
triggered if there's change on pricelist (pricer_sale_pricelist_id), 
and sales price (lst_price).

Steps to Reproduce:
1.Create a pricelist and add a line with "formula" price type, 
and based on "cost",
2.Create a product variant, and add the pricelist
just created.
3.Change the "Cost". The "On Sale Price" doesn't update. 
4.You have to change the price list to some other
and back to the one you want for the "On Sale Price" to update.

To fix the issue, we add the field Cost (standard_price) on 
api.onchange, so when we change the cost it'll
update the "On Sale Price" right away.

opw-5947995

Forward-Port-Of: odoo/enterprise#117806
Forward-Port-Of: odoo/enterprise#111892