The aim of this commit is improving the design of external value in accounting reports.

Before this commit, user has to click on the pencil/edit icon to open a popover to allow him to edit the value. Once the value edited, the user still has to "Post" the value by validating it via a button.

Now, the user can edit the value in place (no more popover) and the value is automatically saved when we leave the focus on the field.

This commit also introduces an easier way to edit the boolean figure_type for external value.
Before this commit, still in the popover, the user has to choose between 2 radio buttons (Yes / No).
Now, it's easily editable by clicking on the value or on the pencil / edit icon.

Finally, this commit introduces the possibility to have editable date or datetime figure_type. To do that, we are using the hook useDateTimePicker which allows us to custom the behavior of the DateTimePicker.

To achieve this transformation, we decided to separate the logic in 4 different components.
- AccountReportLineCellEditable: which is the component you have to call when you want to allow an external value editable. This is the conductor of how things should work.
- AccountReportLineCellEditableBoolean: To easily handle boolean figure_type.
- AccountReportLineCellEditableDateTime: To easily handle date and datetime figure_type.
- AccountReportLineCellEditableLiteral: To easily handle integer, string, float and monetary figure_type.
NB: This component doesn't have the best name for it, but it's to avoid one component per figure_type.

no task id

*: stock_barcode, stock_barcode_picking_batch

- Currently, in the `Barcode App` tab under `Manufacturing operation` type, certain settings such as `Destination location`, `Force destination for all products`,  `Group batch lines` and `Move Entire Packages` have no impact in MO and can be made invisible, as their lack of effect may confuse users about their usage.

- `Source location` and `lot/serial` scan validations were incorrectly applied to `by-products`, which are produced at `Production location` and don't require such scanning. This made by-product lines non-editable in the barcode, reducing usability for byproduct processing. Barcode interface for by-products lacked automatic lot generation, requiring users to manually create the next available lot, resulting in a slower and less efficient process.

- Also, if a line has a reserved lot from the backend and another existing lot is scanned, it is applied correctly. However, when a `new lot/serial` is scanned even with `use_create_components_lots` enabled, the system falls back to the originally reserved lot from the backend, which leads to incorrect behavior. With this change, scanning a new lot clears the existing reserved lot and applies the scanned value instead. This ensures accurate lot assignment, improving traceability and reliability during barcode operations.

These changes hides irrelevant settings for MRP operations, refines the field label `(Product → Component)` specifically for mrp operations, prevents incorrect `source location` and `lot/serial scan` validations from affecting `by-product lines`, and adds direct `lot generation` for by-products in the barcode screen , and ensure that generated or scanned lot names are visible in the MRP form view, as the previous compute logic was always hiding the lot name even when it was set. These updates reduce confusion and make the mrp barcode workflow smoother and more efficient, especially for by-products.

TaskID-4655907

This commit fixes a test after changes in PR: https://github.com/odoo/odoo/pull/232855

Before the community PR:
When creating a PO for a vendor with a negative quantity for a product, it creates an OUT picking with that same quantity to the vendor as a return which is correct. However, it also creates an empty IN picking which is not needed.

After the community PR:
Only the OUT picking is created for the order lines with negative quantity as a return and if there are order lines with positive quantity, it creates a normal IN picking as expected.

Why this fix:
Before the changes, when confirming a PO, a picking was created and then moves were created an assigned to the picking, that led to having `move.partner_id` to be None when it should be the same as `picking.partner_id` (in case of not dropshipping). This is because `move._compute_partner_id()` is not triggered as the moves is created after the picking.

But after the changes, moves are created first and then a picking is created, this triggers `move._compute_partner_id()` properly and sets `move.partner_id` to be equal to `picking.partner_id`, so this test was changed accordingly to not expect None for the `move.partner_id`

Community PR: https://github.com/odoo/odoo/pull/232855

Task-5074899

[FIX] documents_account: sync all XML documents for account moves

Before this commit, the synchronization between accounting attachments and
the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol).

This caused several specific issues:
1. When creating an invoice via the Accounting upload interface, only the
   generated PDF was synced to the correct Documents folder, leaving the
   original XML file unsynced.
2. When creating an invoice from an existing file in the Documents app
   (via server action), the system correctly synced the generated PDF,
   but failed to move or sync the original XML source file to the
   target folder.
3. When receiving vendor bills via Peppol or other EDI networks, the proxy
   attaches the fetched XML to the `account.move` via an `ir.attachment` 
   write. Because this bypassed the existing sync filters, the Peppol XMLs 
   were never pushed to the Documents app.

This commit updates the `ir.attachment` logic in both `create` and `write`.
It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`)
is attached to an `account.move`—regardless of the move type or whether it 
was uploaded manually or fetched via EDI—the document synchronization logic 
is triggered, properly linking and filing the XML alongside the PDF.

Task-5909245
Task-5917535

Forward-Port-Of: odoo/enterprise#111961
Forward-Port-Of: odoo/enterprise#106574

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#111448
Forward-Port-Of: odoo/enterprise#105115

Problem: For expense created from stripe payment, OCR overwrites the data
fetched from stripe.

Solution: Skip OCR for expense created from stripe payment and put a log note
explaining the same.
***
Purpose: One language may have been set on employee, but that employee may be
using any other language in his environment, in that case user should see
chatter messages in language from his environment.

Before this commit: expense refusal message in chatter used employee's language.
After this commit: expense refusal message in chatter uses language of user
related to employee.
***
Problem: Expense Digitalization (OCR) setting is not properly applied.

Steps to reproduce:-
- Create a new database with demo data and install `hr_expense_extract`.
- Switch to `My US Company` and create an employee for that company.
- In expense settings set Expense Digitalization (OCR) to Digitize on demand
only.
- Create an expense for above created employee and attach receipt.
- Expense is digitized automatically.

Cause: Here https://github.com/odoo/enterprise/blob/d8acbf22fec266ff7d5dcc9499543e6bea3c1325/hr_expense_extract/models/hr_expense.py#L43
`self.env.company` gives that user's default company instead of currently active
company in company selector.

Solution: Use `company_id` set on expense to determine Expense Digitalization
setting.
***
task-5712223

Forward-Port-Of: odoo/enterprise#106261

Currently, an error occurs when a user starts a new pay run.

Steps to Reproduce:

 - Install `l10n_hk_hr_payroll_empf` module with demo data. 
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Payslips` > `Pay Runs`.
 - Click `New`, remove the `period value`, and click `Continue`.

`TypeError: value.toFormat is not a function`

After this recent [commit] that changed the required field validation behavior, when the 
date field is empty and it attempts to serialize the date [1], which raises the error here [2].
Although the start and end date field is required, the ORM call is executed without the 
value for the date field.

This commit ensures that, similar to the base PayslipBatchFormController [3], the fields 
are validated before making the ORM call.

[commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8

[1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14

[2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536

[3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20

sentry-7207509338

Forward-Port-Of: odoo/enterprise#108885

The interaction for filling the dynamic content of dynamic snippets
did not run inside the iframe to preview the snippet to add. This is
not an issue for the initial dynamic snippet, as they are filled with
fake content. But when saving a custom snippet, the dynamic content is
cleared, and they seem empty when previewed. This is the case since the
[website builder refactor] as the previous builder re-used the preview
of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview
iframe, and changes the interaction to avoid emptying the fake content
from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part
(there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5427353

Forward-Port-Of: odoo/enterprise#110872
Forward-Port-Of: odoo/enterprise#108912

## [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>

Forward-Port-Of: odoo/enterprise#110804

The bank reconciliation view was freezing on large databases (50k+ invoices,
90k+ journal entries), making it impossible to expand lines, filter, or interact
with the view in any way. Attempting to open a line would sometimes result in a
timeout.

**Root cause:** The `reconciledLineName` getter was called multiple times per
render cycle — once in `t-foreach` and again in the `t-if` condition. Since OWL
re-evaluates the template on every reactive state change, this created an O(n×m)
computation loop (n renders × m statement lines) that overwhelmed the browser.

**Fix:** Cache the result in OWL reactive state via a dedicated
`_computeReconciledLineName()` method, called once on setup and reactively via
`useEffect` when `line_ids.records` changes. The template is updated to store
`Object.entries(reconciledLineName)` in a `t-set` variable to avoid rebuilding
the array on every iteration.

| Metric | Before | After |
|---|---|---|
| Longest blocking task | 15 091 ms | 5 118 ms |
| Total blocking time | 74 147 ms | 22 481 ms |
| Avg. click response | 2 163 ms | 28 ms |
| Max click response | 14 305 ms | 222 ms |
| Total microtasks executed | 9 917 | 32 484 |

opw-5879798

Forward-Port-Of: odoo/enterprise#111059
Forward-Port-Of: odoo/enterprise#107135

To reproduce the issue:

- Setup tax periodicity to "trimester"
- Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example)
- Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester
- Open the report for the second month of the trimester => The line has value 42, while it should have 1.

This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong.

Forward-Port-Of: odoo/enterprise#111721
Forward-Port-Of: odoo/enterprise#110504

This task provides corrections and follow‑up work related to PR IMP #104599.

## Expected Behavior After This Commit
1. Renamed the stat buttons in the Project form view to make their purpose clearer.
2. Corrected breadcrumb generation when accessing the Project form view from the top menu.
3. Adjusted the project update form view to remove excessive padding.
4. Added a graph to the project update view to visualize project progress over time.
5. Updated filters in the margin search view.
6. Improved billable type labels for better user clarity.
7. Ensured billable types are updated correctly when sale_timesheet is installed.
8. Added navigation from analytic lines to their parent record in the margin list view.
9. Added three colors (gray, green, red) to the Milestone stat button.
10. Improved the kanban view of projected margins.

## Additions

### Point 2 — Breadcrumb Fix
When navigating from the top menu to the Project Overview, breadcrumbs were not generated correctly. To resolve this, a multi‑step flow was implemented:

- Clicking the "Overview" button triggers the action `project_embedded_action_project_overview`.
- This action calls the Python method `action_open_project_form`, which then triggers the client action `project_top_menu_overview`.
- The client action uses the `doAction` service to open the Project form view.

This approach is required because:
- Breadcrumbs are generated correctly only when `doAction` is executed inside a client action.
- The "Overview" button cannot directly trigger a client action, making the Python intermediary necessary.

### Point 7 — Billable Type Synchronization
The `sale_project` module defines the `billable_type` field on `account_analytic_line`, including the generic types *Other Revenues* and *Other Costs*. The `hr_timesheet` module adds additional, more specific billable types.

A problem occurs when:
- `sale_project` is installed first, causing analytic lines that should belong to `hr_timesheet` billable types to be incorrectly classified under *Other Revenues* or *Other Costs*.
- When `hr_timesheet` is installed afterward, these analytic lines are not automatically updated.

This fix ensures that potentially misclassified analytic lines are corrected when both `hr_timesheet` and `sale_project` are installed.

## Task :
task-[5955934](https://www.odoo.com/odoo/project/4105/tasks/5955934)

Forward-Port-Of: odoo/enterprise#109492