**Steps to reproduce:**
* Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*.
* Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.).
* Save the settings.
* Create a *customer invoice*.
* Post the invoice.
* Send the invoice through *E-Invoicing (EDI)*.
* Open the generated *Invoice PDF* and the *form view*.

**Observed behavior:**
* The *IRN number* is correctly present in the *Invoice PDF*.
* However, it is *not saved/displayed* in the invoice form view.

**Cause:**
* The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available.

**Fix:**
* Inherit *_l10n_in_edi_send_invoice*.
* Add a condition after the invoice is sent and the JSON response is received.
* When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case).

opw-6097923

Forward-Port-Of: odoo/enterprise#115522
Forward-Port-Of: odoo/enterprise#114350

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#259083
Forward-Port-Of: odoo/odoo#257873

[FIX] project_timesheet_holidays: Exclude archived employees from time-off 

# Description of the issue/feature this PR addresses:
## Steps to Reproduce:
1. Create a time off for Employee A (it should affect the timesheets).
2. Create a new public holiday (global time off) that overlaps with Employee A’s time off.
3. Archive Employee A.
4. Delete the public holiday created in step 2.
5. An error related to timesheet generation appears.

## Expected Behavior:
- The public holiday / global time off should be deleted without any error.

# Desired behavior after PR is merged:
## Fix (Implemented):
When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees.

## Alternative Fix (Not Implemented):
Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved.

 ## Version:
 This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0  but didn't directly test

## Task:

[5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038)

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

Forward-Port-Of: odoo/odoo#261909
Forward-Port-Of: odoo/odoo#244203

When we add a byproduct followed by SN directly in the MO it will not have the its location as production.

Steps to reproduce:
-------------------
* Create product tracked by Serial number
* Create a Manufacturing order
* Add the Product tracked by serial number on the MO as byproduct
* Confirm the MO
* Go to shop floor
* Add the by-product quantity and create a new serial number.
* Close production and go back to the MO in manufacturing
* Open stock moves -> the by-product does not have "production" for origin

Observation:
-------------
When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM.

When adding the byproduct in shopfloor, it will create the quant:
https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171
Additionaly when creating the quant it will decide the source location depending if the product its a byproduct:
https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192
The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids
https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110

#### Additional notes:

The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false


opw-5974582

Forward-Port-Of: odoo/enterprise#110122

Issue:
---
Ewallet line is included in delivery pricing.

Steps to reproduce:
1- Create a delivery method `based on rules`.
2- In pricing set rules:
- price <= 99 => delivery price = 30
- price > 99 => delivery price = 50

3- Create a eWallet with balance = 200.
4- Create a SO add a line with product. Set the SOL unit amount to 100.
5- Click on `add a shipping`. Add the created delivery method.
6- As you see, the delivery amount is correctly calculated.
7- Now apply the eWallet using `reward` button.
8. Update the shipping cost.

The shipping cost is 30, which is not expected.

Cause:
---
In calculation of shipping amount the ewallet is not taken into account. Even though technically it's considered a discount, ewallet is not functionally the same as discount.
However, in `_get_price_available` we cannot have information about `ewallet` lines as it doesn't depend on `sale_loyalty`.

Fix:
---
We use `_compute_amount_total_without_delivery` which is overridden in `sale_loyalty_delivery` to exclude ewallet and gift cards.

opw-6124209

Forward-Port-Of: odoo/odoo#260134

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

Forward-Port-Of: odoo/enterprise#108493
Forward-Port-Of: odoo/enterprise#103333

## Problem:
During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests.

## Solution:
Enforce the `limit` when fetching if it is present.

## Steps to reproduce:
- Have a product with many quant records
1. Open a picking for this product in Barcode
2. Change the lot/serial

The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve.

## Benchmark:
<table>
	<thead>
		<tr>
			<th># of quants</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>17193</td>
			<td>~9s</td>
			<td>~400ms</td>
		</tr>
	</tbody>
</table>

opw-6041705

Forward-Port-Of: odoo/odoo#261904
Forward-Port-Of: odoo/odoo#259983

Steps to reproduce:
===================
1. Open the To-do app and pick any task.
2. In the description add text and an icon with a bg color.
`(you can add this: <i class="fa rounded rounded-circle fa-user
bg-o-color-1 fa-4x" contenteditable="false">​</i>)`
3. Select all and click "Remove format".

Result:
-> Traceback due to an infinite loop.

Cause:
======
Remove format calls `removeAllColor()`, which loops forever at:
https://github.com/odoo/odoo/blob/626bde21a25366d0bb29662bae2057c247a1638e/addons/html_editor/static/src/main/font/color_plugin.js#L194-L194

Why:
_applyColor doesn't remove the icon's background class, so
hasAnySelectedNodeColor keeps returning true and the removal loop
never terminates.
This happens because `font` is already the `<i>` element with the `fa`
class, using `querySelectorAll` on it won't include the element itself,
so the icon is never checked or updated.
https://github.com/odoo/odoo/blob/6cdc6f55886ea48e90f9023a6c6142bf072745b9/addons/html_editor/static/src/main/font/color_plugin.js#L290

Solution:
=========
Check if the font itself has the fa class before doing the
`querySelectorAll`, and include it in the nodes to check for color.

Test Impact:
============
Before this fix, a `<span>` containing an icon was wrapped in a `<font>`
when applying color, treating the icon as a normal span (without size)
instead of applying the color directly.
https://github.com/odoo/odoo/blob/8792c2d38eb0aadac8d778d83fd76f270404ecd5/addons/html_editor/static/src/main/font/color_plugin.js#L397

opw-5928627

Forward-Port-Of: odoo/odoo#261405
Forward-Port-Of: odoo/odoo#248449

1. The `MPESA` payment method needs a callback url where it does a
   `POST` request with the transaction details. Since the call comes
   from safaricom, CSRF will block those requests. This commit will
   disable CSRF checks on the callback endpoints which are expected to
   be called from an external service
2. Sometimes the `web.base.url` parameter is automatically set to http.
   But safaricom expects https for all the urls. So we need to ensure
   that the urls we send on `lipa_na_mpesa_register_urls` use https,
   otherwise the registration fails with an `invalid url` error.
   Additionally, I added the error message in case of error
4. In addition to the business short code we also need a till number for
   transactions. Since this is stable, I've added the till number as an
   extension of the business shortcode field and then parse it before
   usage. On master there is a new PR which will properly separate the
   fields

Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833)

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

Forward-Port-Of: odoo/odoo#254993

When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually.

This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks.

Steps to reproduce:
1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user
2. As a user without that approval right, post a vendor bill and register a payment
3. Add the payment to a batch payment
4. Reconcile a bank statement line with the batch payment
5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line)
   - Expected: the bill stays Posted.
   - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook.

opw-6121448

Forward-Port-Of: odoo/enterprise#115341
Forward-Port-Of: odoo/enterprise#115241

### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.

### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?

### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67

### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.

opw-6050537

Forward-Port-Of: odoo/odoo#260145

When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body directly to the composer.

This caused two issues:
- CTRL+A would select the `(edited)` label, allowing it to be styled, repositioned, or accidentally deleted.
- CTRL+A + Backspace + retype left the body empty after saving, because the self-closing `<span class="o-mail-Message-edited"/>` in the stored HTML was parsed by browsers as an open tag (spans are not void elements), swallowing subsequent content as its children.

Fix: strip `.o-mail-Message-edited` from the body before loading it into the editor. The server always re-appends a fresh `(edited)` span at the end when saving, so removing it from the editor content is safe and correct.

Also align the mock server with the real server behavior:
- Place the span *inside* the last `div`/`p` element instead of after it.

Rename `getNonEditableMentions` → `prepareBodyForEditing` to reflect that the function now covers both making mentions non-editable and stripping the edited label.

task-6172161



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

## Problem:
During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests.

## Solution:
Enforce the `limit` when fetching if it is present.

## Steps to reproduce:
- Have a product with many quant records
1. Open a picking for this product in Barcode
2. Change the lot/serial

The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve.

## Benchmark:
<table>
	<thead>
		<tr>
			<th># of quants</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>17193</td>
			<td>~9s</td>
			<td>~400ms</td>
		</tr>
	</tbody>
</table>

opw-6041705

Forward-Port-Of: odoo/odoo#261904
Forward-Port-Of: odoo/odoo#259983

1. The `MPESA` payment method needs a callback url where it does a
   `POST` request with the transaction details. Since the call comes
   from safaricom, CSRF will block those requests. This commit will
   disable CSRF checks on the callback endpoints which are expected to
   be called from an external service
2. Sometimes the `web.base.url` parameter is automatically set to http.
   But safaricom expects https for all the urls. So we need to ensure
   that the urls we send on `lipa_na_mpesa_register_urls` use https,
   otherwise the registration fails with an `invalid url` error.
   Additionally, I added the error message in case of error
4. In addition to the business short code we also need a till number for
   transactions. Since this is stable, I've added the till number as an
   extension of the business shortcode field and then parse it before
   usage. On master there is a new PR which will properly separate the
   fields

Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833)

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

Forward-Port-Of: odoo/odoo#254993

Description of the issue:

Importing an FEC on saas-19.1 can crash for French association companies in
Guadeloupe or Martinique. During the import, account data is completed from the
fr_comp account templates. Since 19.1, those templates may include
asset_model_ids, which makes the import try to resolve asset XML IDs that do
not exist for that company setup.

Steps to reproduce:

1. Create a new company with Guadeloupe or Martinique for country.
2. Set the French associations chart of accounts on it.
3. Go to Accounting -> Configuration -> Chart of Accounts.
4. Import the FEC file linked on the ticket.
5. Import fails with traceback.

Desired behavior after fix:

FEC import should keep the existing template completion behavior, but it should
not copy asset_model_ids onto imported accounts. Importing an FEC for French
association companies in Guadeloupe or Martinique should therefore no longer
crash because of unrelated asset model references.

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

**Issue:**
Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error:
```
The operation cannot be completed: update or delete on table "account_account" violates RESTRICT setting of foreign key constraint "account_cash_rounding_profit_account_id_fkey" on table "account_cash_rounding"
DETAIL:  Key (id)=(1919) is referenced from table "account_cash_rounding"
```

**Steps to reproduce:**
1) install l10n_be module
2) make a new belgium company
3) go to accounting > configurations
4) change the fiscal localization package to "Belgium- Associations and Foundations"

**Cause:**
`account.cash.rounding` was not included in the chart template cleanup models. As a result, old `account.account` records were unlinked while still referenced by cash rounding records with `ondelete='restrict'`

**Solution:**
Include `account.cash.rounding` in `TEMPLATE_MODELS` so cleanup removes cash rounding records before deleting old accounts. And Add an assertion in `test_change_coa` to ensure old cash rounding records are deleted during COA switch.

opw-6165374

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

**Steps to reproduce**
- Settings: Timesheets > Invoicing policy = only validated TS.
- Have a service product with an invoicing policy based on timesheets.
- Create a sales order using this product.
- From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them.
- Invoice the SO, using a timesheets period that includes both TS.
- Notice that the quantity of the invoice line includes the non-validated timesheet.

**Cause**
The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1

**Change**
Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain.

opw-6116670

Forward-Port-Of: odoo/odoo#261621
Forward-Port-Of: odoo/odoo#259224

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Forward-Port-Of: odoo/enterprise#115534
Forward-Port-Of: odoo/enterprise#114429

Steps to reproduce:
- Set a journal with documents folder sync.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
Adding an image via log note sets it as the main attachment, but it 
is intentionally orphaned (res_model=False) to prevent UI clutter. 
`documents_account` incorrectly syncs this unlinked file, creating a 
workspace document with a missing model.

During "Send & Print", the official invoice PDF replaces the image as
the main attachment. The document versioning logic intercepts this swap
and attempts to re-parent the new PDF to match the orphaned document.
This destroys the PDF's linkage to the invoice, causing a crash when
the system later attempts to fetch the PDF.

Solution:
Since the base module now suppresses premature document creation during 
the message post, we explicitly handle the sync ourselves. We override 
`_fix_attachments_on_record_from_files_data` to iterate over the 
validated attachments and trigger document creation only for files 
that retained their `res_model`. We also add a check inside 
`_update_or_create_document` to strictly block orphaned attachments.

opw-5930888

When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots.

Steps to reproduce:
-------------------
* Create a product with Tracking by lots
* In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)"
* Create a quotation with the product and confirm it
* Validate the delivery
* In POS, settle the sale order from Quotation/Order
* When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes

> Observation:
Quantity doubled.

Why the fix:
------------
read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice.
We now use move lines from exactly one picking and filter by sale_line_id.

opw-6001585

Forward-Port-Of: odoo/odoo#261729
Forward-Port-Of: odoo/odoo#253539

Before this commit, calling the method `_prepare_graph_data` with a recordset of workcenters,
would traverse the recordset and then check if all the workcenters has at least one workorder by
fetching the field `order_ids` for all the workcenters. This can be too slow in cases where the
workcenters have a lot of workorders and in addition to that there is no need to do this repeatedly for
every workcenter.

In this commit, I have modified the check by invoking a `search_count` on the workorders before iterating
over the recordset and in addition to that I have pre-computed the sum of the duration hours of the attendances
related to a `resource_calendar` as multiple workcenters might have the same `resource_calendar`

The benchmark done below, was on a database that contained 78 workcenters.

| Workorders | Before | After |
| :--- | :--- | :--- |
| 1380828 | 12s | 0.16s |
| 138082 | 1.21s | 0.14s |
| 13808 | 0.21s | 0.09s |

opw-6040077

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

Forward-Port-Of: odoo/odoo#256812

Since 605c8b47d52854e36c7cb822ccb2d40de44c4c3c, rourly rental products default to a rental period starting at the next hour of the current day.

Tours override the time of the rental period, but not the date. If the tours tries to set a time which is in the past, the datepicker will discard the time, breaking the tour.

Scenario: Running the tour between 11am-11:59am breaks test_website_sale_renting_ui:
- Product page shows default times: today 12pm (start) to 1pm (end)
- Tour tries to set start time to 8am
- Datepicker rejects 8am (it's before the current time 11am-11:59am) and keeps 12pm
- Tour then sets end time to 12pm, resulting in equal start and end times
- Equal times are invalid, cart addition fails, tour breaks

This commit, extracts the existing utility function into a shared helper that returns a guaranteed future date (next Monday + offset), ensuring tours always set valid times regardless of when they run.

runbot-243459

Forward-Port-Of: odoo/enterprise#115687

**Steps to reproduce:**
* Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*.
* Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.).
* Save the settings.
* Create a *customer invoice*.
* Post the invoice.
* Send the invoice through *E-Invoicing (EDI)*.
* Open the generated *Invoice PDF* and the *form view*.

**Observed behavior:**
* The *IRN number* is correctly present in the *Invoice PDF*.
* However, it is *not saved/displayed* in the invoice form view.

**Cause:**
* The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available.

**Fix:**
* Inherit *_l10n_in_edi_send_invoice*.
* Add a condition after the invoice is sent and the JSON response is received.
* When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case).

opw-6097923

Forward-Port-Of: odoo/enterprise#115522
Forward-Port-Of: odoo/enterprise#114350

When we add a byproduct followed by SN directly in the MO it will not have the its location as production.

Steps to reproduce:
-------------------
* Create product tracked by Serial number
* Create a Manufacturing order
* Add the Product tracked by serial number on the MO as byproduct
* Confirm the MO
* Go to shop floor
* Add the by-product quantity and create a new serial number.
* Close production and go back to the MO in manufacturing
* Open stock moves -> the by-product does not have "production" for origin

Observation:
-------------
When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM.

When adding the byproduct in shopfloor, it will create the quant:
https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171
Additionaly when creating the quant it will decide the source location depending if the product its a byproduct:
https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192
The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids
https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110

#### Additional notes:

The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false


opw-5974582

Forward-Port-Of: odoo/enterprise#115548
Forward-Port-Of: odoo/enterprise#110122

When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag.
The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.
This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices.

Two issues:
- We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`.
- When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678`

ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf

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

When creating an internal transfer from the Barcode app, stock moves auto-created from scanned lines showed incorrect data in the Moves Analysis list view:
- Demand (product_uom_qty) was always 0.
- Source and destination locations showed the picking's generic header location (e.g. WH/Stock → WH/Stock) instead of the actual sub-locations scanned by the operator.

Steps to reproduce:
-------------------
* Open the Barcode app and start a new internal transfer.
* Add a product from WH/Stock/Shelf to WH/Stock/Shelf2 with qty 8.
* Validate the transfer.
* Open Inventory > Reporting > Moves Analysis > List View.

> Observation:
the move shows Demand = 0, From = WH/Stock, To = WH/Stock.

Why the fix:
------------
When barcode saves a transfer it writes move_line_ids directly on the picking without pre-existing moves. stock.move.line.create() calls _prepare_stock_move_vals() to auto-create the backing move. Core stock intentionally sets product_uom_qty = 0 for open pickings (so that backorder/procurement logic is not affected), and reads source/dest locations from the picking header rather than from the individual line.

For the barcode "scan-first" flow these two defaults are wrong:
- The scanned quantity IS the demand; there is no separate planning step.
- Sub-location scanning stores the real locations on the line, not on the picking header.

_prepare_stock_move_vals is overridden in stock_barcode to set product_uom_qty = self.quantity and propagate the line's locations to the move.

For kit (phantom BOM) products, action_explode() deliberately relies on product_uom_qty == 0 as a signal to derive the BOM factor from the actual total scanned quantity (move.quantity) rather than from the first-scan demand, which would be captured too early. A second override in stock_barcode_mrp reverts product_uom_qty back to 0 for kit products only, while keeping the location fix.

opw-6150750

# Setup
Have 2 companies : A & B

# How to reproduce
- Set your website's company to Company B
- Create product X :
	- Company : Company A
	- Published
	- Name : xyz
- Go to Users > Any User > Acces Rights > Allowed Companies => leave only Company A
- Connect as that user on the website
- Go to the Shop tab and search xyz

# The problem
The product X is displayed, even though we currently use the company B's website and the product is limited to company A. 
This causes problem later when Sales Order are created using that product.

If you set the Allowed Companies of the user to both Company A and Company B, then the product is correctly hidden

# Why
When you search something in the search bar, the server does a `_search_with_fuzzy()` that ends up calling a simple `model.search()`.
In our case, this search should not return product X because there is an `ir.rule` that hides product not in the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/product/security/product_security.xml#L34-L38

But the `website` module has some particular rule about setting the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/website/models/ir_http.py#L249-L261

So, in our case, since the user does not have company B in its allowed companies, then
`allowed_company_ids` = Company A. So `('company_id', 'parent_of', company_ids)` is trucy and the product is displayed

# Proposed solution
Doing the search with `with_company` raise an AccessError because the company is not present in the allowed_companies. Chaging the allowed companies logic seems risky because it
may lead to unintended side effects.

We instead enforce the website's company in the search's domain

opw-6115647

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

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

Forward-Port-Of: odoo/odoo#257342

**Steps to reproduce:**
- create a storable product avco auto 
- make sure that a purchase tax is set in 'General Information'
- create and confirm a PO for 30 quantities with a price of 0
- receive the products
- create and validate a delivery for 10 units of the product
- from the PO create the bill 
- set a date and save
- set a price of 100
- on the Bill set the total tax at 500 (it's bellow 'untaxed amount' 
on the bottom right of the bill and should be 450 before you 
change it, if the tax is 15%)
- confirm the bill

**Current behavior:**
The total tax was reset to 450

**Expected behavior:**
It should stay 500 as it was manually set

**Cause of the issue:**
The total tax amount is computed based on the tax lines 
in Journal Items
https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171
So the problem is actually that a recomputation of the balance
of the tax account.move.line (the one with the account "tax paid" in 
journal items) is triggered when we confirm the Bill.

That's because :
When we confirm the bill, because the price is different than 
the one on the PO, _apply_price_difference does 2 things : 
(1) it creates an svl (with corresponding amls) for the quantities
that are still in stock (here 20)
(2) it adds amls on the bill (crediting stock interim received and 
debiting expense) to compensate the cogs deficit for the already 
out of stock quantities (here 10).
cf https://github.com/odoo/odoo/pull/126536 for more details

When we create those amls from (2),  the create method 
from account.move.lines calls super() inside a context manager 
calling _sync_dynamic_lines().
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635
the yield of sync_dynamic_lines() is inside a context manager
calling _sync_tax_lines.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250
Therefore, the first half of sync_tax_lines() (untill the yield) is ran 
before the call to super and the rest (from the yield) is ran 
after the call to super. 
Because we added two lines in the account.move, get_changed_lines
will return those 2 new line and because there is a tax_ids on the new lines
round_from_tax will be False.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041
Therefore we won't reach continue.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059
And the tax line will be recomputed using 
_prepare_tax_line()
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065

Here is why there is a tax_ids on the new lines : 
The field is precompute so if we don't set a value for 
it, _compute_tax_ids will be ran to compute it.
As the account move on which the lines are added 
is a bill, the tax_ids will the supplier_tax_id of the product.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901

**Fix:**
There is no need for a tax_ids on these lines as they 
are not meant to (and should'nt) impact the taxes.

opw-5413798

After the fix, when selecting multiple refunds not belonging to
a same order, a user error will appear, preventing an odoo
error later in the flow.
_____________________________________________________
## Short functional explanation of the error
Selecting several refunds from the same customer in the same transaction, and making sure to print an invoice at every operation caused an error.

## Reproduction Steps
1. Go to the point of sales module, and create an order for a specific customer. Proceed to the payment and make sure that finalizing the payment will create an invoice, before confirming the payment. 
2. Create a second order for the same customer, and proceed the same way as in step 1.
3. On the product screen, click on "refund".
4. Select one order that you've just completed. Then, setup the quantity at 1 and click on refund. 
5. Do step 4 again but this time, select the second order that you've just completed.
6. Click on payment, then click on invoice then try to validate the payment.

The error occurs:
Expected singleton: account.move(720, 722)
Traceback (most recent call last):
  File "/data/build/odoo/odoo/models.py", line 5896, in ensure_one
    _id, = self._ids
ValueError: too many values to unpack (expected 1)

## Causes of the problem
It is due to an ensure_one() in python. Indeed, in the file point_of_sale/models/pos_order.py,in the function _prepare_invoice_vals(self), an error occured on the line:

vals['ref'] = _('Reversal of: %s', self.refunded_order_ids.account_move.name)

self.refunded_order_ids.account_move.name is supposed to be a singleton, but in the case where a transaction has several refund order, this isn't the case anymore, causing the error.

 ## Explanation of the fix

After the fix, when you select a second refund after selecting one, the previous one will be replaced by the current one, preventing users to select 2 refunds in the same transaction. In the code, this is translated as: 
in the point_of_sale/static/src/app/screens/ticket_screen.js file, in the onDoRefund() function, when a refund (= orderline) is created, we check that there are less than 2. If not, we remove the previous ones.



______________________________________________________________
opw-4791231

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

**Problem:**
Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled.

**Steps to reproduce:**
1. Create a Sales Order, do not confirm
2. Change the customer → no log in chatter
3. Confirm the SO, then cancel it
4. Set it back to Quotation → no log in chatter

**Current behavior:**
No chatter entry is created for either change.

**Expected behavior:**
Both changes should appear in the chatter since `partner_id` (tracking=1) and `state` (tracking=3) have tracking enabled.

**Cause of the issue:**
`_track_finalize` discards ALL tracking data whenever the SO is in `draft` state. This was originally intended to avoid noise from catalog product additions, but it also suppresses legitimate field changes like customer updates and state transitions back to draft.

**Fix:**
Instead of blanket-suppressing all tracking on draft SOs, only discard tracking when the change originates from the product catalog (`_update_order_line_info`), which sets a `catalog_skip_tracking` context flag. This preserves the original noise-reduction intent while allowing real user-initiated field changes to be tracked.

Backport of: 311bf3426fb241cd5036db58c6c317fe0e81ab87

opw-6106537

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization.

This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold.

When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The
`sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel.

This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization.

opw-6064896
opw-5152359