Currently, editing a posted `miscellaneous` journal entry in Chile 
localization incorrectly raises a validation error.

**Steps to reproduce:**
- Install the `l10n_cl` module and switch to the `CL company`.
- Go to Accounting > Accounting > Journal Entries.
- Create a balanced entry using the `Miscellaneous journal `and `post` it.
- Reset it to draft, modify the `name`, and try to `save` it.

**Observation:**
`Validation error`: `The DTE document number (folio) must contain only digits.`

**Root cause:**
At [1], the constraint validation is applied to all journal entries in 
Chilean companies, including `miscellaneous` journals. However, 
`miscellaneous journals (move_type = 'entry')` are not linked to Chilean 
electronic documents, so the numeric folio validation should not apply to them.

**Fix:**
This commit ensures that the validation is not raised for `miscellaneous` journal 
types by excluding miscellaneous journals from the numeric folio validation constraint.

[1]:
https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30

opw-5926773

Forward-Port-Of: odoo/odoo#248965

When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others

Steps to reproduce:
-------------------
1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B
1. Create a sales order
2. Add two units of the product to the sale order
3. Confirm the sales order
4. Open the transfer, make the transfer retrieve the product from several location with the same lot.
5. Save the transfer
6. Open the sales order in POS
7. Load the SN/lots
-> Two line of qty 1 appear for the product A but only the first one has the lot number

Additional Issue:
8. Change the number of the product for the first line to 2 and erase the second line
9. Confirm and Pay
10. Close POS
11. Open move lines for this product (Inventory>product>In/out)
-> It moves 2 product from one location (when there is only product)

Observation:
-------------
When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten.

Addition Issue :
When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297

opw-5347992

Forward-Port-Of: odoo/odoo#251270
Forward-Port-Of: odoo/odoo#243347

### Issue:
The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours.

### Steps to reproduce:
- Go to Planning app
- Create a shift for an employee from 3pm to 2am (over two days)
- The hours of the shift are displayed
- Modify the shift end to 3am
- The hours of the shift aren't displayed

### Cause:
Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c).

But as the pills are no longer truncated since 17.0, the computation of pill names is faulty.

### Solution:
We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it.

opw-5881532

Forward-Port-Of: odoo/enterprise#109217
Forward-Port-Of: odoo/enterprise#107233

### Issue:
No tax will be applied if in taxes, fiscal position is set to all.

#### Steps to reproduce:
1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case `all` will be shown in placeholder.
2- Set Domestic FP to be applied automatically, and set the country to `US`.
3- Create a Partner with `US` country_id.
4- Create a product, and apply the created tax to sale taxes.
5- Create a SO with created partner and the created product.
6- As you see, the tax is not applied to the line, while if you check SO's fiscal position, it is set to Domestic.

Expected: As tax's fp is set to all, we expect this tax being applied with Domestic fp.

### Cause:
In this line, if no `tax_ids` is set, it means fp has not tax_ids:
https://github.com/odoo/odoo/blob/0c3ae7f78d313885984c99a4e57485d9660dd974/addons/account/models/partner.py#L154-L158

However, this might also mean the tax has no fp because `fp.tax_ids` is a Many2Many relation.

In the forms, `tax.fiscal_position_ids` being empty is shown as `all` in the placeholder, which means when no tax applied to fp, we expect all taxes to be mapped.

### Fix:
This can be fixed by making sure the fp.tax_ids is not empty because there is no `tax.fiscal_position_ids` set.

### Remark:
In this fix we rename `TestInvoiceTaxes._create_invoice` to `_create_invoice_taxes_per_line` to avoid override of `AccountTestInvoicingCommon._create_invoice`. This is already done on saas-19.1+.

opw-5463245

**Problem:**
When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) returns incorrect results.
When the filter is 'set' it returns all records (even the ones without an analytic distribution) and when the filter is 'not set' it returns no records (even the ones without an analytic distribution).

**Steps to reproduce:**
1) Go to Accounting > Journal Entries.
2) Apply a filter for Invoice lines > Distribution Analytic Account.
3) Select "is set" or "is not set".
4) Check records.

Issue is also reproduceable on Purchase Orders.

**Cause:**
The `_condition_to_sql` method correctly converts '=' and '!=' operators to 'in' and 'not in', but there is no handling for when the value is [False], so it results in an invalid Query.

**Solution:**
- We need to handle the case when we have False in the value on it's own.

opw-5478688

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

Forward-Port-Of: odoo/odoo#247777

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.


opw-4879481

Forward-Port-Of: odoo/odoo#251002
Forward-Port-Of: odoo/odoo#245741

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.

Forward-Port-Of: odoo/enterprise#108937
Forward-Port-Of: odoo/enterprise#105521

Issue:
Sending PUE payments to CFDI/SAT is no more suitable

Step to reproduce:
- In a Mexican company
- Create an invoice (Invoice A)
- Add a line
- Set Payment Terms to "Immediate payment"
- Confirm
- Duplicate (Invoice B)
- Confirm
- Duplicate again (Invoice C)
- Set Payment Terms to "30 days"
- Confirm
- Go to Invoice A
- Pay it. It should appear as "Paid"
- Send it to CFDI
- Go to Accounting > Customer > Invoices
- Select Invoice B and C
- Pay and select the "Group Payments". They should appear as paid.
- In every invoice, click the "Update Payment" button

Current behavior:
- In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI
- In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C

Expected behavior:
- It shouldn't be possible to send payment for invoice A to CFDI.
- Payment for invoice B shouldn't be sent to CFDI

Cause:
Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI.

Solution:
Disable the force sending to CFDI

About tests:
l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess.

opw-5381600

Forward-Port-Of: odoo/enterprise#109105
Forward-Port-Of: odoo/enterprise#104628

Issue
=====

The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors.

Steps to Reproduce
==================

1. Install `industry_fsm_sale` and `l10n_br`.
2. In the US company:
   - Create a Brazilian customer.
   - Set a fiscal position on the customer.
3. Switch to the Brazilian company:
   - Open the same customer.
   - Set a fiscal position on the customer.
4. Still in the Brazilian company:
   - Create a task for that customer in the Field Service app.
   - Add a product to the task.

Result
======

An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company.

Root Cause
==========

When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company.

Solution
========

Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used.

opw-5270522

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

Forward-Port-Of: odoo/odoo#250115
Forward-Port-Of: odoo/odoo#249482