Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.

Enterprise PR: https://github.com/odoo/enterprise/pull/112654

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

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

Forward-Port-Of: odoo/odoo#272112
Forward-Port-Of: odoo/odoo#256932

Issue:
------
`l10n_pe.address_form_fields` inherits from `portal.address_form_fields` but targets a `<div>` element that has been moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2].

Traceback:
----------
```py
Error while rendering the template:
    ValueError: Element '<div id="div_city_id">' cannot be located in parent view (view: l10n_pe.address_form_fields)
    Template: website_sale.address
    Reference: 1973
    Path: /t/t/div/div/form/div/t
    Element: <t t-call="website_sale.address_form_fields"/>
```

Steps to reproduce:
-------------------
1. Install `l10n_pe` and `website` in v19
2. Upgrade to v19.2
3. Go to the website and add a product to the cart
4. Go to checkout → Traceback

Root cause:
-----------
The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile.

Solution:
---------
Update the `inherit_id` of `l10n_pe.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element.

opw: [6302145]

[saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73#diff-83bb066f4477532b76aadd957ae736d0c0b67bc66b48d6f47c035e8cfb4773deR7-R21
[6302145]: https://www.odoo.com/odoo/70/tasks/6302145?debug=1

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#271246

In POS Restaurant with Germany Fiskaly enabled, splitting and paying from a table works once, but repeating the same flow from the Orders tab lets the parent order show lines that were already paid in previous splits. Functionally, the cashier can keep splitting and paying the same line again and again because the parent draft order is not updated consistently in that path.

Steps to reproduce:
-------------------
* Enable POS Restaurant with l10n_de Fiskaly
* Create a table order (e.g. 3 meals + 3 drinks)
* Open Split Bill, move 1 meal + 1 drink, and pay
* From Orders tab, open the remaining parent order and repeat split + pay
* Reopen the parent order from Orders tab

> Observation:
The parent order still contains quantities that were already split/paid, so the same items can be paid multiple times from the Orders tab.

Why the fix:
------------
The Fiskaly `syncAllOrders` override diverged from core sync behavior in the split flow: it ignored explicit `options.orders` and did not await transaction creation for inactive transactions. In the split-bill path this could skip or desynchronize parent-order updates, leaving stale quantities on the parent order.
The fix restores expected sync semantics by honoring `options.orders` and awaiting transaction creation before deciding sync eligibility.

opw-6175880

Forward-Port-Of: odoo/enterprise#117206