## Short functional explanation of the error
In Timesheets, when reporting by billing time, if we try to group by employee, an error occurs.

## Reproduction Steps
1. Go to Timesheets.
2. Click on the Reporting tab > By Billing type.
3. Click on the search bar and click on Employee under the Group By section.

### Expected behavior
A report shows the different hours worked on billing time for each employee.

### Unexpected behavior
An error occurs:
```TypeError: data.forEach is not a function```

## Origin of the issue
When retrieving the data to show in the report after having grouped
it by employee, this piece of code is called:
https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/sale_timesheet_enterprise/static/src/views/timesheet_analysis_pivot/timesheet_analysis_pivot_model.js#L23-L36
However, the variable (data) on which we perform the forEach isn't
an array: it's an object of structure:
```
{ "group": { "rowValues": [], "colValues": [] }, "rowGroupBy": [ "employee_id" ], "colGroupBy": [], "subGroupIndex": 2, "subGroups": [ { "employee_id": [ 1, "Administrator" ], "__extra_domain": [ [ "employee_id", "=", 1 ] ], "unit_amount:sum": 0, "__count": 2, "__domain": [ "&", [ "project_id", "!=", false ], [ "employee_id", "=", 1 ] ] } ] }
```
on which we can't perform a forEach. The data we want to access to
use in the report is actually the `subGroups` element of data.

__
opw-5910036

Forward-Port-Of: odoo/enterprise#106969

Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback

Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.

To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.

After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.

This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4

If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
    order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```

Those two last issues are solved by not syncing the data to the server when we simply print the bill early.

-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt

Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.

We backport this fix that enables basic receipt printing and alter it to also work with early printing.

Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97

There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.

There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.

opw-5387572


Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />

Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />

Forward-Port-Of: odoo/enterprise#105511

### Issue:

The action used in the ` timesheet approval reminder` email template refair to a non existing action.

### Cause of the issue:

The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461

Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45

The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198

opw-5890269

Forward-Port-Of: odoo/enterprise#107385

The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts.

[A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line.

But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error.

So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'.

We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined.

Steps to reproduce:
- Activate Cash Basis in the Settings
- Create a tax based on payment
- Create an invoice with two lines:
	- One with a negative amount, an income account and the created tax
	- One with a positive amount big enough to compensate the previous line, a different income account and the same tax
- Confirm
- Click "Pay", validate the payment
- In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice
- Reconcile it with the invoice
- Accounting > Reporting > Tax Return
- Select "Group By: Account tax"

Community PR: odoo/odoo#239081

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

Forward-Port-Of: odoo/enterprise#101601

Currently, an error occurs when user edits a reconciled line.

**Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):**

 - Install the `Accounting` module.
 - Create an `invoice` with an `invoice line` having an amount greater than zero.
 - `Confirm` the invoice.
 - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice.
 - Click `Reconcile` on that `statement line` and select the newly `created invoice line`.
 - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save.

`UnboundLocalError: local variable 'original_base_lines' referenced before assignment`

The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2].

This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error.

[1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394

[2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411

sentry-7189027839

Forward-Port-Of: odoo/enterprise#107454
Forward-Port-Of: odoo/enterprise#104432

Steps to produce:
---
- Install `sale_renting` and `contacts` modules.
- Go to contact and open `yourcompany` record.
- Add a new contact of type Delivery and save (leave the name empty).
- Go to Rental > New Order.
- Select YourCompany, Delivery as the customer.
- Add a rental product and confirm the order.
- Open the Schedule view.

Traceback:
---
`TypeError: sequence item 0: expected str instance, bool found`.

Root cause:
---
- At [1], the system tries to use the customer's name when computing the display name. However, in this case, the delivery contact has no name, resulting in a False value. This False value is then included in the description list, causing the TypeError when joining the sequence.

Solution:
---
- Use the partner's `display_name` instead of `name`. The `name` field
  can be `False` in some cases. The `display_name` field is a computed
  field that always provides a valid, formatted string by using fallback
  values such as the company name, parent name, or contact type. This
  ensures consistency and prevents errors

[1] https://github.com/odoo/enterprise/blob/f5fea1d7b40e42b7bc1c323cc9613b1aa347da09/sale_renting/models/sale_order_line.py#L61

opw-5914084
---

Forward-Port-Of: odoo/enterprise#107451
Forward-Port-Of: odoo/enterprise#106827

## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift

Before this commit, the user could update the shift linked to a rental
order and creating a conflict with another shift for the same resource
and so, it would be impossible for the resource to be in 2 spaces at the
same time (or it is impossible to rent a room to 2 different customers).

This commit returns an Validation Error if the user updates the planned dates
of a rental shift and creates a conflict.

## [FIX] sale_renting_planning: add problematic shifts only if rental order

Before this commit, the previous fix making sure the error, saying no
resource is available during the generation of a shifts when the user
confirms a sale order, is only displayed when the `Sync Shifts and
Rental Orders` is enabled, could potentially never display the error
when it should be expected because we only check if the last SOL of the
batch to generate shifts has the feature enable or not.

This commit makes sure the error is correctly displayed as expected.

## [FIX] sale_renting_planning: update condition of Rental buttons in shift

Before this commit, the user could click on Create order button for an
open shift is the role having the rental feature enabled. To problem is
a resource is required to make sure the rental order can be delivered.
About the other button shown, `Add to Last Order` one, this one could be
clicked even if the shift is in conflict with another shift and so, it
will display a warning saying no resource is available.

This commit makes sure
- `Create Order` button in shift form view is not
visible when the shift is a open shift.
- `Create Order` and `Add to Last Order` buttons in shift form view are
not displayed when the shift is in conflict.

task-5065930

Forward-Port-Of: odoo/enterprise#97024

Issue:
------
The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6) phase. This occurred because several `ir.config_parameter` records used `ref()` to point to [whatsapp templates](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml) that were manually deleted in the production environment.

ValueError is raised:
```py
    raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: whatsapp_sign.sign_request_whatsapp_template
```
Cause:
-------
Since these whatsapp templates are defined with [`forcecreate="0"`](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml#L3), Odoo does not recreate them automatically during migration. This left the External IDs (IMD) pointing to non-existent records, causing a `ValueError: External ID not found in the system` that blocked the migration.

Solution:
-----------
Updated the `ref()` calls in the XML for these configuration parameters to include `raise_if_not_found=False`. This allows the registry to initialize successfully by returning None instead of crashing if a template is missing.

tgb: [2448](https://upgrade.odoo.com/odoo/tbg/2448?debug=1)
upg: [3895200](https://upgrade.odoo.com/odoo/upgrade.request/3895200?debug=1)
opw: [5931388](https://www.odoo.com/odoo/project/70/tasks/5931388?debug=1)

Forward-Port-Of: odoo/enterprise#107477

Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived.

###  **Steps to reproduce:**
1) Install **l10n_de_reports, Contacts** App with Demo Data. 
2) Switch to a **DE company**.
3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 
4) Archive 'Test-A'.
5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 
6) Unarchive 'Test-A'.

### **Observed Behavior:**
'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier.

### **Expected Behavior:**
A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined.

### **Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint.

However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions.

Fix:
Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones.

opw-5474106

Forward-Port-Of: odoo/enterprise#106146

Since [1], the voip calls infinite scrolling does not work anymore.

Steps to reproduce:
- Make sure to have at least 14 recent calls
- Open the softphone
- Go to the recent/history tab
- Scroll to the end => You are stuck seeing only the 13 last calls.

This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration.

This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item.

Note that [1] disabled a test that was testing the feature. This commit of course re-enables it.

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd

Forward-Port-Of: odoo/enterprise#106768
Forward-Port-Of: odoo/enterprise#106658

## Short functional explanation of the error
In Timesheets, when reporting by billing time, if we try to group by employee, an error occurs.

## Reproduction Steps
1. Go to Timesheets.
2. Click on the Reporting tab > By Billing type.
3. Click on the search bar and click on Employee under the Group By section.

### Expected behavior
A report shows the different hours worked on billing time for each employee.

### Unexpected behavior
An error occurs:
```TypeError: data.forEach is not a function```

## Origin of the issue
When retrieving the data to show in the report after having grouped
it by employee, this piece of code is called:
https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/sale_timesheet_enterprise/static/src/views/timesheet_analysis_pivot/timesheet_analysis_pivot_model.js#L23-L36
However, the variable (data) on which we perform the forEach isn't
an array: it's an object of structure:
```
{ "group": { "rowValues": [], "colValues": [] }, "rowGroupBy": [ "employee_id" ], "colGroupBy": [], "subGroupIndex": 2, "subGroups": [ { "employee_id": [ 1, "Administrator" ], "__extra_domain": [ [ "employee_id", "=", 1 ] ], "unit_amount:sum": 0, "__count": 2, "__domain": [ "&", [ "project_id", "!=", false ], [ "employee_id", "=", 1 ] ] } ] }
```
on which we can't perform a forEach. The data we want to access to
use in the report is actually the `subGroups` element of data.

__
opw-5864458

*: account_asset, sale_lazada

Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access.

Here is a list of examples (each performed with every other access rights disabled):
- With a `stock user`, open the delivery list or form view
 #### > Access error
- With a `purchase user` create and confirm a PO > Upload Bill
####  > the Bill will be created but an access error will prevent the draft bill from opening.
- With a `sale user` create and confrim an SO > Create invoice
####  > the invoice will be created but an access error will prevent the draft invoice from opening.

## Solutions:

### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user:

1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model.

Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view.

#### Note for master:

IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here:
https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52

2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53

### Use case: Open a `stock.picking` views as basic stock user:

3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496

opw-5461135
opw-5417749

## [REF] hr_contract_salary{,_payroll}: Add hr_version_context ctx mngr

Description
-----------
Getting an `hr.version` from an `offer` during simulation is done in
a savepoint, preceded and followed with flushing of the environment
and some post-cleanup. This is verbose and error-prone, as it's done
at each call site of `hr.contract.salary.offer._get_version` and
`hr.version._generate_salary_simulation_payslip` (or any other
future method that may require such a savepoint). These methods have a
comment that mentions *requiring* a savepoint to be called, but
nothing is enforcing it, so a bug due to oversight is bound to
happen. Context keys are also injected a bit everywhere like
`salary_simulation` and `tracking_disable`, without much consistency,
and adding to the visual clutter.

This commit introduces a little context manager called
`hr_version_context` that manages the creation of the savepoint, the
setup and teardown necessary, and the setting of the keys in the
context.
It's accompanied by a decorator `@requires_hr_version_context` that
will fail if the caller didn't use `hr_version_context` before
invoking the marked method.

This ensures:

- Correct creation of the savepoint and its related pre-/post-operations
- Apply context keys consistently
- Ensure methods that require such setup *cannot* be called without it.


## [PERF] {,l10n_be_}hr_contract_salary: speed up salary simulation updates

Description
-----------
Many of the methods used to recompute the benefits and salary on the
salary configurator were creating the necessary context for working
with a simulated employee version (savepoint / flushing /
invalidation) at each level in the method override hierarchy. This
led to unnecessary overhead that had a negative performance impact.

To remedy this, this commit extracts the overridable parts of the
method into their own private versions. Only the private version
should be overridden to modify the behavior, while the public method
is kept for setting up the necessary context. This allows the
setup/teardown of the context only once per call of the method and
its potential parent overridden methods.

Benchmark
---------
On a staging database, opening the salary configurator and clicking
on 'Simulation' when selecting a new car took:

| Timings for        | Before | After  | Speed up |
|--------------------|--------|--------|----------|
| `onchange_benefit` | ~750ms | ~160ms | 4.6x     |
| `update_salary`    | 2.3s   | 1.1s   | 1.9x     |

Bug reproduction: When version >= 19.0, install Kenya payroll and accounting, create payslip for one of the Kenyan employee -> validate the payslip -> Reporting: P9 Report in payroll app -> Create new tax deduction card -> populate employees -> in the inside of the card: select employees and click to generate pdf -> it will not be generated 

Bug cause:
    1 - In cron parameters, context passed wrongly, it should take place in the clickable parameters
    2 - After saas-18.4 in the migration, employee.l10n_ke_pin field is removed but this field still takes place in l10n_ke_tax_reduction_card_templates.xml and it gets error when the user clicks to generate PDF.

Bug solution:
    1 - Fixing cron parameter passing
    2 - Removing PIN of employee field from P9 report since it is not available anymore.

Testing: Unit test is written to check PDF's are generated for sure.
    1 - Creating Kenya company, employees
    2 - Creating payslip for employees and validate them
    3 - Creating tax deduction card and generate declarations
    4 - Checking PDF's are created

task - 5395267

The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts.

[A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line.

But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error.

So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'.

We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined.

Steps to reproduce:
- Activate Cash Basis in the Settings
- Create a tax based on payment
- Create an invoice with two lines:
	- One with a negative amount, an income account and the created tax
	- One with a positive amount big enough to compensate the previous line, a different income account and the same tax
- Confirm
- Click "Pay", validate the payment
- In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice
- Reconcile it with the invoice
- Accounting > Reporting > Tax Return
- Select "Group By: Account tax"

Community PR: odoo/odoo#239081

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

Steps to reproduce:
1. Install `website_knowledge`
2. Create a long, scrollable knowledge article with 20 sub-articles.
3. Share the article publicly
4. Open the public link in mobile view (logged out)
5. Toggle the sidebar using the top-left menu button
6. Scroll down

Issue:
- On mobile, the public sidebar overlaps with the article's content while scrolling.

Cause:
- the sidebar and its backdrop were positioned absolutely inside a flex container. Because they were not fixed to the viewport, the article content continued to scroll and render underneath the sidebar, causing visible overlap between the sidebar and the article body. Additionally, the sidebar’s internal scroll container was not explicitly positioned, which contributed to inconsistent scrolling behavior when the sidebar was open.

Solution:
- Update the public Knowledge sidebar css to behave as a proper mobile overlay by: Fixing the sidebar and its backdrop to the viewport using position: fixed, ensuring they are removed from the flex layout flow on mobile Explicitly positioning the sidebar’s internal scroll view to ensure correct scrolling behavior

<table>
  <tr>
    <td><strong>Before</strong></td>
    <td><strong>After</strong></td>
  </tr>
  <tr>
    <td><img width="725" height="901" alt="Before image" src="https://github.com/user-attachments/assets/33190684-5b52-4931-b01a-5044734c9cf0" /></td>
    <td><img width="686" height="916" alt="After image" src="https://github.com/user-attachments/assets/610a5aef-3467-4215-a0a0-83607375a016" /></td>
  </tr>
</table>


opw-5384026

Steps to produce:
---
- Install `accountant` and `l10n_mx` modules.
- Switch to Mexican company.
- In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`.
- Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice.
- Mark the invoice as global.
- Register the payment.
- Create a credit note and confirm it.
- Click Send(make sure CFDI is checked) and check the generated XML.

Issue:
---
- The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`.

Solution:
---
- Preserve the original line description for CFDI refunds instead of forcing
  the generic label.
- For POS refunds, continue using the generic label.
- This aligns with the fix introduced in 19.0([here]).

Before:
---
<img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" />

After:
---
<img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" />



[here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436
**Backport of https://github.com/odoo/enterprise/pull/97681**

opw-5870052
---

An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices.

In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely.

The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`.

Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information.

[opw-5915515](https://www.odoo.com/odoo/project.task/5915515)

----
*Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.*

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record is not a field service task.
* Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 
[2]
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related community PR: https://github.com/odoo/odoo/pull/241446

opw-5215989

**Steps to Reproduce:**
1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee
3 - Set 2000 euros in recovery amount holiday n-1
4 - Set 10 days in recovery day holiday n-1
5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February  and validate it 7 - Do one payslip for this employee for December

Current behaviour :
- the holiday n-1 amount for February = 824.80
- the holiday n-1 amount for December = 742.32

Expected behaviour :
- the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80

**Reason**
- The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules.

**Solution**
- Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied.