Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report.

## Steps to produce:
* Install mrp_account without demo data.
* Create a product with inventory tracking enabled.
* Create a BoM of type kit for that product.
* Add component products with a defined cost and on-hand quantity greater than 0 to the BoM.
* Recompute the kit product’s cost from its BoM on the product page.
* Go to Inventory > Reporting > Stock > Inventory at date > Confirm

## Observed Behavior:
Even though kits do not appear on stock valuation they still do appear the inventory history report.

**Why kits should not appear on inventory history**
For example, consider a kit product called 'Computer' that is composed of the following components:

| Product | Quantity | Cost |
|--------|--------|--------|
| CPU | 1 | $300 |
| Motherboard | 1 | $300 | 

The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value  at that particular date as $1,200, which is incorrect because it is counting both the kit and its components

## Root cause:
This issue occurs when a user opens the inventory history for a specific date using the `Inventory at Date` option and clicks confirm.

At that point, the `open_at_date` function is triggered, which filters products based on the `domain` defined in [1]. Since this domain only checks for tracking-enabled products and does not exclude kit products, kit products still appear.

**Why doesn’t this issue occur in the normal stock view?** 
Because the domain is overridden at [2] to explicitly exclude kit products from the stock view.

However, the quantity history report does not apply this same domain override, so kit products continue to appear there.
[1]:
https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/stock/wizard/stock_quantity_history.py#L16-L38 [2]:
https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/mrp/views/product_views.xml#L164-L166

## Solution:
To ensure accurate total inventory valuation, kit products should be excluded from the valuation, and only their individual components should be considered.

This can be achieved by modifying and overriding the domain to explicitly exclude kit products.

This PR can be considered an extension of [3](https://github.com/odoo/odoo/commit/6d9c7165ec60ed0b871ac46d8d85ebbf082e8835).


opw-6164547

Forward-Port-Of: odoo/odoo#262185

Steps to produce:
---
- Install the `Sales` module, enable `Variants` in settings.
- Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as `Custom`, enable `Free Text`, set extra price to `25`, set variant creation to `Never`, and save.
- Create a sales order, add the product > configurator opens.
- Without saving, open and close the configurator repeatedly (using the pencil icon).

Issue:
---
-  Product price keeps increasing on every open.

Root cause:
---
- After this [commit], `_getVariantPtavIds()` returns a direct reference to the live `currentIds` array. In edit mode, pushing `_getNoVariantPtavIds()` into it mutates the actual field value, so no-variant PTAV ids accumulate on every reopen, causing duplicate IDs and inflated price computation.

Fix:
---
- Clone the array to avoid mutating the live `currentIds`.

[commit]: https://github.com/odoo/odoo/commit/bd4b6d02fed5fdc5ce628cb7d76df4cfdd2d1b3b

opw-6267273
---

**Note:** Not adding a test because only tour test is possible here in this scenario with makes the execution process slow.



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

Forward-Port-Of: odoo/odoo#267991

**Steps to reproduce:**
* Install the **l10n_es_edi_sii** module.
* Create a **Portuguese customer**.
* Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping.
* Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**).
* Go to **Accounting → Reporting → Tax Report → OSS Sales**.
* Export the **VAT Record Books (XLSX)** file and open it.

**Observed behavior:**
* The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17".
* The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17".

**Cause:**
* In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01".
* This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table.

**Fix:**
* Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`.
* For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise.
* For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise.

opw-6197141,6216485

Forward-Port-Of: odoo/enterprise#119467
Forward-Port-Of: odoo/enterprise#117236

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

  This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish localization databases. Because the Access Control List (ACL) rule for  l10n_pl.bank.account.verification  was limited only to the "Show Full Accounting Features" group (account.group_account_user ), standard billing users who do not have full accounting features could not access or read verification records during payment registration. This PR modifies the read access rules to grant permissions to the Invoicing group ( account.group_account_invoice ).

  ### Current behavior before PR:

  • Users belonging only to the "Invoicing" group (without "Show Full Accounting Features" rights) receive an Access Denied error when attempting to register a payment for a confirmed invoice:
  │  You are not allowed to access 'PL Bank Account Verification' (l10n_pl.bank.account.verification) records. 

  • This triggers a failure to write/compute the transient field  account.payment.register.l10n_pl_bank_verification_ids  during the payment wizard load, completely blocking billing  users from processing payments.

  ### Desired behavior after PR is merged:

  • Standard Billing/Invoicing users ( account.group_account_invoice ) can successfully register payments for invoices.
  • The payment register wizard computes the  l10n_pl_bank_verification_ids  and displays warning banners regarding VAT verification without throwing security exceptions.
  • Full Accounting users ( account.group_account_user ) retain read access as they inherit all privileges from the Invoicing group.

Closes #263938

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

Forward-Port-Of: odoo/odoo#267992

### **Steps to reproduce:**
- Install Payroll and Attendance apps.
- Create an employee with a flexible working schedule and work entry source as attendance.
- Create an attendance record for this employee.
- Create and compute a payslip for this employee.

### **Observed Behavior:**
 Worked Day lines are not generated, and Basic Wage is calculated as 0.

### **Expected Behavior:**
Worked Day lines should be populated based on attendance records.

### **Root Cause:**
During payslip computation, [_compute_worked_days_line_ids](https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1846) only generated work entries for versions having a `resource_calendar_id`  at [1]. As a result, fully flexible employees without a working schedule were excluded from work entry generation, preventing worked day lines from being computed.

[1]- https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1890-L1898

### **Fix:**
Remove the `resource_calendar_id` filter when calling `generate_work_entries` in `_compute_worked_days_line_ids` so work entries are also generated for fully flexible employees using attendance-based work entries.

**opw-6146452**

**Step to reproduce :**

1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.

**Issue :**

Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.

**Reason :**

The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24

After the fix introduced in:
https://github.com/odoo/odoo/pull/248215

However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
    
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
    
**Solution:**
    
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.

opw-6210411

Forward-Port-Of: odoo/odoo#265740