**Description of the issue/feature this PR addresses:**

When a document is rejected by a signer, the notification email sent to
other involved parties incorrectly displays the recipient's name in the
subject line instead of the person who actually refused to sign.

This occurs because the subject string was using `partner.name` (the
current email recipient) instead of `refuser.name`. This commit updates
the string to reference the refuser, ensuring the subject accurately
identifies the individual who rejected the document.

**Steps to reproduce:**

- Sign > upload any PDF > add signature request for 2 different signers > Send > choose signers, e.g. Abigail Carter and Marc Demo > Send
- Settings > Technical > Emails > Emails
  - Select one of the sent emails > Sign document > sign > Validate & Send Completed Document
  - Select the other email > Sign document > top-right dropdown arrow > Decline to sign > Decline
- Settings > Technical > Emails > Emails
  - Observe that all emails sent state that the recipient of the email rejected the signing


**Current behavior before PR:**

- Rejection email subject states that the recipient refused to sign

**Desired behavior after PR is merged:**

- Rejection email subject states that the refuser refused to sign

opw-6421188

Forward-Port-Of: odoo/enterprise#126412

Steps to reproduce
1. Create two products and assign the same vendor to both in the Purchase tab
2. Create two Sales Orders using the dropship route (one product per order)
3. Generate and merge the corresponding Purchase Orders, then confirm the merged PO
4. Validate the dropship transfer

Issue
stock.picking.sale_id is a Many2one (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/sale_stock/models/stock.py#L99)
computed from procurement.group.sale_id, and stock.picking.group_id is a
stored related on move_ids.group_id (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/stock/models/stock_picking.py#L186).
A single picking can therefore only resolve to one SO. _create_picking
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order.py#L290)
builds one picking per PO and _prepare_stock_moves assigns every move
the merged PO's group_id
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order_line.py#L307),
so when a merged dropship PO carries lines from multiple SOs every move
lands in one picking under the PO group. Only one SO gets linked and
the others stay "not fully delivered" even after validation.

Solution
Override PurchaseOrderLine._prepare_stock_moves to set group_id to the
SO's procurement_group_id when sale_line_id is set, so each dropship
move is created in its originating SO's procurement group.

Override PurchaseOrder._create_picking to detect dropship POs whose
order lines span more than one SO and create one picking per SO group
by calling _prepare_picking and _create_stock_moves per group.
picking.group_id then resolves to the SO group via the stored related
field, picking.sale_id points to the right SO, and delivery_status
updates correctly on validation.

opw-6094608

Forward-Port-Of: odoo/odoo#280166
Forward-Port-Of: odoo/odoo#257823

**Steps to reproduce:**
1. Install eCommerce, l10n_be, payment_stripe and switch to belgian company
2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium
3. Create a website for the belgian company and enable stripe payment provider
4. Add SEPA payment method in stripe configuration
5. Open the website, add any product to cart, go to checkout and make a payment using SEPA

**Issue:**
- Check the transaction in Stripe dashboard: the order reference is currently sent only
in the `Description` field which is for internal information and is not shown to
customers on their bank statements. Customers only see "MACKNET", so they cannot
identify which order the payment relates to.

**Expected behavior:**
- Should also send the order reference to Stripe's `statement_descriptor` field, which
is the field used for the customer-facing bank statement reference.
- The `statement_descriptor` value must comply with Stripe's requirements:
Must not contain <, >, \, ', ", or *
Must contain at least one letter
Maximum 22 characters

**Fix:**
- Pass the order reference, which should already satisfy the first two requirements based
on Odoo order/invoice naming conventions

opw-6424994

Forward-Port-Of: odoo/odoo#280985

Steps:
- Install l10n_co module.
- Set `CO company` on user.
- Go to address page on portal address.
- Set `Company Name`, `ID Type` and `ID Number` on the address page.

Issue:
- Not able to save address without any error message on the address page and in logger it raise validation error.

Cause:
- In address we actually do vat validation before creation/updation and if there is any issue with vat number then add it into invalid_fields instead raising any validation error, so here when user set `Company name` on address it try to create parent company and again do vat validation and it raise validation error because `ID Type` on customer is not propagated to parent when creating parent company from portal.

Fix:
- Skip vat validation on parent company creation from address.

To-do: We also need to pass `ID type` and other accounting related values when creating parent company from customer or make them dependent like `Vat`.

Issued PR: https://github.com/odoo/odoo/pull/264356

opw-6434127

Forward-Port-Of: odoo/odoo#280859

**Issue:**
Flexible employees in French companies cannot request the reference paid time off type, even when they have a sufficient allocation.

**Steps to reproduce:**
- Install the l10n_fr_hr_holidays module.
- Create a French company and set it as the active company.
- Log in as a user whose working schedule is Flexible (i.e., the employee's Working Hours field is left blank).
- Ensure the company's Time Off Type matches the leave type that the employee is requesting.
- Set a Resource Calendar on the company (this is required and must differ from the employee's flexible working schedule).
- Attempt to create a Time Off request for the employee.

**Cause:**
https://github.com/odoo/odoo/blob/5e865aeec854ca012dc5537f36b2e626ee39cf0b/addons/l10n_fr_hr_holidays/models/hr_leave.py#L17-L27

`_l10n_fr_leave_applies()` considers an empty employee calendar different from the company calendar. This sends flexible leaves to `_get_fr_date_from_to()`, which requires attendance rows and rejects the request.

**Solution:**
We need to require a concrete employee calendar before applying the French part-time calendar adjustment, leaving flexible employees to the core flexible-duration computation.

opw-6417220

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

Steps to reproduce:
- Enable presets and set a preset carrying a tax-replacing fiscal position (e.g. "Takeout") as the default preset of the POS config
- Take an order with another preset that has no fiscal position (e.g. "Dine In")
- Refund that order from the ticket screen

Issue:
The refund is taxed with the fiscal position of the default preset instead of the one of the refunded order. The ticket screen displays the refund lines with the taxes of the original order, but the refund that is actually created maps them through the wrong fiscal position. With tax-included prices the totals still match on screen, so the operator only sees the discrepancy after going back.

Cause:
The destination order of a refund is an empty order, created with the default preset and therefore with that preset's fiscal position. In TicketScreen.onDoRefund, the fiscal position of the refunded order was only copied onto it when the refunded order had one, so an order taken without a fiscal position kept the default preset's one. When an already existing empty order is reused as destination, whatever fiscal position was last set on it survives for the same reason.

Fix:
Always assign the fiscal position of the refunded order to the destination order, an empty one included, so a refund is taxed exactly like the order it refunds instead of silently switching. The preset itself is left untouched: it drives the ordering workflow (timing slot, customer identification) which must not be imposed on a refund.

opw-6442664

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

Forward-Port-Of: odoo/odoo#280672

Description of the issue/feature this PR addresses:

A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed.

The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document.

That model only grants read access to account.group_account_invoice and account.group_account_readonly.

Steps to reproduce:
- install `l10n_es_edi_verifactu`
- create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough)
- create an ES company and an ES customer
- give the salesman access to the ES company
- activate Peppol in the general settings
- log in as the salesman
- create a sale order in the ES company for the ES customer
- confirm it
- click **Create Invoice**
- click **Create Draft**

Current behavior before PR:

An error access is raised:

Failed to read field account.move.l10n_es_edi_verifactu_document_ids

You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records.

This operation is allowed for the following groups:
	- Invoicing/Billing
	- Technical/Show Accounting Features - Readonly

Contact your administrator to request access if necessary.


In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails  for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management.

Desired behavior after PR is merged:

On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed.


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

Forward-Port-Of: odoo/odoo#280879

**Steps to reproduce:**
1. Install eCommerce, l10n_be, payment_stripe and switch to belgian company
2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium
3. Create a website for the belgian company and enable stripe payment provider
4. Add SEPA payment method in stripe configuration
5. Open the website, add any product to cart, go to checkout and make a payment using SEPA

**Issue:**
- Check the transaction in Stripe dashboard: the order reference is currently sent only
in the `Description` field which is for internal information and is not shown to
customers on their bank statements. Customers only see "MACKNET", so they cannot
identify which order the payment relates to.

**Expected behavior:**
- Should also send the order reference to Stripe's `statement_descriptor` field, which
is the field used for the customer-facing bank statement reference.
- The `statement_descriptor` value must comply with Stripe's requirements:
Must not contain <, >, \, ', ", or *
Must contain at least one letter
Maximum 22 characters

**Fix:**
- Pass the order reference, which should already satisfy the first two requirements based
on Odoo order/invoice naming conventions

opw-6424994

Forward-Port-Of: odoo/odoo#280985

Steps to reproduce:
-------------------------------------------------
1. Install the `sale_project` module
2. Create a test user with Project User rights
3. Create a Project Role with the Created User as a Team Member
4. Create a Template Project as follows: 
    * Add one task to the template project
    * Add the created Project role to the Task
5. Create a Service Type Product with:
    * Create on order: Project
    * Project Template: Created Template
6. Archive the Created User
7. Create and Confirm the Sale Order with the Created Product

Observation:
-------------------------------------------------
The generated task is assigned to the archived user, although the archived user is no longer part of the Project Role.

Issue:
-------------------------------------------------
While creating Project and Tasks from template, the context disable active record filtering (e.g., `active_test=False`), causing the assignment logic to fetch both active and inactive/archived users linked to the role. https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/odoo/orm/models.py#L4868

After that, during the `copy_data` method, It takes all the users from the roles without checking weather user is active or not
https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/addons/project/models/project_task.py#L890-L904

And even if we pass only Active users from this method, on moving further, it reassigns the users from roles without checking the Active field of the user

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L501-L503

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L544-L553

Due to this, the Archived User is also assigned to the tasks from the project roles

Solution:
-------------------------------------------------
Apply a `filtered('active')` check directly on the project role's users
`(role.user_ids)` within the core task-copying logic in both `project` and
`project_enterprise` modules. This ensures archived users are universally
excluded from task assignments during template copying, regardless of what
triggers the template instantiation.

Related Enterprise PR: https://github.com/odoo/enterprise/pull/125637

opw-6350841

Description of the issue/feature this PR addresses:

A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed.

The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document.

That model only grants read access to account.group_account_invoice and account.group_account_readonly.

Steps to reproduce:
- install `l10n_es_edi_verifactu`
- create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough)
- create an ES company and an ES customer
- give the salesman access to the ES company
- activate Peppol in the general settings
- log in as the salesman
- create a sale order in the ES company for the ES customer
- confirm it
- click **Create Invoice**
- click **Create Draft**

Current behavior before PR:

An error access is raised:

Failed to read field account.move.l10n_es_edi_verifactu_document_ids

You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records.

This operation is allowed for the following groups:
	- Invoicing/Billing
	- Technical/Show Accounting Features - Readonly

Contact your administrator to request access if necessary.


In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails  for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management.

Desired behavior after PR is merged:

On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed.


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

Forward-Port-Of: odoo/odoo#280879

Description of the issue/feature this PR addresses:

A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed.

The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document.

That model only grants read access to account.group_account_invoice and account.group_account_readonly.

Steps to reproduce:
- install `l10n_es_edi_verifactu`
- create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough)
- create an ES company and an ES customer
- give the salesman access to the ES company
- activate Peppol in the general settings
- log in as the salesman
- create a sale order in the ES company for the ES customer
- confirm it
- click **Create Invoice**
- click **Create Draft**

Current behavior before PR:

An error access is raised:

Failed to read field account.move.l10n_es_edi_verifactu_document_ids

You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records.

This operation is allowed for the following groups:
	- Invoicing/Billing
	- Technical/Show Accounting Features - Readonly

Contact your administrator to request access if necessary.


In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails  for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management.

Desired behavior after PR is merged:

On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed.


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

Forward-Port-Of: odoo/odoo#280879

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

### Steps to reproduce

1. Install *Sales* and *Timesheets*
2. Create a service product: Invoicing Policy = *Based on Timesheets*, Create on Order = *Task*
3. Create a sale order for it (quantity 1) and confirm it
4. On the generated task, log **4.5 h on 15/06** and **3.5 h on 23/07**
5. *Create Invoice* with no timesheet period → 8 h, and post it
6. On that invoice: *Reverse* → *Partial Refund*, set the quantity to **3.5 h** and post it → 4.5 h invoiced
7. Log **1 h on 31/07** → 9 h delivered
8. *Create Invoice* again, with a **Timesheets Period of 01/06 → 31/07**

### Current behavior

The invoice bills **9 h**: the 4.5 h that were invoiced and not credited are billed a second time.

### Expected behavior

The invoice bills **4.5 h** — the quantity delivered minus the quantity invoiced.

### Cause of the issue

Posting a partial credit note clears `timesheet_invoice_id` on every timesheet the reversed invoice
had linked (`sale_timesheet/models/account_move.py`, `action_post`), because a credit note carries a
quantity and never a set of timesheets, so there is no way to tell which hours it credited.

All of those hours therefore become candidates again in `_recompute_qty_to_invoice`, which assigns
their sum to `qty_to_invoice` without comparing it to what is still due on the line.

### Fix

Timesheet links cannot express a partially invoiced timesheet, so they are used only to select the
hours a period concerns, while the quantity that may still be billed is
`qty_delivered - qty_invoiced`. The period lookup is capped by that remainder, and kept at zero or
above so that an over-invoiced line is corrected by a deliberate credit note rather than as a side
effect of invoicing a period.

### Tests

Five tests are added to `addons/sale_timesheet/tests/test_sale_timesheet.py`.

Three of them fail without the fix:

| test | without the fix |
| --- | --- |
| `test_period_invoice_does_not_rebill_refunded_invoice_hours` | `9.0 != 4.5` |
| `test_period_invoice_after_refund_is_computed_per_line` | `4.0 != 1.5` |
| `test_period_invoice_after_refund_of_an_over_invoiced_line` | `8.0 != 1.0` |

The other two cover behaviour that is not exercised today and that the fix must not break: an
over-invoiced line (which must be left out rather than credited, and must not prevent the other
lines of the order from being invoiced) and the reversed invoice's own `invoice_date`, which must not
influence the quantity billed for a period.

The full `sale_timesheet` suite passes (86 tests).

Forward-Port-Of: odoo/odoo#280721
Forward-Port-Of: odoo/odoo#280536

**Description:**
While loading the budget report, the bad queries are created by 
```def _get_aal_query()``` and ```def _get_pol_query()``` function, makes 
the budget report unusable.

**Root cause:**
Instead of doing a hash join while searching the record,
 the OR statement in the Left Join in the condition 
```(%(bl)s IS NULL OR %(a)s = %(bl)s)``` 
creates a nested for loop that compares everything single aal to bl, 
this causes a significant performance issue as the number of the 
number of check will be the the number aal * bl,
if a database has a 70k aal and 20k bl, both numbers are not large
but it will cause a 70k * 20k search which is more than a billion.

**Fix**:
There are some refactors made in this PR.

_First_, separate out the Q1.
In order to find the aal that has no bl connects to it. 
Doing a search to find the aals that have bl and then subtract them from all aals.

_Second_, Instead of doing a nested loop for by using
 ```(%(bl)s IS NULL OR %(a)s = %(bl)s)```, 
originally we will have do something like
```
JOIN budget_line bl
  ON (bl.x_plan2_id IS NULL OR aal.x_plan2_id = bl.x_plan2_id)
 AND (bl.x_plan3_id IS NULL OR aal.x_plan3_id = bl.x_plan3_id)
 AND (bl.x_plan4_id IS NULL OR aal.x_plan4_id = bl.x_plan4_id)
```
Assuming each bl has three plans ```x_plan2_id```, ```x_plan3_id```, ```x_plan4_id```

Grouping the bl base on whether a specific plan is set, (i.e. shapes)
we can skip the ```IS NULL OR``` because we already know which plan
 is null and do the hash join directly.

For example, the shapes will be a dictionary with a key of a tuple of booleans
based on whether a plan is set or not and the value is a list of bl_id.

```
{
    (True, False, False): [1, 2],
    (False, True, True):  [3, 4],
    (False, False, False): [5],
}
```

we can end up doing something like

```
JOIN budget_line bl
 ON bl.id = ANY(ARRAY[3,4])
 AND aal.x_plan3_id = bl.x_plan3_id AND aal.x_plan4_id = bl.x_plan4_id
```
which is way more faster.

---
The benchmark is made locally from this client's database which contains
 69k aal, 23k bl, 6829 pol and 3 plans for aal and bl.

|Record count                                      |Time before|Time after|
|--------------------------------------------------|-----------------|---------------|
|69k aal, 23k bl, 6829 pol, 3 plans    |70.04s         |4.6s            |

Dalibo:

Before: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/8h3d4e89aaf9f3d4
Overall grand total by company:
https://explain.dalibo.com/plan/445g1f9caf4923e2
Month-over-month grand total by plan: 
https://explain.dalibo.com/plan/53a138ca50b2a7c4
Overall grand total by plan: 
https://explain.dalibo.com/plan/hdbe169ddc7g5785

After: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/hcc86c801e6872bf
Overall grand total by company:
https://explain.dalibo.com/plan/69b2421a3581f98h
Month-over-month grand total by plan:
https://explain.dalibo.com/plan/a88f398bbbch3148
Overall grand total by plan: 
https://explain.dalibo.com/plan/1gg749ae7ab1553c

opw-6345552

Forward-Port-Of: odoo/enterprise#127297
Forward-Port-Of: odoo/enterprise#124161

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126156

Root cause:
For an employee on a flexible working schedule, the weekly overtime shown in the timesheet grid compares the entered total against the full time equivalent of the schedule instead of its own weekly hours. The target is sent by _count_daily_working_hours:

https://github.com/odoo/enterprise/blob/27f3a05ca8a5ad6e8d4537dac4f613e60931f0cd/timesheet_grid/models/hr_employee.py#L117-L119

It reads full_time_required_hours, but since https://github.com/odoo/odoo/commit/5cb102546ea4370b4fe5e4a4f37cccdc90c263fd this field holds the company full time reference used to compute the work time rate, and the hours the schedule actually expects per week are on hours_per_week. So for a part time schedule at 80% of a 42 hours full time, the grid expects 42 hours instead of 33h36 and the weekly total shows in red with a wrong negative overtime.

Fix:
In _count_daily_working_hours, send the hours_per_week of the calendar as the weekly target and keep full_time_required_hours as a fallback when it is not set. For a full time schedule both fields hold the same value so nothing changes there. The result key stays the same so the grid renderers need no change.

Steps to reproduce:
1. Go to Employees > Configuration > Working Schedules and create a schedule with Schedule Type Flexible, Full Time Equivalent 42:00 and Total 33:36 hours per week
2. Assign this schedule to an employee linked to a user
3. As that user, go to Timesheets > My Timesheets
4. On a past week, log 6:44 on Monday and 6:43 from Tuesday to Friday on a project
5. Check the Time Spent weekly total

=> the weekly total 33:36 shows in red with a -8:24 overtime while the employee worked exactly the 33h36 expected by the schedule

Ticket [link](https://www.odoo.com/odoo/project.task/6352965)

opw-6352965

l10n_vn_pos_symbol carries groups='base.group_system,point_of_sale.group_pos_manager', but _prepare_invoice_vals reads it while an ORDINARY salesperson closes an order: _process_saved_order calls _generate_pos_order_invoice as the acting user, with no sudo anywhere on the way. So on a Vietnamese POS with auto-send to SInvoice enabled, a user in point_of_sale.group_pos_user alone hit

  Access Denied by ACLs for operation: read, model: pos.config, fields: l10n_vn_pos_symbol

and the order never finished syncing - the receipt screen's Done button stayed disabled and the checkout dead-ended.

This is reachable from the module's own test suite, which is what makes it more than theoretical: point_of_sale's start_pos_tour logs in as `pos_user` (group_pos_user, NOT group_pos_manager - that is `pos_admin`), so test_l10n_vn_edi_pos_refund_reason_tour exercises exactly the unprivileged path.

Reading the config as sudo is the right resolution rather than widening the field's groups: the salesperson is never shown the symbol or allowed to change it, it is only stamped onto the invoice their own sale produces, which is what a per-POS configuration field is for. Both symbols are read through the same sudo recordset so the company-level fallback keeps working identically.

Reproduced and verified on v18_full (5-repo addons path):
  before - FAILED: [13/36] Tour L10nVnEdiPosRefundReasonTour -> "go to next screen from
           receipt"; 1 failed, 0 error(s) of 1 tests
  after  - tour succeeded for both tours in the class; 0 failed, 0 error(s) of 2 tests,
           and no ACL line left in the log




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

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

### Steps to reproduce:
- Download 'Sales' and 'Timesheets' apps
- Create a service product:
    - Invoicing policy = Based on Delivered Quantity
    - Track service =Timesheets on tasks
- Create and confirm a sale order for quantity 1
- Log 20h on the task. Create Invoice → 20.00. Then, post
- On the invoice: Reverse → Partial Refund, set the credit-note quantity to 11.00
- Post credit note → qty_invoiced = 9.00
- Log 5h. Create Invoice → 16.00. Post. (this part was already fixed, see below)
- Log 3h. Create Invoice
> Expected: an invoice for 3.00h — qty_delivered (28) - qty_invoiced (25)
> Actual: a credit note (out_refund) for 6.00h

### Cause of Issue:
A previous [PR](https://github.com/odoo/odoo/pull/268025) fixed a related issue where `_recompute_qty_to_invoice` failed to account for hours already invoiced/refunded when a credit note had been posted against a prior invoice, causing already-invoiced hours to be re-invoiced.

However, that approach relies on invoice *lineage* (which invoice was reversed) rather than on the actual net amount already invoiced.
https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/sale_timesheet/models/sale_order_line.py#L183 This caused the already-resolved refund to be subtracted a second time (3-(20-11) = -6), producing a negative `qty_to_invoice` and, consequently, a credit note instead of an invoice for the newly logged hours.

### Fix:
Replace the lineage-based tracking with a simpler and more efficient way that holds across any number of refund/re-invoice cycles.
In case there are refund moves:
`qty_to_invoice = total_delivered_quantity − net_posted_invoiced_quantity`

`net_posted_invoiced_quantity` is computed directly from all **posted** invoice lines linked to the
SO line, without needing to determine which invoice a given credit note was reversing or whether
its timesheets have since moved to a newer invoice.

And in case of no refunds (less complex flow), we only include the relevant timesheets.

opw-6253650

Deleting a draft customer invoice linked to timesheets resets their timesheet_invoice_id so the hours become invoiceable again. This write also marks the timesheets' so_line for recompute, and the re-derivation runs while the lines are no longer protected by the invoice link. When the task or project no longer resolves to a sale order item (e.g. it was unlinked after invoicing), the timesheets lose their sale order item or get reassigned to another one, so the delivered hours silently disappear from the original order line.

Protect so_line during the write and drop the pending recompute: deleting an invoice must only make the hours invoiceable again, not change their allocation.

Steps to reproduce:
- Install Sales and Timesheets
- Create a service product with invoice policy "Based on Timesheets" and "Create a task in a new project"
- Create and confirm a sale order with this product
- Log a timesheet on the generated task
- Create the invoice (keep it in draft)
- Remove the Sales Order Item from the task and from the project settings (or point them to a sale order item of another order)
- Delete the draft invoice
- Open the timesheet: its Sales Order Item is emptied (or replaced by the other order's item, whose delivered quantity now includes the hours sold on the original order), and the original line's delivered quantity is reset

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

Forward-Port-Of: odoo/odoo#279552

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

**Problem**

Opening a location applies the default filter `qty_available > 0 | virtual_available < 0`.
Both fields are computed and non-stored, so each leaf goes through
`_search_product_quantity`, which ran `search([])` and evaluated the operator in
Python over the whole catalog:

- `_compute_quantities_dict` `_read_group`s quants **and** incoming/outgoing moves,
  even when the searched field only needs quants, each scoped with
  `product_id IN (all_ids)`.
- `_compute_quantities` then materialises every product through the ORM: it zeroes
  five fields on each one and loops calling `.update` per product.
- `filtered_domain` iterates the full recordset to evaluate the operator.

Nothing is queried per record, but every step scales with the *total* number of
products, so runtime and (batched prefetch) queries grow with the catalog instead of
with the number of products that actually have stock.

**Solution**

Aggregate the underlying quants/moves once and evaluate the operator per product on
plain dicts:

- Only query what the field needs (`need_quant`/`need_in`/`need_out`); a search on
  `qty_available` no longer touches moves.
- No `product_id IN (...)`: the `GROUP BY` only returns products that actually have
  quants/moves, bounding the work by stock rather than by catalog size.
- Products with neither quant nor move have an implicit value of 0 and are never
  loaded: when 0 satisfies the operator the result is returned as
  `id not in <aggregated products that failed>`, otherwise as `id in <matches>`.
- `_compute_quantities` is never called, so no full-catalog ORM materialisation.

The context keys that scope or time-shift the quantity (`lot_id`, `owner_id`,
`package_id`, `from_date`, `to_date`) are applied to the aggregation domains exactly
as `_compute_quantities_dict` does. Like that method's raw aggregates, per-UoM
rounding is ignored, and — as the search already did — kit BoMs are not expanded.

Pre-fix:
| Unique products in location | Search Domain | (Moves=Quants) / Product | Run time | Queries |
|---|---|---|---|---|
| 1,000 | [("virtual_available", ">", 0)] | 1 | 0.15 Seconds | 125 |
| 10,000 | [("virtual_available", ">", 0)] | 1 | 1 Second | 420 |
| 100,000 | [("virtual_available", ">", 0)] | 1 | 10.6 Seconds | 3,400 |
| 100,000 | [("virtual_available", ">", 0)] | 10 | 12.0 Seconds | 3,550 |
| 100,000 | [("virtual_available", ">", 0)] | 50 | 14.5 | 3,700 |
| 500,000 | [("virtual_available", ">", 0)] | 1 | 60.4 Seconds | 17,000 |
| 500,000 | [("incoming_qty", ">", 0)] | 1 | 60.5 Seconds | 17,000 |
| 500,000 | ['or', ("incoming_qty", ">", 0), ("virtual_available", ">", 0)] | 1 | 63 Seconds | 17,170 |

Post-fix:
| Unique products in location | Search Domain | (Moves=Quants) / Product | Run time | Queries |
|---|---|---|---|---|
| 1,000 | [("virtual_available", ">", 0)] | 1 | 0.07 Seconds | 100 |
| 10,000 | [("virtual_available", ">", 0)] | 1 | 0.3 Seconds | 110 |
| 100,000 | [("virtual_available", ">", 0)] | 1 | 2.5 Seconds | 150 |
| 100,000 | [("virtual_available", ">", 0)] | 10 | 3.5 Seconds | 150 |
| 100,000 | [("virtual_available", ">", 0)] | 50 | 4.9 Seconds | 150 |
| 500,000 | [("virtual_available", ">", 0)] | 1 | 6.8 Seconds | 250 |
| 500,000 | [("incoming_qty", ">", 0)] | 1 | 3.2 Seconds | 130 |
| 500,000 | ['or', ("incoming_qty", ">", 0), ("virtual_available", ">", 0)] | 1 | 10.3 Seconds | 315 |

opw-6379459