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

*mrp_account, sale_mrp{,_margin}, point_of_sale

## Issue 1: Kit sale price
 
### Steps to reproduce:

- Install sale_margin, sale_management, mrp
- Create a kit product with an avco product category:
    - 1 x COMP1, cost 10
    - 1 x COMP2, cost 20
- On the kit product update the cost accroding to the bom
- Create an SO for 1 unit of your kit
- Validate the associated receipt
#### > The cost (purchase_price) of the sol of the kit has been reset from 30 to 0.

### Cause of the issue:

Validating the receipt will trigger the dependence of the `purchase_price` compute method since the moves are now done: https://github.com/odoo/odoo/blob/18dc738c710f87d1f937b0d1fbb619c75f5ad952/addons/sale_margin/models/sale_order_line.py#L15-L18 However, the `_get_price_unit` will `return 0` since `sol` is linked to both component moves:
https://github.com/odoo/odoo/blob/18dc738c710f87d1f937b0d1fbb619c75f5ad952/addons/sale_stock_margin/models/sale_order_line.py#L10-L20

### Issue 2: POS with multiple products
Currently, when a pos order contains more than 1 product, inventory valuation lines are not generated when invoicing the order.

Steps to reproduce:
-------------------
* Using anglo-saxon accounting
* In the settings search for inventory valuation
  * Set inventory valuation to Perpetual
  * Choose standard cost method
  * Set up valuation account and journal
* Create two different products
  * Type -> Goods
  * Track inventory by quantity
  * Set a purchase cost
  * Put some quantity on hand
  * Add category
* In the settings of the category
  * Set up Stock account
  * Set up costing methog, standard
  * Set inventory valuation to perpetual
* Open pos session
* Make 3 orders, invoice them
  * Order 1, only product 1
  * Order 2, only product 2
  * Order 3, both products
> Observation: The invoces for orders 1 & 2 have entries regarding
inventory valuation while the invoice for order 3 does not have any.

### Cause of the issue:

Stock valuation entries are not created for order 3 because the price unit computed is 0.
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/account_move.py#L122-L126

The reason why the price unit is 0 is because in `_get_pos_anglo_saxon_price_unit` we have multiple records in `moves` related to multiple products.
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/point_of_sale/models/pos_order.py#L276-L281

`_get_price_unit` was not designed to treat moves with different products https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228

This leads to think we should filter moves in `_get_pos_anglo_saxon_price_unit` regarding the product.

The end result is now the same as when we make a SO with the two products in the Sales app and invoice it. This results in 2 valorisation lines (1 per product) but this does not change the valorisation when the pos order is not invoice and we close the session (still 1 valorisation line).

### Fix:

The filter on the product_id in the `_get_pos_anglo_saxon_price_unit` has been removed in https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229
Prior to that change the price unit were computed on moves sharing a common product:
https://github.com/odoo/odoo/blob/9cb6476e0f8d319dce4baf65904b8bd5d535c83c/addons/point_of_sale/models/pos_order.py#L271-L275
https://github.com/odoo/odoo/blob/9cb6476e0f8d319dce4baf65904b8bd5d535c83c/addons/stock_account/models/stock_move.py#L28-L29
We reintroduce this filter as it should not have been removed.


#### Issue 1: opw-5420977
#### Issue 2: opw-5328152

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

Forward-Port-Of: odoo/odoo#242052

## 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

## Versions
17.0+

## Issue
Customers located in French territories (e.g. La Réunion) can't use Stripe Connect.

## Steps to reproduce
*Ensure Stripe payment provider is installed*
- From the Settings' app, access your company's data:
  - Change your company's country for "Réunion".
- Go to Payment Providers and open Stripe:
  - Try to enable Stripe via Stripe Connect;
  - A message tells you your country is not supported by Stripe.

## Cause
Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries).
This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow.

opw-5421185

Forward-Port-Of: odoo/odoo#242319
Forward-Port-Of: odoo/odoo#241269

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

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Avoid payment wrong initialization when a default value has been set to initialize the `account.payment.register`. Indeed, the `account.payment` also has a `partner_bank_id` property, and so the method `_create_payment`of the `account.payment.register` can initialize payment with wrong `partner_bank_id`.

[enterprise#99373](https://github.com/odoo/enterprise/pull/99373)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/odoo#242004
Forward-Port-Of: odoo/odoo#235475

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`.

Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. 

## Tests
Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment).

Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error.

This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment.

[community#235475](https://github.com/odoo/odoo/pull/235475)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/enterprise#103220
Forward-Port-Of: odoo/enterprise#99373

Before this commit when a combo product was added to the the order, if a note was added and then the product was ordered. And after we change the quantity of this product and the note, the combo children lines were not updated correctly.

After this commit, the combo children lines quantities are correctly updated when the parent line quantity is changed.

Step to reproduce :

1. Add a combo item to the order line in Point of Sale (Restaurant).
2. Add a Note to the main order line and place the order(Send to Kitchen).
3. Now increase the quantity of the main order line and update the note as well.
4. A popup appears to select the combo again make your selection. You'll notice that a new order line is added.
5. However, in the previous order line, the main product quantity is reverted back to the original quantity, but the combo item order line quantity is not reverted, resulting in an inconsistency.

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

Forward-Port-Of: odoo/odoo#232069

*: html_editor

Issue:
1. Button previews displayed incorrectly after converting button type to link
2. Link preview displayed incorrect theme colors when parent and ancestor elements had different themes applied


Steps to reproduce (Issue 1):
1. Add a button component
2. Set it to primary and modify its size/shape
3. Convert the button type to link
4. Re-open the button type dropdown
5. Observe incorrect button preview

Steps to reproduce (Issue 2):
1. Add the `s_text_cover` snippet
2. Apply theme 1 (o_cc1) to Text Cover and theme 2 (o_cc2) to Column
3. Press Enter after the button
4. Start typing `/link` to create a link
5. Observe that the link preview in the powerbox dropdown shows incorrect theme colors

After this commit:
1. Preview now correctly calculates based on previously configured button properties, even after type conversion
2. Link preview now correctly inherits theme styles from its direct parent element



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

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

This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set.

Steps to Reproduce :
	First Change to either the default company (MyCompany) or Demo Belgian company
	Payroll -> Employee -> Salary Calculator -> choose an employee.

Bug : All fields in the Salary Calculator view are empty (evaluated as False).

Root Cause :

Inside _compute_salary, the method _generate_salary_simulation_payslip writes on payslip.version_id using:

payslip.version_id.write(new_payslip_vals)

Because the is_simulation_offer key was missing from the context, this write triggered a full payslip computation, generating payslip lines. During this computation, compute_sheet() performs an unlink() on existing payslip lines. Since the Salary Calculator view fields are only cached at that point, the unlink causes the cached values to be lost, resulting in all fields being evaluated as False.

Fix : Ensure that is_simulation_offer is present in the context when writing to payslip.version_id, preventing payslip line generation and avoiding the unintended unlink() during salary simulation.

This PR references this one odoo/enterprise#102371

Task - 5387155

### Description of the issue/feature this PR addresses:

The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed.

If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly.

But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files.
The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment.

I've tested it with double the amount of bytes and it seems to work correctly.

Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details.

### Current behavior before PR:
<img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" />


### Desired behavior after PR is merged:
The uploaded file's mimetype is correctly identified for big (>40mb) open office files.


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

Forward-Port-Of: odoo/odoo#242281
Forward-Port-Of: odoo/odoo#233266

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#241790
Forward-Port-Of: odoo/odoo#239089

Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function called from that controller endpoint would take the exception message, and ask the AI to explain the error to the user without the use of technical terms.

The problem with this approach is two-fold.
Firstly, in the `post_error_message` method, we use the `generate_response` method in order for the AI to beauty-fy the error message. But, the `post_error_message` method is called when catching exceptions of the `generate_response` method. Thus, the exception is caught, a nice message is posted in the chat, but then a traceback is shown regardless.
Secondly, beautifying the error messages makes it more difficult for end users to understand what could be going wrong and making it also more difficult for our support to help them out.

In this commit, we removed the `post_error_message` flow. We move the try-except to the `_generate_response_for_channel` method and if the user is an internal user we let the exception bubble up. If not (for website users on livechat), a generic message will be posted on the chat.

task-5177169

Forward-Port-Of: odoo/enterprise#97516