When transferring an order to a table that already has an open order, identical products are merged into a single line. If both orders were already sent to the kitchen printer, the merged line was incorrectly marked as new and had to be sent again.

Steps to reproduce:
-------------------
* Open table 1, add product A (2 units) and product B, send to kitchen
* Open table 2, add product A (3 units) and product C, send to kitchen
* On table 2, transfer/merge the order to table 1

> Observation:
product A shows 2 units as new and must be sent to the kitchen printer again, although all quantities were already sent.

Why the fix:
------------
When merging preparation history for identical lines, handlePreparationHistory overwrote the destination sent quantity with the source one instead of summing both. The kitchen diff then treated the missing quantity as new changes.

A unit test will be added in 18.3.

opw-6246470

Forward-Port-Of: odoo/odoo#271828
Forward-Port-Of: odoo/odoo#267915

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121677
Forward-Port-Of: odoo/enterprise#120967

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

The full composer builds default_partner_ids by doing recipient.persona.id over allRecipients. When a recipient is not linked to a partner, the chatter input inserts it with persona: false here:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/static/src/core/web/recipients_input.js#L151

false.id is undefined, so the wizard gets a bad id and clicking the recipient tag crashes with `Invalid ids list: false`.

The persona is false because /mail/partner/from_email returns no partner for unresolved emails when the user does not have base.group_partner_manager. That matches the gate _prepare_post_data already uses for the simple post flow:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/controllers/thread.py#L153,L155

The full composer just was not handling that case.

Filter out persona-less recipients from default_partner_ids so the wizard only sees real partner ids. The full composer now drops them the same way the simple post path already does.

Steps to reproduce:
1. As Administrator, create a user with the Sales group only (no Contact Creation).
2. Log in as that user.
3. Open a CRM lead whose Email is set but Customer is empty.
4. Click Send message.
5. Click the expand icon to open the full composer.
6. Click the recipient tag in the To field.

=> Recipient shows as Unnamed and clicking it raises an RPC error.

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


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

Forward-Port-Of: odoo/odoo#271422
Forward-Port-Of: odoo/odoo#251780

**Issue**
Quantity on subcontracted receipts could be overridden after running the
scheduler.

**Steps to reproduce**
- Create a subcontracting product
- Create a PO for 10 units of that product
- Go to receipt and open Subcontracting Productions'
- Change the quantity to 5
- Enable debug mode.
- Run Inventory/Operations/Procurement: run scheduler
- Return to the receipt
-> The receipt quantity is reset to 10 instead of remaining at 5.

**Cause**
Since the refactor introduced in commit: https://github.com/odoo/odoo/commit/fc66e2d4eb638f1486e69cd5920f02c787055da1,
subcontracting receipt moves are no longer automatically picked when the production quantity is modified.
In particular, this test case protects that behavior:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp_subcontracting/tests/test_subcontracting.py#L1629-L1631
When the scheduler runs:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L731
it computes the moves to assign:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L706-L710
However, subcontracting moves are still included in the assignment domain:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L680-L688
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/stock_rule.py#L127-L129
As a result, they are reassigned if they are not already picked:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_move.py#L1931-L1937

opw-6229668

Forward-Port-Of: odoo/odoo#270837

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates whether the real messages (as opposed to the empty phantom placeholder) are rendered. The mirroring effect both read `mountedAndLoaded` as a dependency and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write pair `[isLoaded=true, mountedAndLoaded=false]`; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window, it drives `mountedAndLoaded` back to false while `isLoaded` stays true. The settling patch then computes the very `[true, false]` pair that was already recorded, so the effect never re-runs: `mountedAndLoaded` is stranded at false and no message is ever rendered.

Depend on a monotonic `resetCount` bumped by `reset()` instead of on `mountedAndLoaded` itself. It is never written by the effect, so the recorded dependencies can no longer match the current ones after a reset and the effect always re-runs to re-sync `mountedAndLoaded` with `isLoaded`. `reset()` keeps clearing `mountedAndLoaded` as before (the false dip is needed for the reload scroll handshake), so the behaviour is otherwise unchanged.

https://runbot.odoo.com/odoo/error/940032

Forward-Port-Of: odoo/odoo#272504
Forward-Port-Of: odoo/odoo#272281

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Put your warehouse in delivery in 2 steps
- On the receipt operation type change the return operation type to be "pick" by default.
- Create and confirm a PO for 1 unit of P
- Validate the receipt > return > Create the return for 1 unit
- Change the operation type of the return from Pick to Delivery to return the product in one step.
- Validate the return
#### > The qty_received is updated from 1 to 2 instead of 0.

### Cause of the issue:

Updating the `picking_type_id` of the return will also update the `location_dest_id` to the default values:
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/stock/models/stock_picking.py#L1138-L1147
However, the default values of the `Delivery` is "Partner/customer". As such, the location dest of the move is also updated to be "Partner/customer". Now the issue is that the `qty_received` only considers moves to be returned if the location dest usage is not 'supplier':
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase/models/purchase_order_line.py#L226-L231 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L55-L67 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L76-L77 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/stock_move.py#L129-L131

opw-6292918

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

Forward-Port-Of: odoo/odoo#270438
Forward-Port-Of: odoo/odoo#269867

Issue:
----------------------------------------
Doing a search on skills, the employees with the skill but no slot in the time frame aren't shown.

Steps to reproduce:
----------------------------------------
- Install `planning_hr_skills`
- Make sure an employee has the skill "English" and no slots
- Open Planning and type "English" in the search bar, click to search on Skills
- The employee does not show up

Cause:
----------------------------------------
Using the search view on skills, a filter on `resource_ids` is in the domain with a `OR`:

https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/views/planning_slot_views.xml#L9

Then a new filter on `resource_ids` is added [here](https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/models/planning_slot.py#L14-L43) to do the search on the skill names: `[('resource_ids', 'in', matching_resource_ids)]`.

The domain is then something like this: 
`['&', ('resource_ids', 'in', matching_resource_ids), '|', ('resource_ids', '=', False), ('employee_skill_ids', 'ilike', 'English')]`.

Since fbf8b2ac67c71ca0abfc75df543069696bd2d29b the resulting domain passes through `filter_map_domain()`. `filter_map_domain()` will only keep the leaves on `resource_ids` and the default `AND` will be used between them resulting in: 
`['&', ('resource_ids', 'in', matching_resource_ids), ('resource_ids', '=', False)]` 
which fetches no resources.

So `_group_expand_resource_ids()` doesn't expand.

Solution:
----------------------------------------
Instead of adding the new leaf to retrieve the resources with the right skills, we replace the leaf on `employee_skill_ids`. This ensures the `OR` operations are kept by `filter_map_domain()`.

opw-6296755

Issue:
----------------------------------------
The Planning / Timesheets Analysis report doesn't include most of the planning slots if they have a calendar based on duration.

Steps to reproduce:
----------------------------------------
- Have a 1 day planning slot (8h-17h) for an employee with a calendar based on duration.
- Planning > Reporting > Planning / Timesheets Analysis
- The slot is not included in the report

Cause:
----------------------------------------
The update of how calendars work in saas-19.2 included the `duration_based` option but the query was not adapted. It still checks if the slot start time is lower than the calendar end time on that day:

```sql
F.start_datetime < (d.date::date + (A.hour_to || ' hour')::interval)
AND F.end_datetime > (d.date::date + (A.hour_from || ' hour')::interval)
```

But for duration-based calendars `hour_from` and `hour_to` are stored as `0.0`. So `F.start_datetime < (d.date::date + (A.hour_to || ' hour')::interval)` evaluates to False.

Solution:
----------------------------------------
If the calendar has `duration_based` to True we only check the date.

opw-6217643

**Issue**
Quantity on subcontracted receipts could be overridden after running the
scheduler.

**Steps to reproduce**
- Create a subcontracting product
- Create a PO for 10 units of that product
- Go to receipt and open Subcontracting Productions'
- Change the quantity to 5
- Enable debug mode.
- Run Inventory/Operations/Procurement: run scheduler
- Return to the receipt
-> The receipt quantity is reset to 10 instead of remaining at 5.

**Cause**
Since the refactor introduced in commit: https://github.com/odoo/odoo/commit/fc66e2d4eb638f1486e69cd5920f02c787055da1,
subcontracting receipt moves are no longer automatically picked when the production quantity is modified.
In particular, this test case protects that behavior:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp_subcontracting/tests/test_subcontracting.py#L1629-L1631
When the scheduler runs:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L731
it computes the moves to assign:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L706-L710
However, subcontracting moves are still included in the assignment domain:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L680-L688
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/stock_rule.py#L127-L129
As a result, they are reassigned if they are not already picked:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_move.py#L1931-L1937

opw-6229668

Forward-Port-Of: odoo/odoo#270837

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

**Issue**
Quantity on subcontracted receipts could be overridden after running the
scheduler.

**Steps to reproduce**
- Create a subcontracting product
- Create a PO for 10 units of that product
- Go to receipt and open Subcontracting Productions'
- Change the quantity to 5
- Enable debug mode.
- Run Inventory/Operations/Procurement: run scheduler
- Return to the receipt
-> The receipt quantity is reset to 10 instead of remaining at 5.

**Cause**
Since the refactor introduced in commit: https://github.com/odoo/odoo/commit/fc66e2d4eb638f1486e69cd5920f02c787055da1,
subcontracting receipt moves are no longer automatically picked when the production quantity is modified.
In particular, this test case protects that behavior:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp_subcontracting/tests/test_subcontracting.py#L1629-L1631
When the scheduler runs:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L731
it computes the moves to assign:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L706-L710
However, subcontracting moves are still included in the assignment domain:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L680-L688
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/stock_rule.py#L127-L129
As a result, they are reassigned if they are not already picked:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_move.py#L1931-L1937

opw-6229668

Forward-Port-Of: odoo/odoo#270837

The full composer builds default_partner_ids by doing recipient.persona.id over allRecipients. When a recipient is not linked to a partner, the chatter input inserts it with persona: false here:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/static/src/core/web/recipients_input.js#L151

false.id is undefined, so the wizard gets a bad id and clicking the recipient tag crashes with `Invalid ids list: false`.

The persona is false because /mail/partner/from_email returns no partner for unresolved emails when the user does not have base.group_partner_manager. That matches the gate _prepare_post_data already uses for the simple post flow:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/controllers/thread.py#L153,L155

The full composer just was not handling that case.

Filter out persona-less recipients from default_partner_ids so the wizard only sees real partner ids. The full composer now drops them the same way the simple post path already does.

Steps to reproduce:
1. As Administrator, create a user with the Sales group only (no Contact Creation).
2. Log in as that user.
3. Open a CRM lead whose Email is set but Customer is empty.
4. Click Send message.
5. Click the expand icon to open the full composer.
6. Click the recipient tag in the To field.

=> Recipient shows as Unnamed and clicking it raises an RPC error.

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


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

Forward-Port-Of: odoo/odoo#271422
Forward-Port-Of: odoo/odoo#251780

The following error is raised in the POS when paying with an Adyen terminal:
```
TypeError: Cannot read properties of undefined (reading 'uuid')
at Proxy.handleAdyenStatusResponse
```

Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so getPendingPaymentLine no longer returns it and the subsequent line.uuid dereference crashes.

opw-6237987 patched the same root cause on a single line by adding an optional chaining operator in isPaymentSuccessful, which only moved the crash to the next dereference.

Fetch the pending line once at the start of handleAdyenStatusResponse and bail out when it is gone, so every dereference below is safe. The same guard is added to the remaining branches of _adyen_handle_response for consistency with the existing Reject branch.

opw-6237987

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

Forward-Port-Of: odoo/odoo#270880
Forward-Port-Of: odoo/odoo#269720

## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

Forward-Port-Of: odoo/enterprise#121693

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238

Forward-Port-Of: odoo/enterprise#120219

### Steps to reproduce:
- Download Calendar and Contacts app
- Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies
- Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies
- Create a another user who also have access to both companies
- Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field
- Switch the company of the logged in user to the other company
- Open the test contact form, use the meeting smart button and create a new meeting
- Open the kanban contact view

 **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.**
### Cause of Issue:
When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user.

### Fix:
Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope.
Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance.

opw-5874204

Forward-Port-Of: odoo/odoo#248985

Issue:
---
Not having at least one variant created for a product template with
dynamic attributes can cause issues as it's expected a product template
to have at least one variant.

To reproduce:
1- Create a dynamic attribute with values.
2- Create a product and without saving:
 - Enable track inventory.
 - Add the dynamic attributes and values.

3- Save the product.
4- Click on forecasted quantity smart button:
 - There is a traceback.

5- Click on Replenish:
 - Unexpected behavior.

6- Click on `Product On Hand Quantity`:
 - No product will be shown if you try to add quantity.

Cause:
---
This is caused because there is no variant created. In the steps,
if you save the template once before adding dynamic attributes, a
single variant will be created which allows it to work without issue.

Fix:
---
we can fix the TB by hiding the forecasted qty smart button,
when there is no variant.

However, there will be still issue with `Replenish` flow, which
requires a variant. We could do the prevent the issue by ensuring
there is at least one variant.

opw-6260253

Forward-Port-Of: odoo/odoo#268879

Steps to reproduce
------------------
1. Install l10n_ke_edi_oscu_pos.
2. Select the Kenyan company.
3. Enable eTIMS on the PoS.
4. Register the products inside a combo, but not the combo itself.
5. Sell the combo in the PoS.

Observation
-----------
We see a warning that the combo must be registered to eTIMS, and the order can't be validated.

What's happening
----------------
In the PoS a combo adds a 0 price parent line for the combo product, but the combo is not a real item to send to eTIMS, only the products inside it are, and (as per step 4) the combo is not registered.

`checkEtimsFields` sees the combo as not registered, so it raises the warning in `showUnregisteredProductsWarning` and blocks the payment in `validateOrder`.

Fix
---
In the backend, we skip sending the parent combo line to eTIMS, and on the frontend, we make the combo parent line not need eTIMS registration, so the warning and the block don't apply to it.

Note
----
Pushing onto `tax_ids` in the order widget makes the Kenyan receipt crash with "The 'tax_ids' array cannot be modified. Use the update method instead.", so we assign the taxes instead of pushing them.


opw-6253306

Forward-Port-Of: odoo/enterprise#121831
Forward-Port-Of: odoo/enterprise#119362

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

### Steps to reproduce:

- Ensure `sale_stock_renting` is installed
- Enable Multi-Steps Routes > Unarchive MTO
- Create a product P with a BoM and the routes MTO + manufacture
- Create anc confirm a sale order for A unit of P
- Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO)
- Open the MO, add a component line and save
#### > Access Error: Blame the following rule: - Personal Order

### Cause of the issue:

Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423
During this confirmation process, one calls the `_merge_moves` method in order to  merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576
Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO:
https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40
However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record:
https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49

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

opw-6275658

Forward-Port-Of: odoo/enterprise#121510
Forward-Port-Of: odoo/enterprise#121135

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089




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

Forward-Port-Of: odoo/odoo#269510

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089

Forward-Port-Of: odoo/enterprise#120210

Currently, accounts with the `Other Expenses` account type cannot 
be selected in financial budget lines.

**Steps to reproduce:**
- Install the `accountant` module.
- Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`.
- Go to Accounting > Configuration > Financial Budgets.
- Create a new budget and add a budget line.
- Try to select the newly created account.

**Observation:**
Accounts with the `Other Expenses` type are not
available for selection in budget lines.

**Root Cause:**
At [1], the `expense_other` account type is missing from the `account_id` domain.

**Expected Behavior:**
Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting.

**Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709

**Fix:**
This commit ensures that users can add `Other Expenses` accounts to budget lines.

[1]:
https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120

opw-6313835

### Steps to reproduce:
- Download Calendar and Contacts app
- Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies
- Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies
- Create a another user who also have access to both companies
- Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field
- Switch the company of the logged in user to the other company
- Open the test contact form, use the meeting smart button and create a new meeting
- Open the kanban contact view

 **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.**
### Cause of Issue:
When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user.

### Fix:
Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope.
Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance.

opw-5874204

Forward-Port-Of: odoo/odoo#248985

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

## Description of the issue/feature this PR addresses:
Setup plus video
1. Go to settings, enable "Automatic Valuation" and "Storeable Locations".
2. Navigate to Product Categories.
3. Create a new product category with the costing method Standard Price and the inventory valuation Automatic.
4. Navigate to Products, click into any product.
5. Add the new product category to this product under General Information.
6. Add any tax in the purchase tax field.
7. In the Accounting tab of the product, add any account to the Price Difference Account field.

https://drive.google.com/file/d/1i2DHEt0g9G5Edad_QB3QaFkOT49cbMAZ/view?usp=sharing

Instructions to reproduce error
1. Navigate to Purchase.
2. Add a customer, then add the configured product.
3. Add a tax to the line. Ensure that the tax and price_unit are nonzero.
4. Confirm the order.
5. Receive the product.
6. Create the bill.
7. Edit the tax on the vendor bill, then save the changes. Notice that the changes are kept.
8. Select Confirm. Notice that the changes to the tax line are not kept, and that the COGS lines appeared (with taxes applied to them).
9. Reset the bill to draft.
10. Click into the configured product and remove the product category.
11. Repeat steps 7-8 . No COGS lines, and the tax line is the manually set value.

## Current behavior before PR:
COGS lines with taxes have no net effect on any tax lines as they cancel each other out. However, their creation triggers the recalculation of all tax lines, undoing any manual adjustments to tax lines.

## Desired behavior after PR is merged:

This commit ensures that COGS lines are not considered base tax lines, so that their creation does not trigger the recalculation of other base tax lines.

opw-5387248


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

Forward-Port-Of: odoo/odoo#271262
Forward-Port-Of: odoo/odoo#262442

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

Issue:
Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference"

Steps to reproduce on any database with DIAN and Colombian localization:

  1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”.
  2. Find a res.partner with a ref field, or add a ref field to any partner.
  3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it.
  4. Send that invoice to DIAN.
  5. Create a Debit Note for that invoice. Use the journal created in step 1.
  6. Add a product, price, and tax to the debit note. Confirm it.
  7. Send the debit note to DIAN.
  
Explanation:
The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents.

Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output.

opw-6181039

Forward-Port-Of: odoo/enterprise#121458
Forward-Port-Of: odoo/enterprise#121422

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Forward-Port-Of: odoo/enterprise#121779
Forward-Port-Of: odoo/enterprise#112654

**Steps to reproduce:**
- Install Documents app
- Upload a sound file (mp3 for example, but the
    behavior is the same for other formats)
- Share the document and copy the link
- Log out
- Paste the link
- Click on preview button
- Media is working fine on Firefox
- Media won't read on Chrome
```
Loading media from '' violates the following Content Security Policy directive: "default-src 'none'".
Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.
The action has been blocked.
```

**Issue:**
Since [1] default CSP Headers are too strict for Chrome default media rendering, which breaks the file preview (and force user download).

This only impacts Chrome as they seem to render generate `<video><source>` elements to render the file which triggers a secondary request and fails due to the CSP constraint.

**Fix:**
Could re-apply the header fix of 17.4 (see [2]), but it seems better to block the preview of audio files as well by default (to match how we manage videos).

(Note: we don't want to be used as a media streaming platform)

[1] (set csp to none by default) https://github.com/odoo/odoo/commit/64beb80205dffe4b432c8b5813a3271b073fa85e
[2] (similar issue which was not fixed in 18.0+) https://github.com/odoo/enterprise/commit/a7af78eeb2b9763045a5bda8714172f5e7402df8
[3] (mp4 preview removed) https://github.com/odoo/enterprise/commit/ea88cf7c6d5f077b60fb59347659507fded0e2fe

opw-6235043

In POS Restaurant with Germany Fiskaly enabled, splitting and paying from a table works once, but repeating the same flow from the Orders tab lets the parent order show lines that were already paid in previous splits. Functionally, the cashier can keep splitting and paying the same line again and again because the parent draft order is not updated consistently in that path.

Steps to reproduce:
-------------------
* Enable POS Restaurant with l10n_de Fiskaly
* Create a table order (e.g. 3 meals + 3 drinks)
* Open Split Bill, move 1 meal + 1 drink, and pay
* From Orders tab, open the remaining parent order and repeat split + pay
* Reopen the parent order from Orders tab

> Observation:
The parent order still contains quantities that were already split/paid, so the same items can be paid multiple times from the Orders tab.

Why the fix:
------------
The Fiskaly `syncAllOrders` override diverged from core sync behavior in the split flow: it ignored explicit `options.orders` and did not await transaction creation for inactive transactions. In the split-bill path this could skip or desynchronize parent-order updates, leaving stale quantities on the parent order.
The fix restores expected sync semantics by honoring `options.orders` and awaiting transaction creation before deciding sync eligibility.

opw-6175880

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

# How to reproduce
- Install the Website module
- Install another module that has atleast one model with one html field,
sanitize=Flase or sanitize_form=False and groups
- Remove the field's group from the current user
- Enable dev mode
- Go to Settings > Technical > Database Structure > Models
- Pick any model (e.g. sale.order.line)
- Add a field to that model & Save
- Delete the added field & Save

> Note : Significantly harder to reproduce since :
https://github.com/odoo/odoo/commit/9a336bbb94b0a4266d84f7554c024c3abd2d1e7c
I am not sure a field as mentionned in the steps exists

# The problem
An access error is raised for the module wich access rights were
removed, even if the module is not linked in any way with the picked
model

# Cause of the issue
Deleting the field will endup calling the `unlink()` method of
`BaseModel` on the `ir.model.fields` record. This function triggers all
`@api.delete` methods defined on the model :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/odoo/models.py#L4548-L4552

This will call the this method :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/addons/website/models/website_form.py#L153-L154

That was introduced by :
https://github.com/odoo/odoo/commit/c0a827519844ec43537e4487f6abe358bb82ba9a

Which prevents a field from being deleted if it is actively used in any
website form. But this method does a search on every model return by
`_get_html_fields` which may contains models that are not accessible by
the user, so we get an access error.

# Proposed solution
Since `_check_if_used_in_website_form` should perform the same
independently from the user, we can do the search in sudo

opw-6231951

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

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#269456

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654