When opening the Auto Reconcile wizard for AMLs belonging to different companies
with different currencies, a traceback is raised.

Steps to reproduce the error:
- Install ``accountant`` module with demo data
- Create a new company A > switch to company A > In Settings, set the Fiscal Localization to Generic Chart of Accounts.
- Change Company A’s currency to ``EUR``
- Create a new chart of account > Type: Receivable > Allow Reconciliation: True >
  Companies: YourCompany and Company A >
  Set the code separately for each company
- Enable multi-companies with YourCompany and Company A
- Create 2 invoices, one for each company > Journal Items Tab, assign the above receivable account in receivable account > Confirm both invoices
- Go to Accounting > Accounting > Reconcile > click the Auto-reconcile button next to the receivable account created above

Traceback:
```py
ValueError: Expected singleton: res.currency(1, 124)
```

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/account_accountant/wizard/account_auto_reconcile_wizard.py#L69
Here, When AMLs belong to different companies,
``amls.company_currency_id`` contains multiple currencies.
So, it will raise the above error when opening auto reconcile wizard for that amls.

sentry-7031018807

The system will crash with error when user try to create new operation type in recepit.

**Steps to produce:**
- Install `Inventory` module with demo data.
- `Inventory > Configuration > Settings > under Warehouse > Enable Storage Locations`.
- Inventory > Receipts > Open any receipt > remove value of `Operation Type` and then `Source Location`.
- Type test in `Operation Type` and click on `create` > click discard.

**Error:**
`ValueError: Expected singleton: stock.location()`

**Cause:**
- When we remove the `Operation Type` and the `Source Location` values from the picking, and then try to create a new operation type and then `discarding the wizard` triggers the `onchange`, which then raises the error from [1].

**Solution:**
- We can prevent this error by checking `picking.location` before doing `picking.location_id.should_bypass_reservation()`.

[1]https://github.com/odoo/odoo/blob/483ce91547b8045e8dfaa6ae8cac8573a01f54d0/addons/stock/models/stock_picking.py#L837

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

Currently, an error occurs when the user validates a POS order.

Steps to Reproduce:

 - Install the `l10n_br_edi_pos` module.
 - Switch to a `BR company` and remove the `State` from the company address.
 - Set up the `AvaTax` account with the `API ID and API Key`.
 - Go to `Products`, select a product that is not of type Service, and in the `Sales` section enter a value in the `Mercosul NCM Code` field.
 - Go to `Point of Sale` > open a `session` > add that `product` > `Payment` > `Validate`.

`KeyError: False`

This error occurs when the user validates a POS order while the company’s State field is empty. During validation, the system attempts to generate the access key [1] based on the company data. As part of this process [2], it attempts to retrieve the CUF code using the state code. Since the state is not set, the state code is False, which results in a KeyError at [3].

This commit ensures that when the system tries to generate the access key, it raises a UserError if the State field is missing.

[1]- https://github.com/odoo/enterprise/blob/6c3cf27c87c9156182b5ac77a493d33bdff81f9d/l10n_br_edi_pos/models/pos_order.py#L586

[2]- https://github.com/odoo/enterprise/blob/6c3cf27c87c9156182b5ac77a493d33bdff81f9d/l10n_br_edi_pos/models/pos_order.py#L467

[3]- https://github.com/odoo/enterprise/blob/6c3cf27c87c9156182b5ac77a493d33bdff81f9d/l10n_br_edi_pos/models/pos_order.py#L458

senrty-7049618190

The system crashes when the user tries to reschedule a work order.
    
Cause:
- When the user triggers a reschedule, the method `web_gantt_reschedule` calls
 `_web_gantt_action_reschedule_candidates` at [1].
 That method then calls `_web_gantt_move_candidates` at [2], which in turn calls
 `_web_gantt_reschedule_compute_dates` at [3]. Inside that method,
 `_get_first_available_slot` is called at [4].

- At [5], `_get_first_available_slot` may return a boolean value and a message
 when there is no available slot 700 days after the planned start.
 Since the caller expects date values instead, an error is raised.

Error:
`AttributeError: bool' object has no attribute 'astimezone'`

Solution:
- Display a proper error message to the user instead of triggering a crash.

[1]: https://github.com/odoo/enterprise/blob/a20aef4d892d0126527b7d3b0760819bb2064927/web_gantt/models/models.py#L214
[2]: https://github.com/odoo/enterprise/blob/a20aef4d892d0126527b7d3b0760819bb2064927/web_gantt/models/models.py#L429
[3]: https://github.com/odoo/enterprise/blob/a20aef4d892d0126527b7d3b0760819bb2064927/web_gantt/models/models.py#L546
[4]: https://github.com/odoo/enterprise/blob/a20aef4d892d0126527b7d3b0760819bb2064927/mrp_workorder/models/mrp_workorder.py#L653
[5]: https://github.com/odoo/odoo/blob/e4e7efffade8542756e9504820ef4e3e419381b4/addons/mrp/models/mrp_workcenter.py#L380

sentry-6950609055

Currently, when saving a report with invalid XML syntax raises an error

**Steps to Reproduce:**
1) Install sales,studio app (with Demo)
2) Open Sales app and switch to studio mode.
3) Open any Report from the studio mode.(e.g. PDF Quote). 
4) Edit Source code and remove the `t-if` part from the code.
   (e.g remove `t-if='is_proforma'>Issued Date`) and save the report.

**Error:**
`QWebError: Error while rendering the template:`
`SyntaxError: t-elif directive must be preceded by t-if or t-elif directive`

**Root Cause:**
On following above steps, the invalid QWeb XML is passed through `_render_report()` from [2], which triggers a parsing failure in the QWeb engine at [1]. The exception is not caught within Studio, resulting in an error.

**Fix:**
This commit improves error handling by raising UserError if QWebError occurs.

[1]: https://github.com/odoo/odoo/blob/fb27059536d77a26874e6bf9d743b9aa4ecc9522/odoo/addons/base/models/ir_qweb.py#L1851-L1852

[2]: https://github.com/odoo/enterprise/blob/85e81587018803167ec0bd86a926f1d11f535e1b/web_studio/controllers/report.py#L701

sentry-6941258628

Currently, an error occurs when the UrbanPiper store webhook executes after the POS ID has been removed from the POS Shop configuration.

**Steps to Reproduce:**
1. Configure UrbanPiper with a pos shop.
2. Toggle the store service (e.g., zomato) activate/deactivate multiple times on POS Shop (It takes time to process).
3. While webhook processing is pending, close the register and remove the POS ID from the configuration.
4. Once the delayed webhook event executes, an error is raised.

Video Reference: https://drive.google.com/file/d/1T-V4ph81MhH6xW-rh0E4vw1GhV-1MMMX/view?usp=drive_link

**Error:**
`ValueError - Expected singleton: pos.config()`

**Cause:**
The webhook attempted to update a store configuration using a POS ID that no longer exists, causing a singleton error.

**Fix:**
This commit ensures `pos_config_sudo` exists before calling `_store_action_update(data)`. If no record is found, log a warning and skip processing to prevent the error.

sentry-6931073324

The error occurs when a user tries to sync orders from the Amazon account.

**Error: -**
```
NotNullViolation: null value in column 'currency_id' of relation 'product_pricelist' violates not-null constraint
DETAIL:  Failing row contains (5, 16, null, 1, 1, 1, {'en_US': 'Amazon Pricelist False'}, f, 2025-09-12 04:01:41.571883, 2025-09-12 04:01:41.571883).
```

**Root cause: -**
- In `_prepare_order_values` (see [1]), if the order currency does not exist in `res.currency` (deleted by the user), the search returns an empty record.
- Then `_find_or_create_pricelist` (see [2]) is called with this empty record, which leads to the error at (see [3]).

**Solution: -**
- In this commit, if currency is not found, fall back to the company’s default currency.

[1]: https://github.com/odoo/enterprise/blob/c99bd493b33773e4a4686b03363583a9edacb17a/sale_amazon/models/amazon_account.py#L673-L676
[2]: https://github.com/odoo/enterprise/blob/c99bd493b33773e4a4686b03363583a9edacb17a/sale_amazon/models/amazon_account.py#L706
[3]: https://github.com/odoo/enterprise/blob/c99bd493b33773e4a4686b03363583a9edacb17a/sale_amazon/models/amazon_account.py#L1099

**sentry-6719663911**

Currently, deleting a default country group leads to errors in modules which rely on these groups.

**Steps to reproduce:**
1. Install `contacts, account_edi_ubl_cii, l10n_be` modules.
2. Switch company to "BE Company CoA".
3. Open country group and delete "European Union".
4. Create an Invoice.

**Error:**
`ValueError - External ID not found in the system: base.europe`

**Cause:**
Default country groups are referenced in various modules. Deleting them breaks these references, causing errors when related actions are performed.

**Fix:**
Prevent deletion of default country groups by raising a user error when deletion is attempted.

**Refs:**
[1]: https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/account/models/partner.py#L257 [2]: https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/account_edi_ubl_cii/models/account_edi_common.py#L186 [3]: https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/account_qr_code_sepa/models/res_bank.py#L51 [4]: https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/l10n_gcc_invoice/models/account_move.py#L24

sentry-6857603868

_
## Short functional explanation of the error
When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly.

## Reproduction Steps
1. Go to attendances.
2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes.
3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12.

### Expected behavior
As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed.

### Unexpected behavior
12 minutes of overtime are computed.

## Origin of the issue
Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time.

Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code.

note: the same bug exists for the employee tolerance time, which
is corrected in this commit.
__
opw-5136861

---

Forward-Port-Of: odoo/odoo#242517

# [FIX] delivery_sendcloud : Adapt "test_multicollo" and "test_sendcloud_picking_batch_validation"

Before this commit, there was some nightly tests, that where not executed successfully.

The test `test_multicollo()` was break during the quantity pocalypse so I replaced the `quantity_done` to use quantity and picked.
There was also an issue with the parcel weight assertion, because the parcel weigh is averaged now so I multiply it by the parcel quantity.
That average change is in the function `_prepare_parcel` inside `sendcloud_service.py` : 
```py
'weight': `float_repr((sum(p.weight for p in pkg)/len(pkg)), 3)`,  #weight gets multiplied with quantity in sendcloud backend.
```

The test `test_sendcloud_picking_batch_validation()` used an unexisting function `action_set_quantities_to_reservation` that wasn't necessary anymore, so I removed it.
I also fixed the path to _send_shipment that was false.


# [FIX] delivery_bpost, delivery_dhl_rest, delivery_usps, delivery_usps_rest: make shipping documents use english or partner language for product description

## Issue: ##
Before this commit, the commercial invoices product's description used the database language
This may cause issues with customs when the language was neither English nor the destination country’s language

## Cause: ##
No language context was applied when generating product descriptions for shipping documents

## Fix: ##
To apply this change to most shipping connectors, we updated the `_get_commodities_from_order()` and `_get_commodities_from_stock_move_lines()` functions
This PR is linked to a community one with the main fix, the PR is only to fix the connectors that don't rely on those methods
Link: https://github.com/odoo/odoo/pull/221508

## Steps to reproduce: ##
The steps depends on the shipping connectors
The community PR will give a Step by step guide for Delivery_Sendcloud

opw-4742861

## Issue: ##
Before this commit, the commercial invoices product's description used the database language
This may cause issues with customs when the language was neither English nor the destination country’s language

## Cause: ##
No language context was applied when generating product descriptions for shipping documents

## Fix: ##
To apply this change to most shipping connectors, we updated the `_get_commodities_from_order()` and `_get_commodities_from_stock_move_lines()` functions
An enterprise PR has been for connectors that don't rely on those methods
Link: https://github.com/odoo/enterprise/pull/87417

## Steps to reproduce: ##
The steps depends on the shipping connectors, here is steps for Delivery_sendcloud:
- Create a product with a name that can be translated, for example in French
- Setup a Sendcloud connection with a international shipping service

- Set the delivery contact language to English
- Validate a transfer with a commercial invoice (need to be international)
- The product language should be English

- Repeat the step with the other language for the product translation, like French
- The product's name in the commercial invoice should be in the other language

opw-4742861

Steps to reproduce
------------------
1. Make an order with a single payment method, say Bank, with amount X
2. On the receipt screen, click "Edit Payment", the modal will open
3. On the payment tab, change the amount of the current payment line to X - Y
4. Add another payment line with a different with amount Y, so the total is X
5. Save the edits

Notice that on the receipt, instead of seeing 2 lines, the edited one and the newly added one, we see 3 lines: the old edited line as expected, but we see the new line twice, it's duplicated!!

The reason
----------
When saving the changes, we call `await this.data.read("pos.order", [record.evalContext.id]);` [1] which adds the new payment line to the order in the cache, the old one and also the new one. When doing so, we assign a `uuid` to that new line since it's the first time we encounter it in the data_service. [2], but we don't save this new uuid to the backend yet, that will be important! Till here all is good. We will refer to this as step 1.

Now in step 2, we call `await this.data.read("pos.payment",` [3] to apply the updates to the existing payment lines, but as argument we're passing the two lines not just the old one, so we are refetching both lines, and we see that the new line doesn't have a `uuid` (since the above uuid was not saved to backend!!), so we think it's another new payment line and we link it again to the order, so we end up with 3 lines on that order.

The fix
-------
We only need to apply the udpates for the old lines in step 2, since the new ones are already updated in the cache by step 1.

[1]: https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/point_of_sale/static/src/app/store/pos_store.js#L1934
[2]: https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/point_of_sale/static/src/app/models/related_models.js#L497
[3]: https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/point_of_sale/static/src/app/store/pos_store.js#L1935-L1938

opw-5317680

Steps to reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Currently, an error occurs when user sets the resource on a resource leave.

**Steps to Reproduce:**

 - Install `hr_contract` with demo data.
 - Go to `Resource Time Off`.
 - Create a new record and remove the `start date` value.
 - Select the `Anita Oliver` resource `(employee record with running contract)`.

**Error:**
`TypeError: '<=' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause:**
This error occurs when the user removes the start date and sets a resource that is linked to an employee with a contract. In this case, the system groups leave records based on the contract [1], and while computing calendar_id for the leave, it filters records by checking whether the leave start date falls between the contract start and end dates [2]. Since the leave start date is False, the comparison raises the error.

Another issue is that when the user changes the start date, the calendar_id should be updated based on the employee’s current contract.

**Fix:**
This commit ensures that when setting or changing the resource_id, for contracts with and without a start date, the calendar_id is computed correctly.

[1]: https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L17

[2]- https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L29

**No Task ID**


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

[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export

Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data.

Steps to reproduce:
- Install `l10n_ma_reports` and switch to the MA company
- Create and confirm a bill:
	Bill Date: 10/01/2025
	Vendor: Azure Interior
	Invoice Lines: Price 100, Taxes 20% (S 140)
- Go to `Bank Reconciliation`
- Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo)
- Select the transaction and the invoice, then click Validate
- Open the Tax Return for November.
	Section D should show data linked to the created invoice
- Export the XML using the Gear → XML
	The created bill is missing in the XML and others may be present, showing inconsistent data

opw-5002779


[IMP] l10n_ma_reports: call the report to compute the prorata value

Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file.