**Steps to reproduce:**
* Install Peru - Accounting Reports (l10n_pe_reports).
* Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047).
* Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4).
* Export the TXT file and open it.

**Observed behavior:**
* Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code.
* SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes.

**Cause:**
* `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235".
* The same incorrect value was also written to field 28 (aduana_code).
* ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

**Fix:**
* For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value).
* Apply the same logic to field 28 (aduana_code) for consistency.

opw-6157662

Forward-Port-Of: odoo/enterprise#115406

### Description of the issue/feature this PR addresses: 
**Issue:** When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue.

**Solution:** This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds.

### Current behavior before PR:
A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue.

### Desired behavior after PR is merged:
The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created.

opw-6179479

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

Forward-Port-Of: odoo/odoo#266180

Steps to produce:
---
- Install `website_sale` with demo data.
- Go to `website > ecommerce > products > ecommerce categories`.
- Open `Desks/Components` category > Set website to `My website 2`.
- Open the shop page on website > Click on Desks category.

Issue:
---
- The Components subcategory is still displayed on Website 1.
- Clicking on it leads to a Not Found page since the category is not assigned to that website.

Root cause:
---
- At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access.
- As a result, categories restricted to another website are still shown.

Solution:
---
- Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed.

[1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769

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

Forward-Port-Of: odoo/odoo#266637
Forward-Port-Of: odoo/odoo#262410

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

Ticket [link](https://www.odoo.com/odoo/project.task/6217373)
opw-6217373

Forward-Port-Of: odoo/odoo#267081
Forward-Port-Of: odoo/odoo#266374

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#118131
Forward-Port-Of: odoo/enterprise#115760

## [FIX] web_gantt,planning: apply hasGroup before compute params

Before this commit, some actions like drag and drop gantt pills are
blocked for planning manager instead of being allowed only for them. The
reason is because the compute params is something made before checking
if the user is a planning manager and so the system will consider the
user is not a planning manager. The compute params is something made
before because the methods are executed inside 2 distincts onWillStart
hook and so OWL framework cannot know one hook depends on the other one.

This commit creates a method `onWillStart` in the main gantt controller
to be able to override it and be able to wait a rpc before processing
the compute params.

## [FIX] planning_field_service_sale_timesheet: don't count unscheduled intervention

This commit filters the interventions counted to display the field
service stat button in the form view of Sale Order. Now the intervention
unscheduled will no longer be counted and also the one linked to
plannable SOL.

## [FIX] planning_field_service: send email to customer when intervention published

Before this commit, the template "Field Service Scheduled" was unsused.

This commit uses that template to send an email to the customer once the
intervention is scheduled.

## [FIX] planning_field_service: send report when intervention completed and signed

Before this commit, the customer signs the intervention completed and
does not received any email with the intervention report. He has to
create an account in the DB as portal user to be able to see his
intervention or ask to contact person to send him the report by mail.

This commit will automatically send the intervention report by mail to
the customer once the intervention is completed and signed by the
customer.

## [FIX] planning_field_service: fix label and record_name in email sent for Field service

Before this commit, the button sent to the customer to see the
intervention is `View Planning Slot` and the record name used inside the
same email is the display name which is not useful for the customer.

This commit changes the label of the button displayed to see `View
Report` and change the record_name to show `Field Service -
<intervention date>` as shown in the portal view.

## [FIX] planning_field_service: no login required to access to intervention

Before this commit, the customer cannot access to the intervention
without begin log in even if he has the access token.

This commit changes the route access to let the user access to the
intervention completed and he can also sign it.

## [FIX] planning: hide duplicated name field in kanban displayed in gantt

This commit hides the duplicated name field displayed in the popover of
the gantt view in the planning.slot model.

## [FIX] planning_field_service: rename module name

This commit renames the module to call it `Field Service` instead of
`Planning - Field Service`.

## [FIX] worksheet: only show property warning message in mobile

## [FIX] planning: define employee_public_ids field in planning.slot

Before this commit, when a planning user goes to a shift he will see
Assign to me button on a shift assigned to another human resource which
is normally not allowed. The reason because the button is visible is
because `employee_ids` field is always empty for users who are not HR
user.

This commit adds `employee_public_ids` field which is also a computed
field non stored to get the employee for the user who is not a HR user.

## [FIX] planning_field_service: always compute break_time

This commit removes the default value on break_time field to always
trigger the compute of that field, the reason is because by default the
allocated_hours computed when we create a shift, will not always cover
the whole duration of the shift, the allocated hours of the shift is
computed based on the working schedule of the shift and so the
break_time field has to be computed afterwards to make sure the break
time is correctly set instead of having 0 by default when we create a
shift.

task-6060493

Forward-Port-Of: odoo/enterprise#112420

__

## Short functional explanation of the error
When rescheduling the deadline only of a task that has dependencies, other dependencies won't be moved in time, even if we select `Auto-Reschedule (Keep Buffer)`.

## Reproduction Steps
1. Go to Project. On a given project, click on the 3 dots on the top right of the project card. Then, click settings and under Task Management, check Task Dependencies.
2. Create 2 tasks for this project. On task 1, click on the Deadline field, then click on the top right of the calendar card to set a planned date.
3. On task 2, click on the Blocked By tab. Then, add a line with task 1. Select a planned date like you did with task 1.
4. Go back to the project and on the top right, click on the Gantt view. Make sure that above the calendar, the Auto-Reschedule (Keep Buffer) option is selected. Then, move forward (or backward) the deadline of task 1 by only clicking on the right edge of the pill and dragging/dropping it to the left/right.

### Expected behavior
As task 2 depends on task 1, and we need to keep the buffer. The start date of task 2 should be moved left when we drop the deadline of task 1 further left, or right when we move the deadline of task 1 further right.

### Unexpected behavior
Nothing happens.

## Origin of the issue
### JS side
When we click on the whole task 1 and drag it to the right (thus changing the start date *and* the deadline), the dependent tasks are also moved right. When performing this action, this calls the method `dragPillDrop`. In it, we can see this piece of code: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L1484-L1489 where `this.isAutoPlan` indicates whether we checked the Auto-Reschedule (Keep Buffer) option. In that case, we call `rescheduleAccordingToDependency`, which performs this ORM call: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L500

However, when only moving the deadline of the task, we call the method `resizePillDrop`. In this method, we don't check if `this.isAutoPlan` is True, as we perform in all case the call to: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L2822 Which will trigger the orm call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L479 which will call the `web_gantt_write` method in Python, only writing on the task we changed the deadline of.

### PY side
Inside `web_gantt_reschedule`, to reschedule dependent tasks, we have to reach the method call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L247 However, there's a condition preventing us from reaching that code when only changing the deadline:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L230-L235 Yet, we need to trigger the code and reschedule dependencies even if there's no planned date as soon as we change the deadline.

Once we're in `_web_gantt_action_reschedule_candidates`, we check if we're in the case of preponing or postponing the task (i.e the direction of the rescheduling):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L410 This call is performed with `start_date_field_name`, which is present in the `vals` in the case of moving a whole task. Yet, in our case, we only move the deadline, so `start_date_field_name` isn't in our `vals`. So, to get the direction of our rescheduling, we have to use `stop_date_field_name` instead.

Then, we perform this call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L412 However, in our case, the dependent tasks are still found under the `dependency_inverted_field_name` field.

This leads us to the return of the function, where we call `_web_gantt_move_candidates`. In it, we retrieve the previous values of the pill we're modifying with:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1366 using `vals`. Later we use `start_date_field_name` to update the dates of dependent tasks:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1413-L1415 Still, in our case, we don't have `start_date_field_name` in vals. Thus, we have to define `old_vals_per_pill_id[self.id][start_date_field_name]`.

Next, we define the start date and end date of the intervals in which we reschedule the dependent tasks (so, the left and right bounds of intervals):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1392-L1401 In case of a `search_forward`, this is natural. Nevertheless, in the case of a backwards search, we can't consider the start date of the first task to be the right bound for our dependent tasks, as they occur after the first task! This would mean that our right bound is set before the dependent tasks even start. So, in our case of changing only a deadline, we have to set the right bound to the latest deadline of the dependent tasks. They won't be set to later, as we are moving the deadline backward.

Finally, in the case of setting a deadline backwards, we have to keep the time gap between task 1 and the dependent tasks, based on the working hours. This feature wasn't implemented.

__
opw-6080405

Forward-Port-Of: odoo/enterprise#117815
Forward-Port-Of: odoo/enterprise#113787

Scenario:

- set menu bar as sidebar
- adds lot of menu item (or decrease page height)
- try to scroll to bottom menu item that are not shown

Result: you can't see the bottom of the menu

Cause: there is no overflow auto on sidebar elements so the default
visible is used without possible scroll. This issue doesn't happen for
hamburger menu (hamburger template or on mobile) because it wraps the
menu in an .offcanvas-body element that has in bootstrap

  overflow-y: auto

Fix: add vertical overflow to o_header_sidebar menu.

Note: also fixes the visual issue happening when setting both sidebar
menu and disclaimer by forcing the disclaimer to not be avialable if
sidebar menu is selected.

opw-5486934

---

__pr note__: I'm not sure if there is a reason this was not done yet or if this has just not been reported. The behavior happen from 16.0 to now. Since the query is from 19.0  to lower risk (and since it's not really broken, just not working with a big number of menu) I've targeted 19.0 but I could go lower if wanted.

Forward-Port-Of: odoo/odoo#252047

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

Ticket [link](https://www.odoo.com/odoo/project.task/6217373)
opw-6217373

Forward-Port-Of: odoo/odoo#267081
Forward-Port-Of: odoo/odoo#266374

Issue:
----------------------------------------
In German, using a time field with minutes breaks the parser and only the hours are taken into account.

Steps to reproduce:
----------------------------------------
- Install Timesheet and Project
- Change language to German
- Open a task, page "Timesheets"
- Create a new record
- Write "2:30" to set the time, it will work
- It won't work if you add an UoM, i.e. "2h30m", "2h 30 Min."

Cause:
----------------------------------------
In German all common nouns begin with a capital letter so their UoMs too.

In the parser we call `durationUnitsRegex` which uses a library to get the UoMs in the local language.

https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/core/l10n/time.js#L289-L298

For Germany, the abbreviations will have capital letters ("Min.", "Sek.", etc.). So there will be upper case letters in the regex.

But the string on which we call the regex is only lower case:

https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/views/fields/parsers.js#L185-L189

https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/core/l10n/time.js#L271-L277

So the regex returns no match.

Solution:
----------------------------------------
When building the regex, we call `RegExp()` constructor with "i" to ignore cases.

opw-6236787

__

## Short functional explanation of the error
When rescheduling the deadline only of a task that has dependencies, other dependencies won't be moved in time, even if we select `Auto-Reschedule (Keep Buffer)`.

## Reproduction Steps
1. Go to Project. On a given project, click on the 3 dots on the top right of the project card. Then, click settings and under Task Management, check Task Dependencies.
2. Create 2 tasks for this project. On task 1, click on the Deadline field, then click on the top right of the calendar card to set a planned date.
3. On task 2, click on the Blocked By tab. Then, add a line with task 1. Select a planned date like you did with task 1.
4. Go back to the project and on the top right, click on the Gantt view. Make sure that above the calendar, the Auto-Reschedule (Keep Buffer) option is selected. Then, move forward (or backward) the deadline of task 1 by only clicking on the right edge of the pill and dragging/dropping it to the left/right.

### Expected behavior
As task 2 depends on task 1, and we need to keep the buffer. The start date of task 2 should be moved left when we drop the deadline of task 1 further left, or right when we move the deadline of task 1 further right.

### Unexpected behavior
Nothing happens.

## Origin of the issue
### JS side
When we click on the whole task 1 and drag it to the right (thus changing the start date *and* the deadline), the dependent tasks are also moved right. When performing this action, this calls the method `dragPillDrop`. In it, we can see this piece of code: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L1484-L1489 where `this.isAutoPlan` indicates whether we checked the Auto-Reschedule (Keep Buffer) option. In that case, we call `rescheduleAccordingToDependency`, which performs this ORM call: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L500

However, when only moving the deadline of the task, we call the method `resizePillDrop`. In this method, we don't check if `this.isAutoPlan` is True, as we perform in all case the call to: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L2822 Which will trigger the orm call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L479 which will call the `web_gantt_write` method in Python, only writing on the task we changed the deadline of.

### PY side
Inside `web_gantt_reschedule`, to reschedule dependent tasks, we have to reach the method call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L247 However, there's a condition preventing us from reaching that code when only changing the deadline:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L230-L235 Yet, we need to trigger the code and reschedule dependencies even if there's no planned date as soon as we change the deadline.

Once we're in `_web_gantt_action_reschedule_candidates`, we check if we're in the case of preponing or postponing the task (i.e the direction of the rescheduling):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L410 This call is performed with `start_date_field_name`, which is present in the `vals` in the case of moving a whole task. Yet, in our case, we only move the deadline, so `start_date_field_name` isn't in our `vals`. So, to get the direction of our rescheduling, we have to use `stop_date_field_name` instead.

Then, we perform this call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L412 However, in our case, the dependent tasks are still found under the `dependency_inverted_field_name` field.

This leads us to the return of the function, where we call `_web_gantt_move_candidates`. In it, we retrieve the previous values of the pill we're modifying with:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1366 using `vals`. Later we use `start_date_field_name` to update the dates of dependent tasks:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1413-L1415 Still, in our case, we don't have `start_date_field_name` in vals. Thus, we have to define `old_vals_per_pill_id[self.id][start_date_field_name]`.

Next, we define the start date and end date of the intervals in which we reschedule the dependent tasks (so, the left and right bounds of intervals):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1392-L1401 In case of a `search_forward`, this is natural. Nevertheless, in the case of a backwards search, we can't consider the start date of the first task to be the right bound for our dependent tasks, as they occur after the first task! This would mean that our right bound is set before the dependent tasks even start. So, in our case of changing only a deadline, we have to set the right bound to the latest deadline of the dependent tasks. They won't be set to later, as we are moving the deadline backward.

Finally, in the case of setting a deadline backwards, we have to keep the time gap between task 1 and the dependent tasks, based on the working hours. This feature wasn't implemented.

__
opw-6080405

Forward-Port-Of: odoo/enterprise#117815
Forward-Port-Of: odoo/enterprise#113787

### Description of the issue/feature this PR addresses:
This PR introduces batch processing to the VAT Books ES (Libros de IVA) report generation. When attempting to export the report for periods containing a massive volume of invoices, the ORM cache continuously accumulates records, leading to severe memory consumption. By implementing batching and explicitly clearing the environment cache, use memory use will remain stable and efficient.

### Current behavior before PR:
Generating the VAT Books report loads all account move lines into memory at once. Because the ORM cache is never cleared during the iteration, RAM usage spikes continuously. On databases with tens or hundreds of thousands of invoices in a single period, this leads to significant performance degradation, worker timeouts, or complete Out-Of-Memory (OOM) crashes.

### Desired behavior after PR is merged:
The report engine now splits the recordset into manageable batches (e.g., 50,000 accounts per batch). After processing each chunk to extract the income and expense line values, invalidate_model() is called to flush the ORM cache related to the searched records. This frees up memory continuously, keeping the server's RAM usage flat and allowing the successful export of massive datasets without crashing.

### Benchmark:
The model is iterating through ~1.1M account move lines when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 385 MB | 666 MB |
| ~340,000 account move lines |1.2 GB | 1.5 GB |
| ~1.2M account move lines | MemoryError | 1.5 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 32s | 12s |
| ~340,000 account move lines | 2:29min | 1:11min |
| ~1.2M account move lines | MemoryError | 4:11min |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#116139

**Problem:**

Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date.

This introduced an unnecessary dependency chain:
```
contract_start_date -> employee_version_id -> contract_template_id -> wages and other offer fields
```

As a result, updating `contract_start_date` invalidates and recomputes the whole chain, even when `employee_version_id` does not actually change.

In addition, offer fields were coupled in a single compute, causing unrelated fields to be reset to template values when only one field required recomputation.

**Fix:**

- `contract_template_id` compute now depends on `employee_id` instead of `employee_version_id`, and directly uses the employee's `version_id`, breaking the chain while preserving default behavior.
- The offer fields computations were also split to avoid unintended recomputations and field resets.
- Simplified `_get_version` by always copying values from the template to the currently active version.
---

**Additional fix:**

The `is_hr_payroll` context flag is used to distinguish payroll vs recruitment flows when creating an offer with both `employee_id` and `applicant_id` unset.

A recent change in [Task #6094737](https://www.odoo.com/odoo/project/1251/tasks/6094737) did not account for this flag, causing both fields to be hidden when opening the form from Payroll (a new feature added in saas-19.3).

This is fixed by properly considering `is_hr_payroll`, restoring consistent behavior across all versions.

Task: 6158245

Forward-Port-Of: odoo/enterprise#115408

## Issue
When scheduling a sign request, the request appears immediately on the portal for the requested signer.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Create and send a sign request
    - Signer 1: Any portal user (e.g., Joel Willis)
    - Use the clock icon to schedule the signature request to a future date
3. Log in as the portal user used in step 2
4. Navigate to Signature Requests
5. **The signature request already appears in the list, even though it was scheduled for a future date.**

## Cause
The portal filters the sign requests shown based on the `is_mail_sent` field, which does not properly reflect when the signature request is shared to the user.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/controllers/portal.py#L40

In fact, when scheduling a signature request, the `is_mail_sent` field is unconditionally set to `True`, even if the signature request will only be sent later.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request_item.py#L289

## Fix
Since the `"scheduled"` `sign_request_item.state` option introduced by https://github.com/odoo/enterprise/commit/ed8d5a653e01b1378f0020e2f7a7c2d39fadf3e9 in 19.1, we can easily filter out the sign request items that are scheduled. That state is automatically updated by the `_cron_update_state`, introduced by the same commit as the `"scheduled"` option.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request.py#L493-L503

opw-6227472

…lit for same-product lines

When doing an intercompany Sale->Purchase with multiple lines having the same products, the receipt picking would be incorrectly assigned:
- Enable Inter-Company Transactions on both companies (Create and validate)
- Create SO in company A to company B with 2 lines having the same product P, Confirm. => Delivery in company A, Purchase and Receipts in company will be created => The SO/PO/Delivery/Receipt will all have 2 lines
- Validate delivery => On the receipt, the 2 units of P are reserved on the 1st move, and the 2nd move is not reserved.


https://github.com/user-attachments/assets/b4816051-120e-4226-9228-fd552649d5ef


---

### Test result without fix:
```
2026-04-23 13:16:44,577 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: Starting TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product ... 
2026-04-23 13:16:44,949 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: ====================================================================== 
2026-04-23 13:16:44,949 48027 ERROR oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: FAIL: TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/sale_purchase_stock_inter_company_rules/tests/test_inter_company_so_to_po.py", line 109, in test_02_inter_company_multiple_lines_with_same_product
    self.assertRecordValues(purchase_from_a.picking_ids.move_ids, [
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/tests/common.py", line 709, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'pr[18 chars]0, 'quantity': 1.0}, {'product_uom_qty': 1.0, 'quantity': 1.0}] != [{'pr[18 chars]0, 'quantity': 2.0}, {'product_uom_qty': 1.0, 'quantity': 0.0}]

First differing element 0:
{'product_uom_qty': 1.0, 'quantity': 1.0}
{'product_uom_qty': 1.0, 'quantity': 2.0}

- [{'product_uom_qty': 1.0, 'quantity': 1.0},
?                                       ^

+ [{'product_uom_qty': 1.0, 'quantity': 2.0},
?                                       ^

-  {'product_uom_qty': 1.0, 'quantity': 1.0}]
?                                       ^

+  {'product_uom_qty': 1.0, 'quantity': 0.0}]
?                                       ^

```

OPW-6145683

Forward-Port-Of: odoo/enterprise#118548
Forward-Port-Of: odoo/enterprise#114873

**Steps to reproduce:**
- Accounting > Configuration > Settings > Default Accounts > Product Accounts
- Change the default expense account (and income account)
- Create a new product category
- category still proposed the old accounts

Affected versions: from 18.2 till 19.2

**Cause:**
`ir.default` for `product.category` (`property_account_expense_categ_id` and `property_account_income_categ_id`) was not updated when `res.company.expense_account_id` / `income_account_id` changed, so new categories kept using stale defaults.

and in 19.0
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L490
and
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L753
calls
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L1136-L1139

However, when stock_account is installed

https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/stock_account/models/res_company.py#L361-L366

this gets called, without calling super, that's why it didn't work although the fix is there, we will need to adapt another fix in 19.0+

**Solution:**
Call `_set_category_defaults()` in `res.company.write()` so `ir.default` stays aligned with the company's current product default accounts.

opw-6145491

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

Forward-Port-Of: odoo/odoo#265052
Forward-Port-Of: odoo/odoo#261594

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

Ticket [link](https://www.odoo.com/odoo/project.task/6217373)
opw-6217373

Forward-Port-Of: odoo/odoo#267081
Forward-Port-Of: odoo/odoo#266374

**Steps to reproduce:**
- Install Sales app
- Create a Sales Order
- Click on the 'Send by Email' action
- Add an attachment and send it
- Open the chatter to create a log note
- Attachment is attached to the new message
- It disappears on refresh

**Issue:**
Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`.

Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers.

But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`.

**Fix:**
Restrict the attachment save to the full composer using context.

[1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027
[2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3

opw-5164504

Forward-Port-Of: odoo/odoo#266530
Forward-Port-Of: odoo/odoo#265736

**Steps to reproduce:**
* Install Peru - Accounting Reports (l10n_pe_reports).
* Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047).
* Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4).
* Export the TXT file and open it.

**Observed behavior:**
* Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code.
* SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes.

**Cause:**
* `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235".
* The same incorrect value was also written to field 28 (aduana_code).
* ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

**Fix:**
* For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value).
* Apply the same logic to field 28 (aduana_code) for consistency.

opw-6157662

Forward-Port-Of: odoo/enterprise#115406

…lit for same-product lines

When doing an intercompany Sale->Purchase with multiple lines having the same products, the receipt picking would be incorrectly assigned:
- Enable Inter-Company Transactions on both companies (Create and validate)
- Create SO in company A to company B with 2 lines having the same product P, Confirm. => Delivery in company A, Purchase and Receipts in company will be created => The SO/PO/Delivery/Receipt will all have 2 lines
- Validate delivery => On the receipt, the 2 units of P are reserved on the 1st move, and the 2nd move is not reserved.


https://github.com/user-attachments/assets/b4816051-120e-4226-9228-fd552649d5ef


---

### Test result without fix:
```
2026-04-23 13:16:44,577 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: Starting TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product ... 
2026-04-23 13:16:44,949 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: ====================================================================== 
2026-04-23 13:16:44,949 48027 ERROR oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: FAIL: TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/sale_purchase_stock_inter_company_rules/tests/test_inter_company_so_to_po.py", line 109, in test_02_inter_company_multiple_lines_with_same_product
    self.assertRecordValues(purchase_from_a.picking_ids.move_ids, [
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/tests/common.py", line 709, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'pr[18 chars]0, 'quantity': 1.0}, {'product_uom_qty': 1.0, 'quantity': 1.0}] != [{'pr[18 chars]0, 'quantity': 2.0}, {'product_uom_qty': 1.0, 'quantity': 0.0}]

First differing element 0:
{'product_uom_qty': 1.0, 'quantity': 1.0}
{'product_uom_qty': 1.0, 'quantity': 2.0}

- [{'product_uom_qty': 1.0, 'quantity': 1.0},
?                                       ^

+ [{'product_uom_qty': 1.0, 'quantity': 2.0},
?                                       ^

-  {'product_uom_qty': 1.0, 'quantity': 1.0}]
?                                       ^

+  {'product_uom_qty': 1.0, 'quantity': 0.0}]
?                                       ^

```

OPW-6145683

Forward-Port-Of: odoo/enterprise#118548
Forward-Port-Of: odoo/enterprise#114873

This commit fixes the test "waitForTimeout does not trigger update if
interaction is not ready yet", which could very rarely fail on runbot.

**Origin of the problem**
The test relies on precise timings, but the helper `advanceTime` could
introduce a non-deterministic lag because, when called with default
options, it awaits for an animation frame. If the lag happens to be too
long, the second `verifySteps` is called too late and the test fails.

**Fix**
The helper `advanceTime` is now called with the option `animationFrame`
set to false to avoid awaiting for an animation frame. For additional
safety, the waiting time is also reduced.
Two changes not directly related to this problem have been applied to
improve the test: 1. an unnecessary `await` in `willStart` has been
removed; 2. the `animationFrame` has been set to false also on the
second `advanceTime` (a non-deterministic lag here can't fail the test,
but still there is no reason to await for the animation frame).

runbot-243515

Forward-Port-Of: odoo/odoo#266432

**Steps to reproduce:**
* Install Peru - Accounting Reports (l10n_pe_reports).
* Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047).
* Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4).
* Export the TXT file and open it.

**Observed behavior:**
* Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code.
* SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes.

**Cause:**
* `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235".
* The same incorrect value was also written to field 28 (aduana_code).
* ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

**Fix:**
* For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value).
* Apply the same logic to field 28 (aduana_code) for consistency.

opw-6157662

Forward-Port-Of: odoo/enterprise#115406

…lit for same-product lines

When doing an intercompany Sale->Purchase with multiple lines having the same products, the receipt picking would be incorrectly assigned:
- Enable Inter-Company Transactions on both companies (Create and validate)
- Create SO in company A to company B with 2 lines having the same product P, Confirm. => Delivery in company A, Purchase and Receipts in company will be created => The SO/PO/Delivery/Receipt will all have 2 lines
- Validate delivery => On the receipt, the 2 units of P are reserved on the 1st move, and the 2nd move is not reserved.


https://github.com/user-attachments/assets/b4816051-120e-4226-9228-fd552649d5ef


---

### Test result without fix:
```
2026-04-23 13:16:44,577 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: Starting TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product ... 
2026-04-23 13:16:44,949 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: ====================================================================== 
2026-04-23 13:16:44,949 48027 ERROR oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: FAIL: TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/sale_purchase_stock_inter_company_rules/tests/test_inter_company_so_to_po.py", line 109, in test_02_inter_company_multiple_lines_with_same_product
    self.assertRecordValues(purchase_from_a.picking_ids.move_ids, [
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/tests/common.py", line 709, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'pr[18 chars]0, 'quantity': 1.0}, {'product_uom_qty': 1.0, 'quantity': 1.0}] != [{'pr[18 chars]0, 'quantity': 2.0}, {'product_uom_qty': 1.0, 'quantity': 0.0}]

First differing element 0:
{'product_uom_qty': 1.0, 'quantity': 1.0}
{'product_uom_qty': 1.0, 'quantity': 2.0}

- [{'product_uom_qty': 1.0, 'quantity': 1.0},
?                                       ^

+ [{'product_uom_qty': 1.0, 'quantity': 2.0},
?                                       ^

-  {'product_uom_qty': 1.0, 'quantity': 1.0}]
?                                       ^

+  {'product_uom_qty': 1.0, 'quantity': 0.0}]
?                                       ^

```

OPW-6145683

Forward-Port-Of: odoo/enterprise#118548
Forward-Port-Of: odoo/enterprise#114873

Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870

Forward-Port-Of: odoo/enterprise#118773

**Description of the issue this PR addresses:**
----------------------------------------------
Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation.

**Current behavior before PR:**
----------------------------------------------
- Visitors can type @ in the livechat composer and trigger partner mention suggestions.
- The suggestions only include the visitor themselves or odoobot.

**Desired behavior after PR is merged:**
----------------------------------------------
- The @ delimiter is disabled for visitors in livechat threads.
- Partner mention suggestions are no longer triggered for visitors.
- Internal users (operators) can still use @ mentions normally.

Task-5119068

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

Forward-Port-Of: odoo/odoo#266758
Forward-Port-Of: odoo/odoo#253551

**Problem:**
When a combo product has a price but all of its combo components have a zero list price, the quotation shows the combo's price twice: once on the combo line itself and once on the last combo item line.

**Steps to reproduce:**
1. Create a combo product with a non-zero price and two or more combo groups whose component products have a zero list price.
2. Create a sale order, add the combo, pick one item per group.
3. Look at the quotation/order: the combo line total and the last combo-item line both show the full combo price.

**Current behavior:**
The full combo price ends up on the last combo item line; the other combo items show 0. The combo line then displays the same total via `_get_combo_totals`, so the same amount appears twice.

**Expected behavior:**
The combo's price is spread across its combo items so no single line duplicates the combo total.

**Cause of the issue:**
`_get_combo_item_display_price` prorates the combo price by each combo's base price. When every base price is 0, every prorated price is 0, so `combo_price_delta` equals the full combo price and is added to the last combo as a rounding correction, concentrating the whole price there instead of spreading it.

**Fix:**
Treat an all-zero base case as "no proration signal" and split the combo price evenly across combos before the delta adjustment runs. The delta correction then only handles rounding, as intended.

opw-6217945

Forward-Port-Of: odoo/odoo#265010

### Steps to reproduce:

- In the settings enable: "Units of Measure & Packagings", "Storage Locations"
- Create a product in units and register 1 unit in stock
- Inventory > Operations > Adjustments > Physical Inventory
- Select your line and request a count > Set Current Value
- Inventory > Configurations > units of measures > UOM categories
- Select unit and archive it
- Go to the barcode app > Click Count inventory
### > Owl error: Uncaught promise

### Cause of the issue:

Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110

opw-6250090

Forward-Port-Of: odoo/enterprise#118813

By default, payslip lines that do not appear on the printed payslip
  (appears_on_payslip = 'never', or 'non_zero' with zero total) are now
  hidden in the Salary Computation tab, giving a backend view consistent
  with what the employee sees on their payslip.

  Added a Show All Toggle that controls the visibility of payslip lines that are invisible on the actual payslip.
  This Toggle state is shared across all payslips, but not stored.

Implementation:
    - Added a "Show All" toggle widget registered as a view_widget.
    - Toggle state is persisted in localStorage under the key
      "hr_payroll.display_all_payslip_lines"
    - Created a module-level proxy object "payslipShowAllState" as the
      single source of truth shared across all payslip instances.
    - Custom ListRenderer (PayslipListRowVisibilityRenderer) filters rows
      based on appears_on_payslip and payslipShowAllState.showAll.
    - Custom X2ManyField widget (payslip_lines_2many) swaps the default
      ListRenderer with the custom one.

task - 6200256

**Steps to reproduce:**
* Install Peru - Accounting Reports (l10n_pe_reports).
* Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047).
* Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4).
* Export the TXT file and open it.

**Observed behavior:**
* Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code.
* SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes.

**Cause:**
* `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235".
* The same incorrect value was also written to field 28 (aduana_code).
* ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

**Fix:**
* For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value).
* Apply the same logic to field 28 (aduana_code) for consistency.

opw-6157662

Forward-Port-Of: odoo/enterprise#115406