Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year.

### **Steps to Reproduce:**
1) Install CRM without demo data.
2) From the `CRM>Configuration>Stages` make `new` stage as **'won'** stage.
 3) Create a lead with dated in the past (e.g., 30-12-2025 by changing system date)
   and with some expected_revenue.
4) Change the system date to today and move the lead to the Won stage.

Ref Video: https://drive.google.com/file/d/18OCQ4Tl6Co_oh28XNag3qjxMkXJNSMOh/view?usp=sharing

### **Error:**
`TypeError: '<' not supported between instances of 'NoneType' and 'float'`

### **Root Cause:**
When a lead is moved to a won stage, `_get_rainbowman_message` is called and computes the values for `max_{team,user}_{31,7}`. However, when the lead spans different years, the condition of SQL query at [1] fails(because 2025 != 2026) due to which SQL query return null from the MAX() Function. As a result, subsequent comparisons at [2] fail, raising an Error.

### **FIX:**
Introduce small helper method(`_is_lower_than_expected_revenue`) to ensure comparisons
across different years only happen when we have meaningful numeric values.

[1]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1218

[2]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1232

**opw-5484887**
**sentry-7026119584**

Forward-Port-Of: odoo/odoo#244938

Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.

### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B). 
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.

### **Current/Buggy Behavior:**
The contact does not appear in the search results.

### **Expected Behavior:**
The contact should be selectable.

### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.

However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].

This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.

### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.

[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896

**opw-5484611**

Forward-Port-Of: odoo/odoo#244671

This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the description.

| 19.0 and above | This PR |
|--------|--------|
| <img width="333" height="392" alt="image" src="https://github.com/user-attachments/assets/3dce73b3-0ce9-486e-b1de-f88a74e52e05" /> | <img width="313" height="381" alt="image" src="https://github.com/user-attachments/assets/25d75970-7f55-4967-87ba-3ecf5710835d" /> |

#### Steps to reproduce:
1. Go to `website_slides`
2. Create a new course
3. Go to the description tab
4. Insert a link in the description and save
5. Go to the frontend to see the courses list
6. Course cards with a description containing a link are visually broken.

While this looked like an improvement because it simplified the DOM, it was done with the assumption that the course card could not contain another link. This is, of course, not the case, as the description field
is editable by the user and can therefore contain a link. Because this is not valid HTML, the layout removes all nested links and renders them separately. Since all the classes related to the card design
are applied to that `<a>` tag, all links are rendered with a border and other styling.

This PR fixes the issue by reassigning all the card styles to the card container. We then reassign each property to the corresponding element, adapt the styles to mimic the original card design, and hide extra links
that are rendered empty. This should at least fix the layout for users.

[^1]: https://github.com/odoo/odoo/commit/f632b8a9e74a050288e3ec75a4f49ae3ecb551d6

task-5957910

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

Forward-Port-Of: odoo/odoo#249969

Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5
in Odoo), the JS sanitization process aggressively removes html attributes with
`-->`, `<style` and `<title` for security reasons (see [1]).

However `html_editor` embedded components use `data-attributes`
(`data-embedded-props` and `data-embedded-state`) to store various kind of data
as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex
and these attributes are therefore removed, which results in an Editor crash.

There are multiple reasons why such values are acceptable as is for the
`html_editor` usage:
- only `HTMLElement` instances are sanitized, never a string, therefore there is
  no `DOMParser` to trick with invalid HTML.
- values in these attributes are always/exclusively parsed as JSON strings, and
  the editor will crash if the value is not a legit JSON.
- values in these attributes are HTML escaped by the python sanitizer when the
  serialized html is sent to the server.
- values in the JSON parsed object are at worst rendered as plain text (never as
  HTML or other parsed formats).
- values in the JSON parsed object are never executed as JS (only serializable
  primitives are stored).

Therefore, the suggested solution is to encode the values during sanitization,
and decode just after, to keep the rest of the codebase simple and explicit.

[1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml

task-5960707

Forward-Port-Of: odoo/odoo#250475
Forward-Port-Of: odoo/odoo#250210

# How to reproduce
- Go to the Talen Pool sub-menu of the recuitment app
- Create a new Talent
- Click on the cog button, then on "Edit Properties"

# The problem
A not very descriptive error message is displayed

# Why
The hr.applicant model has a Properties field that allows the edition of its properties directly in the UI. This field needs to be linked to a PropertiesDefintion field in another model. In our case, that definition is in the hr.job model linked to the hr.applicant model via the field job_id. To be able to edit the properties of the hr.applicant model, it needs to be linked to a job, which is not always the case.

A fix was made in master to allow the edition of properties even when there is no job_id (https://github.com/odoo/odoo/commit/99aa75bc64ee8898a0815163603e5861c35b0b94) but that fix is not applicable to a stable version.

The fix I implemented instead hides the button when editing the properties would fail.

opw-5932666

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

Forward-Port-Of: odoo/odoo#248691

…n invoicing

**Issue:**
When generating an invoice for a subscription that contains a mix of regular products (invoiced on order) and timesheet-based services (invoiced on delivery), a traceback can occur if the timesheet service has 0 delivered quantity.

**Cause:**
During the invoice creation process, `_get_reinvoiced_analytic_lines_to_link` iterates over the newly created invoice lines to link analytic lines. It filters the linked sale order lines using `_is_line_reinvoicable()`. If the invoice only contains standard products (because the timesheet line was skipped due to 0 delivery), `so_lines` evaluates to an empty recordset. Passing an empty recordset into `_analytic_line_domain_get_invoiced_lines()` results in a traceback when evaluating the domain.

**Fix:**
Added a safeguard (`if not so_lines: continue`) inside the loop. If an invoice line does not contain any reinvoicable sale order lines, it is now safely skipped, allowing standard subscription lines to be invoiced alongside undelivered timesheet lines without crashing.

task: 5966725

*: mrp_subcontracting

Issue:
---------------------------------
When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New Production" action, only the `first serial number line` appears in the "Move" detail operations smart button.
Although all move lines are correctly created on the move, this behaviour is confusing for the user.

Steps to reproduce:
---------------------------------
1. Install the `mrp_subcontracting_purchase` module.
2. Create a serial-tracked product and its subcontracting BoM.
3. Create a PO with a subcontracting vendor and a product quantity greater than 1.
4. Confirm the PO and validate the resupply.
5. Open the receipt and click on the "Subcontracting Production" smart button.
6. Generate serial numbers for the product.
7. Validate the receipt and open the "Move" detail operations smart button.
8. Only one line (the first serial number) is shown, while the move actually contains all move lines.

Cause:
---------------------------------
When serial numbers are generated from the subcontracting MO view, or when a new MO is created using the "Create New Production" action introduced in [PR](https://github.com/odoo/odoo/pull/218377), new move lines are created without setting the `picking_id`.
As a result, these move lines are linked to the stock move but not directly to the picking.
Since the "Move" detail operations smart button relies on the picking’s `move_line_ids`, the newly created move lines are not displayed.

With this commit:
---------------------------------
The `picking_id` is now set on newly created move lines. This ensures that all move lines are directly linked to the picking, allowing the "Move" detail operations smart button to display all serial/lot lines correctly and improving traceability for the user.

And also When working with a subcontracting order, if the user opens the lot/serial number generation wizard from the subcontracting production and directly clicks 'Apply' without creating or assigning any lot/serial number, Odoo raises the following traceback:
`IndexError: tuple index out of range`
This issue has also been fixed here.

Forward-Port-Of: odoo/odoo#243988

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#108161
Forward-Port-Of: odoo/enterprise#105511

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

**Steps to produce:**
* Install `hr` with demo data
* Modify the view `report_employee_cv`  by adding `<div t-if=o.no/>`
* Print resume of any employee

**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="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" />

**After:**
<img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" />

[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/enterprise/pull/100142

opw-5167898

Forward-Port-Of: odoo/odoo#250286
Forward-Port-Of: odoo/odoo#237262

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#108438
Forward-Port-Of: odoo/enterprise#100142

Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop).

Steps to reproduce the error:
- Install ``hr_work_entry_attendance`` module with demo data
- Activate developer mode
- Create an Employee A > Settings > Set Default Ruleset in Overtime Ruleset
  In Payroll Tab, Work Entry Source: ``Attendances`` and set Contract
- Create an overtime attendance > Save > Open the Overtime Details > Unset the ``Stop(time_stop)`` > Save
- Open Employee A > Click on Work Entries smart button

Traceback:
```py
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
```

https://github.com/odoo/enterprise/blob/56c3723a925f718ba39d11cde12933542ebcd7c1/hr_work_entry_attendance/models/hr_version.py#L49-L52
When ``stop(time_stop)`` is unset in the overtime,
``ot.time_stop`` is False,
causing ``min()`` to compare a ``datetime`` with ``False``, which raises the above traceback.

sentry-7169332615

Forward-Port-Of: odoo/enterprise#103764

### Steps to reproduce the bug:
- Install mrp
- Go to manufacturing app
- Go to products -> bills of materials
- Create a new bill of material for a product
- Go to the operations tab
- No 'copy existing operations' button appears if at least one operation
 is already created

### The problem:
In version 19.0, the "Copy Existing Operations" button is missing from
the BoM operations tab when no operations have been defined yet for the
current BoM. While this feature was fully functional in version 18.4,
it became inaccessible in 19.0 to users due to a UI reorganization
introduced in commit https://github.com/odoo/odoo/commit/80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 that accidentally omitted the "Copy
Existing Operations" button. Currently, users are forced to manually
create at least one operation before they can see the option to copy
from other BoMs.

### The reason to introduce the fix:
The ability to copy operations is useful also when starting with an
empty BoM if operations in other BoM's have been already created. Since
this fix has already been implemented in version 19.1 via commit https://github.com/odoo/odoo/commit/02e837c959381523170c653da099328e9855a4e4,
this PR backports that changes to 19.0 to restore feature parity and
improve the user experience.

opw-5906667

Forward-Port-Of: odoo/odoo#250411
Forward-Port-Of: odoo/odoo#248225

**Steps to reproduce:**
- Create a DB with l10n_ar and l10n_ar ecommerce
- Go to Settings > Invoicing > Fiscal Localization
- Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package
- Create a website, and a portal user
- Add a main and a secondary address to the user using the website form in 'My Account'
- Go to the secondary address and change any field
- Click on Save Address
- Multiple errors will appear on the form (reproducible with other similar config)
(and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`)

**Issue:**
In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms.

This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]`
which try to compare recordsets with the given ids.

**Fix:**
Cast relational field to their id values to ensure they can be properly compared to the website form values.

related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252

opw-5247171

Forward-Port-Of: odoo/odoo#244532

__Before commit__
When using `makeButtonHandler`, a loading effect is applied to the
button if the handler takes more than 400ms to execute. However, if
the handler finishes sooner, the effect is still briefly added and
removed, triggering a DOM mutation.

If a button is clicked and the website builder opens immediately
after, this mutation may be recorded in the current history step
despite being unnecessary.

This causes the `design-themes` tour `theme_menu_hierarchies` to fail
in a non-deterministic way with the following warning:
"should not have any 'characterData', 'remove' or 'add' mutations in
current step when you update the selection"

__Fix__
Ensure the loading effect is never added if the handler execution
time is shorter than the debounce duration.

This fix is applied to both `makeButtonHandler` functions in the
codebase. The test case is only added for the interaction use case,
as the other instance resides in legacy code.

runbot-229803

Forward-Port-Of: odoo/odoo#248242

Before this commit, the following discuss call test may fail non-deterministically:

```
@mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window
```

This happens at the step where it checks that when inside the discuss meeting view, having another participant enable a video stream does not auto-focus the card.

The test was failing and auto-focusing the card because the simulated toggling of enabling the video stream happens before the side-effect of rendering to toggle the flag that meeting view is on. So the handling of event that video stream is toggled on was mistakenly considering outside of meeting view.

This commit fixes the issue by awaiting a `data-active` on the UI if meeting view, which ensures the rendering of meeting view is complete and store is aware of meeting view being open, before triggering the event that simulates toggling of video stream. This technique is borrowed from `DiscussApp` component that requires a similar technique to determine whether a chat window must auto-open or not, which also requires making sure the store knows precisely when `DiscussApp` is logically open.

Fixes runbot-error-240554

Forward-Port-Of: odoo/odoo#250174

### Steps to detect the bug:
  - Download stock apps
  - Enable "storage locations" settings under warehouse index
  - Change name of warehouse with a name composed only of numbers (ex. 01)
  - Create a product (with barcode number)
  - Insert a number of products available with smart button "on hand"
  - Create a new delivery for that product
  - Go to barcode app and search for the delivery you just created
  - Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
    
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.

### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
    
opw-5730199

Forward-Port-Of: odoo/enterprise#107920

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

Forward-Port-Of: odoo/odoo#248883
Forward-Port-Of: odoo/odoo#236276

__

## 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#108187
Forward-Port-Of: odoo/enterprise#107018

To reproduce
-------------
1. Install `l10n_es_edi_verifactu_pos`, and select the ES company
2. Make an order in PoS with a price less than 400, and don't invoice it.
3. Close the PoS session, then go to PoS > Orders, and select the previously made order
4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order.
5. Click invoice to invoice the order; the invoice is no longer simplified.

Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead.

The fix
-------
When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1.

Sources:
--------
Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD

opw-5343973

Forward-Port-Of: odoo/odoo#242274