**AllowanceDate**:
l10n_tw_edi_ecpay has an issue on Credit Notes (Allowances).
When we `_l10n_tw_edi_generate_issue_allowance_json()`, we send the
`l10n_tw_edi_invoice_create_date` which is was set to the associated
invoices creation date, and not the Allowance's creation date.

This creates a potential issue where allowances issued more than 6 days
after the original invoice would bounce back from ECpay with errors.
To be consistent with invoices send to ECPay, we do not send the
`AllowanceDate` parameter at all

Manual Testing/Verification:
1. Create an invoice that has a `l10n_tw_edi_invoice_create_date`,
visible in the Invoice's ECPay tab more than 6 days ago. (Requires
sending to ECPay via the custom wizard via the "Send" button)
2. Create a credit note from the invoice and send to ECPay.
3a. Before this, see that an error would appear.
3b. Now, there would be no error

*InvoiceRemark*:
When Customer Reference `ref` is not set, the code sets the parameter
value as `False`, displaying it's string on the e-invoice and official
printout. We only set the parameter if there exists the `ref` now,
eliminating the issue.

Tests:
1. (both cases) undo the `account_move.py` changes and run the tests.

task-[5455847](https://www.odoo.com/odoo/project/967/tasks/5455847)

---

# New test failed output
<img width="1458" height="353" alt="image" src="https://github.com/user-attachments/assets/77df8e51-5005-4d99-985c-71757c0f62a6" />

```bash
07:47:53,055 ERROR l10n_tw_edi_ecpay-demo-vy2vd3s0 odoo.addons.l10n_tw_edi_ecpay.tests.test_edi: FAIL: L10nTWITestEdi.test_01_can_generate_file
Traceback (most recent call last):
  File "/home/odoo/odev/worktrees/18.0-l10n_tw_edi_ecpay-fix-allowance-date-erle/odoo/addons/l10n_tw_edi_ecpay/tests/test_edi.py", line 61, in test_01_can_generate_file
    self.assertIsInstance(json_data["InvoiceRemark"], str)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: False is not an instance of <class 'str'>
 
07:48:02,516 ERROR l10n_tw_edi_ecpay-demo-vy2vd3s0 odoo.addons.l10n_tw_edi_ecpay.tests.test_edi: FAIL: L10nTWITestEdi.test_13_b2b_refund_upload_deadline_restriction
Traceback (most recent call last):
  File "/home/odoo/odev/virtualenvs/18.0/lib/python3.13/site-packages/freezegun/api.py", line 885, in wrapper
    result = func(*args, **kwargs)
  File "/home/odoo/odev/worktrees/18.0-l10n_tw_edi_ecpay-fix-allowance-date-erle/odoo/addons/l10n_tw_edi_ecpay/tests/test_edi.py", line 430, in test_13_b2b_refund_upload_deadline_restriction
    self.assertNotIn("AllowanceDate", json_data,
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        "B2B Allowances should not include AllowanceDate to avoid >6 day limit errors."
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
AssertionError: 'AllowanceDate' unexpectedly found in {'MerchantID': '1234', 'Details': [{'OriginalInvoiceNumber': 'AB11100099', 'OriginalInvoiceDate': '2025-01-06', 'OriginalSequenceNumber': 0, 'ItemName': 
                                                                                                                                                                                                              'product_a', 'ItemCount': 1.0, 'ItemPrice': 1000.0, 'ItemAmount': 1000.0}], 'TotalAmount': 1000.0, 'TaxAmount': 50.0, 'CustomerEmail': 'partner_b@tsointsoin', 'AllowanceDate': '2025-01-06 15:00:00'} : B2B 
                                                                                                                                                                                                            Allowances should not include AllowanceDate to avoid >6 day limit errors.
```

---

Things to think about:
- FWP
- [ ] 19.0
- [ ] master

Forward-Port-Of: odoo/odoo#241973

## Current behaviour:
When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order.

## Expected behaviour:
If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order.

## Steps to reproduce:
1. Validate a delivery order integrated with Starshipit.
2. Trigger a label generation failure (e.g., bad address).
3. Observe that the created Starshipit order is deleted.

## Cause of the issue:
The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order.

## Fix:
Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual.

## Additional note:
The _() wrapper in the error line was removed because
the Starshipit service has no env or language context.
Since translations cannot be resolved there, Odoo raised a warning.
Removing _() avoids this warning and keeps the error clean.

opw-5306979

Forward-Port-Of: odoo/enterprise#103354
Forward-Port-Of: odoo/enterprise#101174

Currently, the recurring price table displays incorrectly when the user enables the one-time purchase option for a product.

**Steps to produce:**
* Install `website_sale_subscription` with demo data
* Products > Car Leasing > Recurring prices > Enable Accept One-time
* Go to that product's website page

**Observed behavior:**
The pricing table template [1] is appended inside the input radio button instead of replacing the entire pricing table.

**Root cause:**
* Initially, when the `sale_subscription_product_price` template is used, function [2] replaces the table inside `div` [3], which has the `plan_select` class.
* But  When one-time purchase is enabled, the template `subscription_one_time_sale` is used instead of `sale_subscription_product_price`.
* In that template, `div` [4] does not have the `plan_select` class.
* Because of this, the query selector [5] finds the first `plan_select` element inside `input` [6].
* As a result, function [2] renders the table inside that `input` element instead of the intended `div`.

**Solution:**
This commit ensures that:
* One time purchase price is changed dynamically based on variants.
* The pricing table is displayed correctly for both service and
  goods type products.
* The radio button selection works correctly by adding classes to the template
  and modifying its interaction accordingly.

| Before 'Service' type product page | After  'Service' type product page|
|--------|--------|
| <img width="1855" height="928" alt="image" src="https://github.com/user-attachments/assets/d662fbf5-cfce-45c5-b14c-043e982c63a6" /> | <img width="1851" height="933" alt="image" src="https://github.com/user-attachments/assets/8e510b27-6917-43bc-ac5d-b01ff1b187ad" />|

|  Before 'Goods' type product page | After  'Goods' type product page |
|--------|--------|
| <img width="1852" height="931" alt="image" src="https://github.com/user-attachments/assets/b9aa68e7-beef-413c-b99e-a71937e35e10" />| <img width="1851" height="932" alt="image" src="https://github.com/user-attachments/assets/d768edd9-2169-4d43-ac59-9893b55d5bcd" /> | 

[1]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/xml/pricing_view.xml#L21-L63
[2]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/js/variant_mixin.js#L32-L36
[3]:
https://github.com/odoo/enterprise/blob/77423e62d5b74d73cad86bf81fdfee2bea3ef2d1/website_sale_subscription/views/templates.xml#L61
[4]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L130
[5]:
https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/website_sale_subscription/static/src/js/variant_mixin.js#L18-L20
[6]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L138


opw-5380240

Putting in pack from the SML view leads to package incorrectly located

To reproduce the issue:
1. In Settings, enable "Package"
2. Confirm a delivery with 2 available products
3. Open the SML thanks to the smart button
4. Tick a line > Put in pack
5. On the second line, in "Destination Package", look for the package

Error: it is impossible to find it

When opening the SML thanks to the smart button, we also load a lot 
of default values:
https://github.com/odoo/odoo/blob/1492abd8c6bcfdbc48f730f6767b177aeff54bf7/addons/stock/models/stock_picking.py#L1203-L1221
Those are (obviously) SML specific.

However, this context is used when putting in pack. This is a 
problem since `location_id` is also the field name of a package. As 
a result, the ORM defines the location of the new package with the 
default value, i.e. the source location of the SML. This is incorrect.

One consequence of this bug is the step 5 of the above use case. 
When looking for a package, a domain checks its location:
https://github.com/odoo/odoo/blob/35feed47622b279abf8e593d8190ea36b64d32fd/addons/stock/models/stock_move_line.py#L51-L55
It must be either `False` or equal to the dest loc, which is not the 
case with the created package.

Now... About the solution. It's probably difficult to do something 
more hacky. However, it's not too invasive in the code and all user 
will take benefit from it once the commit is deployed. On master, we 
will discuss with both frameworks to negotiate/find something more 
elegant.

OPW-5215243

Forward-Port-Of: odoo/odoo#242328

Scenario:
* create a delivery with quantity 3 and mark as TODO
* mark the stock move as picked
* open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new package or a new lot
* exit the popup and try to validate the delivery

Behavior before this commit:
* the stock move in the delivery form remains picked
* validation shows a backorder popup, warning of missing quantity

Reason: the newly created stock move line is not picked, but this information is not displayed anywhere, so users are not aware of the cause of this issue

After this commit:
* the stock move is no longer picked after a new move line is added
* users can click the "Picked" checkbox in the delivery form manually, which marks all stock move lines as picked as well
* after this action, delivery validation proceeds without backorders

opw-5345579

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

Forward-Port-Of: odoo/odoo#241655
Forward-Port-Of: odoo/odoo#239089

Currently, an error occurs when user tries to open the Tax Return view.

**Steps to Reproduce:**
 - Install the `Accounting` module.
 - Go to `Tax Returns` and set the `Fiscal Year End Day to negative value`, then click `Apply`.

**Error:**
`ValueError: day is out of range for month.`

**Cause:**

 - The field is related to the `company's fiscalyear_last_day` [1].
 - When the user enters a `negative value`, that invalid value is written directly to the `company's fiscal year last day`[2] .
 - When the user opens the `Tax Returns`, it going to compute the `fiscal year dates` [4]. Since the day value is negative, it raises error [5] because the day is out of range for the month.

**Fix:**
- This commit ensures that a validation error is raised when a user enters zero or negative fiscal year date.
- In 18.3, setting the value to 0 falls back to the previously defined company value [2].
- In 19.0, however, the value 0 is incorrectly saved on the company [3], causing an error.
- This fix restores the correct behavior and resolves the issue in 19.0 as well.

[1]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L17-L18

[2]: https://github.com/odoo/odoo/blob/45ca03fcb77febf4f373fe35f0242720e88cb85b/addons/account/wizard/setup_wizards.py#L49

[3]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L54-L56

[4]: https://github.com/odoo/enterprise/blob/99642bdf62f8b1c653dfefdbdcd0e9258cc9e307/account_accountant/models/res_company.py#L174-L175

[5]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/odoo/tools/date_utils.py#L242

sentry-7102968735



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

Forward-Port-Of: odoo/odoo#239814

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#102771
Forward-Port-Of: odoo/enterprise#99096

Steps to reproduce:
====================
- Go to the website in chrome
- Create a Image Wall (gallery)
- Add a lot of images. See attachments for a .zip file in task to test it.
- Try to change the display mode or number of column

-> An error will appear when the cursor get on the dropdown options.

Cause:
======
In Google Chrome, calling img.decode() on a large set of images simultaneously (e.g., in an image wall) can result in `EncodingError: The source image cannot be decoded for some images`. This is a known Chromium issue (See [1]) where the browser's image decoder gets overwhelmed or hits a concurrency limit, causing it to reject valid images.

The current implementation uses Promise.all(imgLoaded), which utilizes a "fail-fast" mechanism. Consequently, if a single image fails to decode due to this browser limitation, the entire promise rejects immediately. This unhandled rejection interrupts the execution flow, preventing the display mode or column options from functioning correctly when the user interacts with them.

Solution:
========
Replace `Promise.all(imgLoaded)` with `Promise.allSettled(imgLoaded)`.

Unlike `Promise.all`, `Promise.allSettled` waits for all promises to finish regardless of whether they succeeded or failed.

[1]: https://issues.chromium.org/issues/40261318

opw-5249130

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

**Steps to reproduce:**
* Install the *purchase_stock* module
* Create new Product category.
* In the category, set the **Costing Method** to *Average (AVCO)*.
* Create a new product and assign a created product category. 
* Create a new Purchase Order.
  * Add a Purchase Order Line with the created product.
  * Set **Quantity** to 10.
  * Set **Unit Price** to 100.
  * Set **Discount** to 10%.
* Confirm the Purchase Order.
* Validate the generated receipt.
* Open the product form and check the *standard_price*(Cost) field.

**Observed behavior:**
The product standard price is updated to **100**, calculated from  the undiscounted unit price (1000 / 10), ignoring the discount applied  on the purchase order line. The expected value is *90* (900/10).

**Cause:**
With the new inventory valuation logic in v19.0, the standard price is updated via *_update_standard_price*, which calls *_run_avco* which uses the stock move *value* field set by *_get_value_from_quotation*:
https://github.com/odoo/odoo/blob/71195624008f8c1ba8b10e1b04433e34e08fb540/addons/stock_account/models/product.py#L340
However, the *_get_value_from_quotation* relies on *_get_stock_move_price_unit*, which returns the unit price **without considering the discount**, leading to an incorrect move value for AVCO computation.

**Note:** 
Prior to 19.0, the `price_unit` of the move was calculated in the `_get_price` unit using the `_get_gross_price_unit` using the discounted value of the line:
https://github.com/odoo/odoo/blob/24db73743d8bb4d678af7efb4d78a019e0953395/addons/purchase_stock/models/stock_move.py#L152-L154
https://github.com/odoo/odoo/blob/24db73743d8bb4d678af7efb4d78a019e0953395/addons/purchase/models/purchase_order_line.py#L383-L387
It should still be the case here as there is no discounted_unit_price on the move and, since we do not rely on the `_get_gross_price_unit` anymore, we should adapt the relative call:
https://github.com/odoo/odoo/blob/090c5a4d55e3fcd1b2840bc8afaed49efc8745d4/addons/purchase_stock/models/stock_move.py#L214-L218
https://github.com/odoo/odoo/blob/090c5a4d55e3fcd1b2840bc8afaed49efc8745d4/addons/purchase_stock/models/purchase_order_line.py#L238-L243


---
opw-5409226

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

Commit 04155a0 correctly increased the threshold for the VP7 line
of the monthly tax report from 25.82€ to 100.00€. However, a
subsequent commit (https://github.com/odoo/odoo/commit/51a72ab42d118d6fb0eb3e3545a09e10019b9140) accidentally reverted this change to
the outdated value.

This commit restores the threshold to the expected value of 100.00€.

---

The previous fix in https://github.com/odoo/odoo/commit/4e831999ed06e0e3c2f380414c5949db645f2f19 attempted to correct VP6 (VAT due/deductible)
but relied on an incorrect assumption regarding debit signs.

In the Italian tax report, values should remain positive regardless of
whether they are debits or credits. Displaying debits as negative caused:
1. Incorrect visual representation in the report columns.
2. Inconsistent totals for VP14 (VAT payable).

This commit ensures all debit column values are displayed as positive
and restores the correct calculation logic for the report totals.

opw-5357719
opw-5411706
opw-5421779

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

**Problem:**
When ordering a combo product, you can order more products than the
combo requires, which will the add *base_price* to the combo price.
The problem is that when changing the preset, like going from eat in
to delivery, the pricelist is reconfigured, and it does not take the
extra products from the combo into account. This means that the price
will go back to the combo's price without the extra products.

**Steps to reproduce:**
- Have a combo that can take on multiple free products and has a limit above this free product number
- Order more than the free quantity
- Change the preset (from eat in to delivery)
- The price is recomputed without taking the extra products into account

**Why the fix:**
The extra articles were not accounted for when changing the pricelist,
meaning they would end up free and the price would change. We now
make a separation between the free products (that are from the combo) and
the extra products. The extra products cost the *base_price* of said combo.

To do that, we need to get the extra lines from the combo, which are the
products that are not free in the case where there are more products
selected in the combo than free products defined in the definition of
the combo. To make that happen, we add the non free lines to the
extra lines list once we have at least as many free products as
defined in the combo definition.

In the case where the quantity of a product is greater than the number
of free items, the lines are automatically split. Meaning if we have
a combo with 2 free items but we order 3, we will have a line with
a quantity of 2 and another line with a quantity of 1. In that case,
the first line will be free, but the second line will be an extra.
This logic is implemented here https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/components/popups/combo_configurator_popup/combo_configurator_popup.js#L88-L106
Which is then retrieved here to make the separation in the combo's price
https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/services/pos_store.js#L879

opw-4885574

Forward-Port-Of: odoo/odoo#217082