After this commit 1e702a5, a bug in the invoice form view appeared that made it difficult (to not say impossible) to reset an invoice or do any operation that involves to save the invoice.

How to reproduce (there are multiple ways but this is the easiest): 
1.- Using mx demo company INNOVACION y DESARROLLO SA de CV 
2.- Create an invoice with INMOBILIARIA CVA as contact 
3.- Post the invoice
4.- Try to send or do a modification and save
5.- Missing required fields notification will appear.

This error happens since the payment way is required if the payment policy is PUE but is not editable when not in draft, causing this deadlock.

There multiple ways to fix this, but the simplest way and maintaining the flexibilty on the user to decide what value to use, we keep the logic on the view but make the payment method editable until the invoice is sent to the SAT just like with the payment policy.

target: saas-19.2 -> master
task-5962060

Forward-Port-Of: odoo/enterprise#108378

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#108197
Forward-Port-Of: odoo/enterprise#100749

__

## Short functional explanation of the error
Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours.

As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours.

## Reproduction Steps
1. Go to Planning. Click on Configuration tab > roles.
2. Create a role and add an employee as a resource This employee has to have a fixed working schedule.
3. Click on Configuration tab > Shift Templates.
4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created.
5. Click on Schedule tab > By resource and click on New.
6. Select the role you just created.

### Expected behavior
The start and end hours should align with the shift template start and end hours.

### Unexpected behavior
The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36.

## Origin of the issue
We kept computing the working intervals of employees, even if a shift template was set:
https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule.
__
opw-5898509

Forward-Port-Of: odoo/enterprise#108412
Forward-Port-Of: odoo/enterprise#107018

Steps to reproduce:
- Set up a Company with BR localization
- Create a product as follows:
  - [General Information] Product Type: Service
  - [Sales] LC116 Code: 14.01
  - [Sales] Purpose of Use: Not applicable
  - [Sales] Service Code Origin: 14.01.3/168061/1524
  - [Sales] Service Codes: 14.01.3/168061/1524
- Create an Invoice with Document Type "Electronic Service Invoice - NFS-e"
- Add the product on the line
- Compute taxes
- Compute taxes again

Issue:

Action will be blocked by a validation error resulting from the external
taxes call
```
odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice.
Errors: Rejection: Total Installments doesnt match Total Lines
∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0
```

It occurs because during the call the system is considering the
existing taxes on the line and it will send to the avatax service wrong
amounts

opw-5412456
opw-5409735

Forward-Port-Of: odoo/enterprise#108403
Forward-Port-Of: odoo/enterprise#108088

### Issue:
Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong.

### Steps to reproduce:
- Have an employee with a calendar in "Europe/Brussels" and working from 8 to 17
- In planning add a line for this employee
- Display the gantt view on a day
- Create a shift for this employee from 8 to 17
- In the "Total" row, the first hour is not counted

### Cause:
To compute the values displayed in the Total row, we take the intersection of the shift and the working hours from the calendar. ([src](https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L318)) But the working hours from the calendar are given in UTC for this computation (without conversion), this result in a discrepancy between the actual hours of the calendar (with timezone conversion) and the one given to compute the total row.

### Solution:
`resource_work_intervals()` returns the work intervals with the calendar hours and the resource timezone.

In our case, only the hours are interesting (the previous code replaced the timezone by UTC). We need to convert them from the calendar timezone to UTC. So the first thing to do is remove the timezone from `resource_work_interval` then we localize it in the calendar timezone and to finish we convert it to UTC.

opw-5564749

Forward-Port-Of: odoo/enterprise#108669
Forward-Port-Of: odoo/enterprise#106891

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#108563
Forward-Port-Of: odoo/enterprise#100142

This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper.

18.3-:
https://github.com/odoo/enterprise/blob/ce67bf6fb4f694c25785580fe3ed290bcb8c92b5/account_reports/data/pdf_export_templates.xml#L151-L154

18.4+:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/account_reports/data/pdf_export_templates.xml#L159-L160

This broke `l10n_be_reports` which uses `(//div[hasclass('row')])[last()]` to inject BE-specific fields:

https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/l10n_be_reports/data/tax_report.xml#L9-L24

Without the wrapper, `[last()]` targets the conditional `aml_ir_filters` row instead, making BE fields invisible.

Steps to reproduce:
1. Create a Belgian company
2. Navigate to Accounting → Reporting → Tax Return
3. Create a VAT Return and submit it
4. Check the generated PDF in the attachment

=> The "Ask Restitution" and "Client Nihil" fields are missing from the PDF header.

Ticket [link](https://www.odoo.com/odoo/action-4043/5509725)
opw-5509725

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

Forward-Port-Of: odoo/enterprise#107519

Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback

Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.

To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.

After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.

This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4

If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
    order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```

Those two last issues are solved by not syncing the data to the server when we simply print the bill early.

-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt

Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.

We backport this fix that enables basic receipt printing and alter it to also work with early printing.

Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97

There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.

There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.

opw-5387572


Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />

Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />

Forward-Port-Of: odoo/enterprise#108234
Forward-Port-Of: odoo/enterprise#105511