**Steps to Reproduce**

* Install `sale_management`, `purchase`, and `stock` with demo data.
* In Inventory → Settings, enable `Dropshipping`.
* Create a product: 
     * Set a vendor under the Purchase tab. 
     * Set routes to `Dropshipping` and `Buy`
* Create and confirm a sale order for this product.
* Confirm the generated purchase order.
* Cancel the originating sale order.
* Go back to the linked purchase order.

**Observed behavior**

* Two activities are created on the purchase order when the sale order is cancelled.

**Cause**

* Both templates — `exception_on_so` (from sale_stock) and
`exception_purchase_on_sale_cancellation` (from sale_purchase) 
are triggered during sale order cancellation.

* Each module overrides `_action_cancel` and triggers its corresponding exception template.

* When both modules are installed, both templates run.

https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_purchase/models/sale_order.py#L26-L32

https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_stock/models/sale_order.py#L206-L208

* The template `exception_purchase_on_sale_cancellation` should only be triggered
when the PO originates from an SO and the product is a service, but
the domain lacks the required product-type condition.

**Fix**

* Add the missing condition to ensure that `exception_purchase_on_sale_cancellation`
is not triggered for dropshipped products, preventing duplicate activities.

---
`NOTE` - This issue is resolved from version 19.0 in this [commit](https://github.com/odoo/odoo/pull/212679/changes/ede2898278220a3ba4d8910ef268fe59f1587c72)

---
opw-5153488

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

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 base lines of type entry which have a balance of the same sign as the tax line. Yet 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 is only considering lines with the same sign 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"

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

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

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