**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
   - Name: ICBPER
   - Amount type: Fixed
   - Code: ICBPER
   - Amount: 0.5(e.g.)
   - Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).

**Issue:**
Processing the invoice raises:
    AttributeError: 'dict' object has no attribute '_get_downpayment_lines'

**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.

During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
  - With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
  - With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
 
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.

**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error

**opw-5809939**

Forward-Port-Of: odoo/enterprise#108638

## [FIX] planning_field_service*,worksheet: fixes follow-up

This commit fixes and improves field service feature in planning to be
sure to not have any regression compared to the previous field service
app.

In detail, this commit will:

- better handle SOL generation
- fix buttons visibility, display name, multi-company issues
- fix mix up demo and data
- auto install when sale timesheet and field service
- display the first slot for today in the stat button
- handle multi-company issue in slot conflicts
  Make partner phone readonly if no Contact access. Hide the Serial/Lot products
  from the shift catalog if the user has no inventory access
- display view itinerary label in mobile
- set role in field service product
- fix the domain of SO stat buttons related to shifts
- fix the default groups of "Planning By ..."" actions.
- use a custom search view for 'resource_ids' in kanban of shifts
- ask to switch in employee portal
- hide by default some fields in list view of shift
- avoid recomputing when a worksheet property changed
- display message to design worksheet in desktop only
- display plan intervention in ticket
- recompute allocated hours when break time changed
- rename Publish & send button into Publish in form view of
  planning.slot model
- display full form in my planning only

## [FIX] planning: manage state in copy_data

Before this commit, when the shift is duplicated, the state is not reset
as expected.

This commit sets copy=False on state field of planning.slot model, to
handle that in copy_data when the shift is splitted because in that case
we want to keep the state instead of resetting it.

## [FIX] planning: display notification error when save as template a template

Before this commit, since the Save as template button is in the cog
menu, it is still displayed even if shift has already generated a shift
template.

This commit will display a notification in the action of that button
when there is already a template linked to that shift.

## [FIX] planning: display planned dates in display_name when empty

Before this commit, the display_name of a shift could be empty and
displays "Unamed" in the breadcrumb due to project, task, customer
and role can be unset on the shift.

This commit will display the planned dates of shift when the other
fields used in the compute of display name are unset. However, the
planned dates are not displayed in the display name if the view is gantt
or calendar because the planned dates are already displayed and would be
redundant.

## [FIX] worksheet: hide section when separator is folded

Before this commit, when the definition of a worksheet defines 2
sections folded by default with some properties inside of each one and
the worksheet template is used for a shift, if the user just unfolds one
section to fill in just this one and lets the other section unfolded,
then the properties in the both sections are displayed in the portal of
the shift even if the second section is folded. The reason is because
the value of the second separator is not in the properties of the shift
because it is untouched.

This commit checks if the separator is by default folded if its value is
not in the properties of the shift.

task-6020304

Co-Authored: Xavier Bol (xbo) <xbo@odoo.com>

An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation

Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```

Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown

Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.

Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.

target: saas-18.4
task-6034836

Forward-Port-Of: odoo/enterprise#111007
Forward-Port-Of: odoo/enterprise#110568

Currently, when a user creates a Sale Order for MTO products that share the same component (which itself has a BOM), the system does not create a separate child MO for each manufacturing order.

## Steps to produce:
- Install Sales and Manufacturing
- Go to Settings and turn on Replenish on Order (MTO).
- Create products 'Wooden Arrow' and 'Wooden Rod' with a BOM that includes:
   - 'Stick', which itself has a BOM with 'Raw stick'.
- On each product page, go to Inventory and enable the MTO route, except for 'Raw Stick' .
- Create a Sale Order for Wooden Arrow and Wooden Rod for Customer 'Administrator'.
- Confirm the Sale Order.
- Go to Manufacturing > Open and check both Manufacturing Orders.

## Observed Behavior:
Currently, the manufacturing order for 'Wooden Arrow' has a child MO, but the order for 'Wooden Rod' does not.

The child MO under 'Wooden Arrow' produces two sticks at once. However, each manufacturing order should have its own separate child MO so that every item is produced and tracked individually.

## Root cause:
The issue happens because when a Sale Order is confirmed, [_run_manufacture](https://github.com/odoo/odoo/blob/7c7c6663e28974834d1569b27605f6ce400c7b16/addons/mrp/models/stock_rule.py#L81-L120) is called. This method creates a new MO or updates an existing one based on the domain returned by `_make_mo_get_domain` [1].

For 'Wooden Arrow' and 'Wooden Rod; new MOs are created because no existing MO matches their BOM ID, product ID, or reference.
They are added to `new_productions_values_by_company` [2], which is then used to create the MOs [3].

When `_run_manufacture` runs for 'Stick', it is triggered twice since both MOs require it as a component. The first time, no MO matches the domain, so a new one is created. The second time, the domain matches the existing MO (same BOM ID and product ID), so that MO is updated instead [4]. Because of this, `new_productions_values_by_company` is not filled again, and no second child MO is created.

[1]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L146-L165 
[2]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L98-L103 
[3]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L113-L115 
[4]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L105-L110

## Solution:
To resolve this issue, the domain has been tightened to include the parent production group ID. Since the parent MO’s group ID is passed through the procurement variable when `_run_manufacture` is executed for its component products, this group ID can be used to ensure the correct MO is matched.

**Why modify the existing test case?:**
With this change, in the `test_sale_mrp_pickings` test case, a new child MO for 'Stick' is created under the MO for 'Arrow' instead of modifying another parent MO for 'Stick'. The test case has been updated accordingly. (Confirmed the new behavior with CRL and TAGO)



opw-5480133

Forward-Port-Of: odoo/odoo#248229

Steps to reproduce:
1. Install `contacts`
2. Create an individual contact with a phone number
3. Try to edit the phone number on the mobile

Issue:
- Unable to edit in mobile view

Cause:
- On mobile devices, the utility buttons (Call, SMS, WhatsApp) inside the phone widget consume significant horizontal space. Due to the flex layout, this forces the actual phone input field to shrink too much, making it hard/impossible to view or edit the number.

Solution:
- Hide the text labels of the utility buttons to save space, showing only the icons
- make input's width 100% on mobile screens in partner form

<table>
  <thead>
    <tr>
      <th>Before</th>
      <th>After</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">
        <img
          src="https://github.com/user-attachments/assets/a620d417-119e-4e28-a62b-f63031e72598"
          alt="Before"
          width="500"
        />
      </td>
      <td align="center">
       <img width="500" height="354" alt="image" src="https://github.com/user-attachments/assets/6adc4c77-767d-491d-a468-8463c0f77666" />
      </td>
    </tr>
  </tbody>
</table>

opw-5489021

Forward-Port-Of: odoo/odoo#250256
Forward-Port-Of: odoo/odoo#246295

**PROBLEM**
Here is the client use case:
The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations.

**STEP TO REPRODUCE**
1. Create a fixed tax used for 'vidange/consigne'.
2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

**CAUSE**
Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice:
line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange.

After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%.
line 2: qty=-1, unit_price=0, taxes: 0%.
line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None.

When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'.
Line 2 reason comes from:
https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274

opw-5912986

Forward-Port-Of: odoo/odoo#254875
Forward-Port-Of: odoo/odoo#250413