### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 
However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37
But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Enterprise: https://github.com/odoo/enterprise/pull/86394

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

Forward-Port-Of: odoo/odoo#211616

Currently in MX localization we allow updating existing bills when users upload a CFDI XML [1]
However, we might change the bill source PO with a wrong one in case we have similar records

Steps to reproduce:
- With an MX Company setup
- Create a PO [PO1] with [Partner] and a line and confirm it
- Create an identical PO [PO2], confirm it, receive and create bill (Note: the bill is currently associated with PO2)
- In the bill upload the corresponding xml bill

Issue: After uploading the document, the bill will be associated to PO1

This occurs because in case of CFDI xml bills we process the attachment and update the bill even if some lines already exists. The system tries to find a PO not yet invoiced to associate with the bill, and finds PO1 which is identical to PO2 but not invoiced yet

A solution would be to avoid changing the source purchase order when we want to just extend the bill with an attachment

[1] https://github.com/odoo/odoo/commit/e05457c51e7a03115ba37a196e88a199b7682501

opw-4521106

Forward-Port-Of: odoo/odoo#211252

To be able to merge moves, the 'price_unit' fields needs to be equal. However, if the product price decimal accuracy is higher than the currency decimal accuracy, then price_unit that looks the same are actually not, and prevent the merge.

It can happen in 2 situations:
- Python rounding precision: 55.55 != 55.5500000000001
- Tax involvement: If a tax is present on the Purchase Order, then the price unit will be recomputed to check the tax, with something similar to `CURRENCY_ROUND(price_unit * qty) / qty`, and because the currency rounding is less precise, the resulting price_unit will vary depending on the quantity.

A similar issue was already fixed in this commit: a7f08f0b4c87aeb60315d07c2e0a5fc4c7a21e50 ,but only for decrease of quantity.

This fix attempts to fix the increase of quantity. The main issue when fixing this problem is that we can't simply use float_compare, this is because the move values are fetched with _itemgetter_, and are 'compared' when _groupby_ is using these values as dictionary key.

The idea is to create a custom _itemgetter_, that will cast the price_unit as a string using the correct precision.

So, the list of values used in the group by will now look like this:
```
(product.product(84,), 'make_to_stock', ..., '25.67')
```
While it previously looked like this:
```
(product.product(84,), 'make_to_stock', ...,  25.668000000000003)
```

---

## How to reproduce
- Create a Storable product.
- Change the decimal accuracy of product price to 5.
- Create a purchase order for 10 units of P, and a price unit of 25.66803.
- Ensure a tax is set on the PO
- Confirm the order
- Edit the PO line quantity to 13 => The receipt has 2 lines of P, one for the first 10 units and the other for the added 3 units

https://github.com/user-attachments/assets/d93f697f-126a-44e5-b134-5bfc8f3ccc68

---

Test results without fix:
```
2021-01-14 09:12:15,000 21884 ERROR oes_17_test odoo.addons.purchase_stock.tests.test_purchase_order: FAIL: TestPurchaseOrder.test_05_po_update_qty_stock_move_merge
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/purchase_stock/tests/test_purchase_order.py", line 442, in test_05_po_update_qty_stock_move_merge
    self.assertEqual(len(purchase_order.picking_ids.move_line_ids), 1)
AssertionError: 2 != 1
```

---
OPW-4675425

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

Forward-Port-Of: odoo/odoo#210077

Currently, an exception is raised when validating a new receipt transfer where both the stock move and the push rule have the same destination location.

Steps to Reproduce:

1. Install `stock`  module
2. Enable Multi-Step Routes in Inventory
3. Routes -> Enable Warehouses and ensure they are linked to `YourCompany`.
4. Create a new rule for that route.
5. Set action to 'Push To' with same source and destination (e.g., WH/Stock) and Automatic Move to 'Automatic No Step Added'.
6. Go to Inventory -> Operations-> Receipts
7. Create a new receipt with the same destination location as defined in the rule.
8. Click on Validate

TypeError:
```TypeError
unsupported operand types in: stock.move() - None
```

This issue[1] occurs when the rule and stock have the same destination location. It does not execute and returns None, resulting in new_move being None. When `move.move_dest_ids - new_move` is executed, it raises an error.

[1]- https://github.com/odoo/odoo/blob/5c182227514af87659ee48360c63f33487de71bf/addons/stock/models/stock_move.py#L1048

sentry-6551676919

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

Forward-Port-Of: odoo/odoo#206850

**Steps to reproduce:**
- Install account_accountant and l10n_es_edi_tbai
- Create 2 companies with 2 different currencies having different rounding factors:
  * a Spanish company with EUR (rounding factor: 0.01)
  * another company with another currency (rounding factor: 1.0)
- For the other company, select "Round Globally" in Accounting settings

- Switch to the Spanish company
- Create an invoice:
  * Customer: [a Spanish customer]
  * Lines: [any with a tax generating a tax amount with a decimal part]
- Save the invoice

- In the company selector, select both companies with the other one as the main one
- Confirm the invoice
- Send it to "TicketBAI (ES)"
- Download the electronic invoice and check it

**Issue:**
In the XML, the value of "CuotaImpuesto" is the tax amount but it has been rounded with the decimal precision of the currency of the main selected company instead of tthe currency of the invoice.

**Cause:**
In "_prepare_invoice_aggregated_taxes" method, "_aggregate_taxes" is called in which some rounding are done using the currency of "self.env.company".
But in this case, "self.env.company" is not the company of the invoice and the currency used for the rounding isn't the one set on the invoice.

opw-4724945




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

Forward-Port-Of: odoo/odoo#211841

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

### Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37 But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Community: https://github.com/odoo/odoo/pull/211616

opw-4798349

Forward-Port-Of: odoo/enterprise#86394

**Problem:**
When internal transfer operation type has a manadatory destination
in barcode, the transfer can still be validated without destination
location scanned if it's a package

**Steps to reproduce:**
- In settings, enable the "packages" settings
- Navigate to Inventory/Configuration/Warehouse Management/
Operations Types
- Select "Internal Transfers", in the "Barcode App" page for Source
Location, select Mandatory Scan
- for "Destination Location" select "after each product"
- create a new storable product
- Navigate to Inventory/Operations/Physical Inventory
- Create a new line and select stock as the location
- Select your product
- In the package column, create a package and give it a name
- Set a quantity > Apply
- Open the barcode app, select operations and then internal
transfers
- Click on New and then Scan WH-Stock and the package name: PACK

**Current behavior:**
 The validate button is higlighted in green and clickable

**Expected behavior:**
Because we didn't scan a destination location it shouldn't be 
green and clickabel

**Cause of the issue:**

When a package barcode is scanned, when _processBarcode calls
_processPackage 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1007
Inside _processPackage 
barcodeData.stopped is set to true (1)
and this.selectedLineVirtualId is set to false (2) 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L1532-L1533
Because of (1) _processBarcode returns here 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1008-L1011
and doesn't reach the part of the method where _selectLine is called  
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1181-L1182
(Inside _selectLine the value of selectedLineVirtualId is defined
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1269-L1274
)

So as a consequence of (1) and (2) the value of this.selectedLineVirtualID is 
false when a package is scanned

When the validate method is called when the user clicks on validate,
the method uses the value of this.selectedLine
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L777-L779
Because this.selectedLineVirtualID is false, get selectedLine returns false
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L307-L309
So the if condition is false, the method is allowed to run and 
the error notification is not triggered


**Fix:**
After scanning a package there is no selectedLine so we need another
condition


opw-4590345

Forward-Port-Of: odoo/enterprise#83710

Currently, when a user sends an article to the trash, the system triggers a notification email to relevant members informing them that the article has been trashed and will be permanently deleted in 30 days (see: `knowledge_article_trash_notification`).

This email includes a link to the trashed article (see: `article_url`). However, when a user clicks the link, they are taken to a 403 error page and cannot access the article to review or restore it.

Steps to reproduce the issue:
1. Open an article
2. Send the article to the trash
3. Open the notification email and click on the article link

=> The user is redirected to a 403 error page

When an article is trashed (see: `action_send_to_trash`), it is marked as inactive. As a result, it is excluded from ORM search results by default.

The `/knowledge/article/<id>` route uses the ORM to retrieve the article by its ID. Since trashed articles are inactive, the ORM does not return the article, leading the route to assume the article does not exist and redirect the user to a 403 error page.

To resolve this issue, we will modify the context of the search method to include the key `active_test=False`. This will allow the ORM to return inactive (trashed) articles. As a result, users who follow the link from the email will be correctly redirected to the trashed article page, where they can view its content and choose to restore it using the banner interface.

Task-4636494

Forward-Port-Of: odoo/enterprise#86065

The `action_timer_start` method caused infinite recursion when the user's timezone differed from the timesheet's timezone. The comparison between `fields.Date.today()` and `self.date` failed, creating a new timesheet.  That new timesheet triggered `action_timer_start` again, repeating the loop. 

**Steps to Produce:-**
1. Install the `Timesheets` application.
2. Navigate to `Settings > Users & Companies > User`.
3. Select your current user and, under `Preferences`, set the timezone to one that does not reflect today’s date.
4. Open the Timesheets application, and for any record, click on the `Search icon` in the column for today’s date.
5. Start the time tracking by clicking the `Play button`.
6. Wait for a moment; an error will generate.

**Error:-**
`RecursionError: maximum recursion depth exceeded.`

**Solution:-**
   - When action_timer_start() is invoked, it first checks for the _from_action_timer flag in the context.
   - If not set, it sets _from_action_timer=True.
   - The next time action_timer_start() is triggered, the presence of _from_action_timer in the context causes it to exit early, 
     preventing recursion.

**Sentry - 6592348827**

Forward-Port-Of: odoo/enterprise#85105

Currently, an error-level log is generated when confirming a Vendor Bill without setting the required AFIP Authorization Code.

**Steps to Reproduce:**
1) Install `l10n_ar_edi module`.
2) Select Company having Argentina code (e.g **(AR)Exento**) 
3) Navigate to `Invoicing->Configuration->settings`, under Argentina localization,
   set `Verify Vendor Bills validity in AFIP` to **required**.
4) Create a new Vendor Bill, select Vendor Name (e.g **ADHOC SA**).
5) Click on confirm.

**Error:**
UserError('Please set AFIP Authorization Mode and Code to continue!')

**Root Cause:**
- The code  calls `_logger.error(repr(error))` on any exception at [1] during the AFIP verification attempt, causing an ERROR‐level log entry.

[1]- https://github.com/odoo/enterprise/blob/ca16c89c6f53b1c0adb0a1a061d985bdf3439e5e/l10n_ar_edi/models/account_move.py#L500

**Solution:**
- This commit handles `UserError` exceptions separately using a warning log to prevent error-level entries.

Sentry-6576006813

Forward-Port-Of: odoo/enterprise#85261

Currently, an error occurs when updating data for payroll if a referenced partner record has been deleted by the user.

**Steps to produce:**
- Install the `contacts` and `l10n_ma_hr_payroll` module.
- Delete the partner **National Social Security Fund**.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.

**Error:**
`ValueError: ParseError('while parsing /home/odoo/src/enterprise/saas-18.3/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml:169 ...`

The error occurs because the method at [1] tries to load the `hr_salary_rule_data.xml` file, which references a deleted `partner_id` [2], resulting in a parsing failure.

[1] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/models/hr_payslip.py#L9
[2] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml#L169

This commit ensures that all the referenced data is loaded properly, preventing errors due to missing references.

Sentry - 6617089492

Forward-Port-Of: odoo/enterprise#85979