### Issue:

Tldr: If a field A depends on an other computed field B and if the value of A is used in the computation of the field B, the ORM will consider that the value of A is false  (or empty record set) in the computation of B.

On the `mrp.production` model, the `product_tmpl_id` is a related non stored field:
https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L82 depending on the `product_id` field. This means that if we need to access the value of that field, we will first need to access the value of the `product_id` field. However, the `product_id` field is a computed field: https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L62-L66 So that if its value is marked as dirty in the cache at the moment we try to access the value of the `product_tmpl_id` of the we will launch a call of its compute method. This is problematic because the 'related' that launched the compute is used inside the compute method: https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L397 This is probelmatic because it would technically lead to an infinite recursion loop. So, to avoid any of these situation, when the computation of the `mrp.production.product_tmpl_id` has been started the filed has been marked as protected and is used as "False" in each of the subsequent computations:
https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/odoo/fields.py#L1295-L1299 In particular, we will compute the `product_id` of the mrp.production considering that the `product_tmpl_id` is false and we will therefore set a wrong value on the bom.

### Steps to reproduce:

Using studio, you can create a set of fields linked to the 'product.template' and `mrp.production` models and an automated rule that will force a situation where the above situation will be triggered with the following flow:
- Create a product with 2 variants.
- Create a bom for the template of these products and one bom line:
    - 1 x COMP
- Create and confirm an MO for 1 unit of variant 2.
- Change the bom line to 2 x COMP.
#### > Return to the MO and click on update bom, the `product_id` of the MO has been altered to variant 1.

The details of the set up are the following:
1. Create a new field with the following configuration: Name: x_studio_1 Model: Product Field Type: many2one Stored: True Related Model: res.partner
2. Create a new field with the following configuration: Name: x_studio_2 Model: Manufacturing Order Field Type: char Stored: True Readonly: True Related Field Definition: product_tmpl_id.x_studio_1.name
3. Create an automation rule on the manufacturing order model that trigger on save and that trigger's the action of updating the record responsible to Joel willis.

### Fix:

We should not rely on the related field `mrp.production.product_tmpl_id` inside the compute method of the `mrp.production.product_id`. Particularly since we can access this value using the direct path to this value. This avoids any recursion issue.

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

Forward-Port-Of: odoo/odoo#203956

Currently, an error can occur in `_find_matching_po_and_inv_lines` when some invoice lines have a price_unit of 0. This happens because the matching logic sorts and matches lines by `(price_unit, qty)`, leading to "Journal Items" (`line_ids`) being incorrectly matched with purchase order lines.

The issue arises because the `_find_matching_po_and_inv_lines` function checks all `line_ids`, instead of only `invoice_line_ids`. When a PO line has a price_unit of 0, it might match with a line that isn't an actual invoice line. As a result, `unmatched_lines` becomes incorrect, and it could remove a valid invoice line. Then, later, when calculating `inv_and_po_lines`, the process only considers `invoice_line_ids`. Since no matching line is found, an error occurs when attempting to delete the line (id is False).

Steps to reproduce:
1. Create a purchase order with:
   - 1 product A with price_unit = 0
2. Confirm the purchase order.
3. Upload an EDI XML bill (e.g., IT localization) with:
   - A reference to the purchase order
   - 1 product B with price_unit = 100

Since all bill lines are processed, a tax line or a payment term line might incorrectly match with the PO line, causing the error.

opw-4513869

Forward-Port-Of: odoo/odoo#197637

LATAM task 1299 / Adhoc Task 47453

---

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

Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes.

For more info about the RG, go to https://servicioscf.afip.gob.ar/publico/sitio/contenido/novedad/ver.aspx?id=4448

### Current behavior before PR:

Old version of legal PDF report; we are not showing vat taxes, and summarying internal and national taxes on the tax totals

![before-print-detail-other-taxes](https://github.com/user-attachments/assets/2bc416c9-4231-42c4-8c71-fd1f5531d3d2)

### Desired behavior after PR is merged:

We add a special table at the end of the report (ask required in the RG) with the detail of the taxes group by type: vat taxes, and other internal and national taxes

![new-taxes](https://github.com/user-attachments/assets/d75ae2ad-b787-4399-a9d7-c6b3082c67ec)

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

Forward-Port-Of: odoo/odoo#203521
Forward-Port-Of: odoo/odoo#201257

Issue:
========

There is an issue during the generation of invoices from subscription that causes the is_invoice_cron field on the sale order to remain `True`. This prevents the processing of transactions and, as a result, does not mark the invoices as paid. Furthermore, this issue blocks the generation of subsequent invoices.

To reproduce:
=============

1. Create a subscription that does not require initial client payment, (can generate an invoice on the next invoice date).
2. Create 30 other subscriptions (equal to the batch size value) that cannot generate invoice until the client has made a payment.
3. Run the scheduled action “Sale Subscription: generate recurring invoices and payments.”
4. You will notice that the first Sale Order remains to “is_invoice_cron” as True

Problem:
========
the condition to trigger the cron to invoice subscriptions is based on the number of subscriptions that can be invoiced in a batch. But we are taking all the subscriptions while it should be only the subscriptions that can be invoiced.

Solution:
=========
filter the subscriptions that can be invoiced before checking the condition to trigger the cron to invoice subscriptions.

opw-4559250

Forward-Port-Of: odoo/enterprise#82340