**Steps to produce:**
- Install `sale_subscription,website_sale` module.
- `Subscription > Configuration > Recurring Plans`.
- `Archive` the `Monthly` plan.
- Go to website > Shop > Open product `Car Leasing (SUB)`.

**Issue:**
- Even after archiving the Monthly recurring plan, its pricing still appears on the website product page.

**Root cause:**
- At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans.
- As a result, inactive plans are still considered during pricing selection.

**Solution:**
- In this fix, we ensure that recurring plan pricing is included only if the related plan is active.
- Archived plans are now ignored, preventing them from appearing on the website.

[1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79

before
<img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" />

after
<img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" />

**opw-5266333**

Forward-Port-Of: odoo/enterprise#103473
Forward-Port-Of: odoo/enterprise#100587

### Issue:
When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs.

### Steps to reproduce:
- Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step)
- Refuse all time off for "Anita Oliver" (to avoid side effect in next step)
- Create a user for the employee "Anita Oliver"
- Link the employee and the user
- Create 2 payslips
	- 1 for "Mitchell Admin"
	- 1 for "Anita Oliver"
- Compute sheet and confirm both payslips
- Run scheduled action: "Payroll: Generate pdfs"
- Nothing happens

### Cause:
The traceback is raised on the line `self._get_document_partner().id`
 because `_get_document_partner()` can return a recordset.

### Solution:
Call `ids` instead of `id`.

### Note:
Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`.

The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86).

opw-5213979

Forward-Port-Of: odoo/enterprise#103749
Forward-Port-Of: odoo/enterprise#101911

Fix an incorrect flow when creating a Manufacturing Order through the Barcode app.

Steps to reproduce:
- Disable tracking in Settings
- Create a BOM for product Table with components Wood and Screws
- In the Barcode app, go to Manufacturing
- Click New > Add product and select Table
- Click Confirm -> Components are not added after the Table line

The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected.

This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`.

This fix ensures that `lot_producing_id` is defined before performing the comparison.

opw-5165163

Forward-Port-Of: odoo/enterprise#103849
Forward-Port-Of: odoo/enterprise#98440

The scheduled action responsible for generating recurring invoices (`_create_recurring_invoice`) can enter an infinite loop, repeatedly rescheduling itself and consuming server resources without making any actual progress.

### Reproduction Steps

1. Create a single subscription in the "In Progress" stage.
2. Ensure the subscription meets a condition that causes it to be skipped during invoicing (e.g., it has a draft invoice linked but no payment token).
3. Run the "Sale Subscription: generate recurring invoices and payments" cron.
4. Observe that the cron completes but is immediately rescheduled by the system, repeating the cycle indefinitely.

### Root Cause

The Odoo cron mechanism uses a progress tracking system to handle large batches of records. When a job starts, it initializes a `remaining` counter representing the total workload. As records are processed, the job is expected to report its progress to decrement this `remaining` count. If a job finishes with `remaining > 0`, the system assumes the batch was interrupted (e.g., by a timeout) and immediately reschedules the job to complete the unfinished work.

In the `sale_subscription` module, the `_create_recurring_invoice` method initializes this counter and iterates over subscriptions. It relies on a helper method, `_subscription_commit_cursor`, to commit the transaction and report progress (decrementing `remaining`). However, inside the processing loop, several conditional checks (such as filtering out subscriptions with existing draft invoices) use the `continue` statement to skip the current record. These skip branches bypass the `_subscription_commit_cursor` call.

Consequently, the `remaining` counter is never decremented for these skipped records. The cron finishes with a positive `remaining` value, leading the system to incorrectly flag the job as "partially done" and reschedule it indefinitely.

### Fix

Update the loop logic to ensure `_subscription_commit_cursor(auto_commit, progress=1)` is called in all execution paths, including those where a subscription is skipped via `continue` or where an exception is handled. This ensures that every inspected subscription is accounted for in the progress tracking, allowing the `remaining` counter to correctly reach zero and preventing unnecessary rescheduling.

opw-5137931

Steps to reproduce:
- With a PE Company setup
- Create an Invoice with "Document Type" set to "(01) Factura"
- Set a discount on the invoice line
- Confirm and send for validation
- Create the credit note
- Confirm the credit note and send for validation

Issue:

Credit note validation will fail with error
`3271|El valor de venta por ítem difiere de los importes consignados. -
Detalle: xxx.xxx.xxx value='ticket: 1767185167086 error: Error en la
linea: 1: 3271 (nodo: "cac:CreditNoteLine/cbc:LineExtensionAmount"
valor: "600.00")'`

This occurs because while UBL standard allows AllowanceCharge in credit
notes, SUNAT does not.
Credit notes are treated as pure amount adjustments, not price recalculations.
Discounts were already applied in the invoice, so SUNAT ignores
AllowanceCharge in CN, causing error 3271.

With this commit we introduce a check to ensure users won't post edi credit
or debit notes containing line discounts

opw-5414766

Forward-Port-Of: odoo/enterprise#103106