*: sale_stock

Issue:
======================
The forecast availability(icon) on the sales order incorrectly appears
red even when enough stock is available for products in multi-step deliveries.

Steps to Reproduce:
======================
1. install sale_management & stock module.
2. Activate multi-step delivery in the warehouse.
3. Sell a product that has sufficient stock.
4. Ensure that enough quantities are reserved on the created picking.
5. Check the forecast availability(icon) on the sale order.

Issue:
======================
The 'is_consuming' method is not considered for internal transfer moves
during forecast availability computation. This leads to incorrectly flagging
the forecast icon as red on the Sales Order, even when sufficient stock is
available and reserved.

With this commit:
======================
This fix ensures that the forecast icon correctly reflects stock availability
by considering internal transfers in a multi-step delivery. the icon
currently appears green on the Sales Order when there is enough
stock to fulfill the demand.

task - [4555666](https://www.odoo.com/odoo/project/966/tasks/4555666)

Forward-Port-Of: odoo/odoo#199027

**Issue**
When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable.

**Steps to Reproduce**
1. Install the Accounting module.
2. Go to Taxes.
3. Select a tax and open Advanced Options.
4. Set a very long name for the tax group.
5. Go to Accounting > Customers > Invoices.
6. Create and confirm an invoice using the tax with the long group name.
7. Print the invoice PDF and observe the layout issue.

**Root Cause**
The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary.

**Fix**
Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page.

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

Forward-Port-Of: odoo/odoo#211950

_Description of the issue/feature this PR addresses:_

When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available.

_Current behavior before PR:_

As an HR manager, go to menu HR -> Configuration -> Activity Plan. Click 'New'. Under Activities To Create, click 'Add a line'. Under 'Assignment', the only options available are Ask at launch and Default user.

<img src="https://github.com/user-attachments/assets/97be6790-b450-42c6-910a-07483c30e175" width=50% height=50%>

Cancel the 'Create Activities' popup. Give the plan a name and save it. Again, under Activities To Create, click 'Add a line'. Only now are HR specific options (Coach, Manager etc) available under 'Assignment'.

_Desired behavior after PR is merged:_

HR specific values for 'Assignment' are immediately availalbe when setting up a new plan for the Employee model.

![image](https://github.com/user-attachments/assets/391da1c1-c1ed-495a-a25f-48941554791a)

_Technical solution:_

Pass the plan's model as the default model for new templates so that the related field is populated with a value that unlocks the HR specific values before first saving the plan.

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

Forward-Port-Of: odoo/odoo#213411

Steps to reproduce the bug:
- Create a storable product “P1”:
    - Update the quantity to 1 in "WH/Stock"
    - Create a putaway rule:
        - From "WH/Stock" to "WH/Stock/Shelf1"

- Create a manufacturing order:
    - Select any product to produce
    - Add a component:
        - 1 unit of P1

- Confirm and validate the MO
- Unbuild the order

Problem:
A stock move for P1 is created from "Virtual Location/Production" to "WH/Stock/Shelf1" instead of "WH/Stock".
This happens because the `_apply_putaway_strategy` method is not called on the `stock.move.line` linked to the move.

In previous versions (e.g., v17), this issue didn't occur because the quantity was directly set on the move. This triggered a write on the `stock.move` model, which in turn called `_set_quantity`. Since no `stock.move.line` was linked at that point, a new one was created, and its quantity was set via `_set_quantity_done`, which itself called `_apply_putaway_strategy`:

- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L202
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L399
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L384
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L2133

This scenario used to work only when the product was untracked:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L186

However, starting from v18, some code was refactored to clean up unnecessary conditions. The `else` block was removed, and now, regardless of the product type, the quantity is not set directly on the move anymore. Instead, a `stock.move.line` is created using `_prepare_move_line_vals`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L197

But `_apply_putaway_strategy` is not called in this flow.

Bug introduced in v18.0, commit:
https://github.com/odoo/odoo/commit/79d9dd7f15371aa7293a4af0b0ebd193aa80e2be

opw-4830952

Forward-Port-Of: odoo/odoo#212604

Currently, an error occurs when the user attempts to import a `Datetime` object into a field that is not of type Datetime (e.g., `External ID`).

Steps to replicate:
- Install Accounting and Import Invoices through the file attached.
- On any date field select `External ID` and click Test.

Error:
`TypeError: argument of type 'datetime.date' is not iterable`

This error occurs due to a recent change introduced in version saas-18.1 [PR](https://github.com/odoo/odoo/pull/206876), where `Datetime` objects are now passed directly [1] instead of being converted to string(18.0 [2]). This change has led to multiple issues during data processing.

This commit resolves the issue by preemptively raising column-level warnings for fields with incompatible data types (e.g.,importing a Date into an External ID column), preventing errors before they occur.

[1]-https://github.com/odoo/odoo/blob/d000cf0be02253af1ac1beb6d54b46dcdeac3648/addons/base_import/models/base_import.py#L480-L484
[2]-https://github.com/odoo/odoo/blob/752ba2927e0b61cd6315e5c780a5292a6e99fe17/addons/base_import/models/base_import.py#L479-L483
[Journal Entry (account.move) (25) (1).xlsx](https://github.com/user-attachments/files/20339804/Journal.Entry.account.move.25.1.xlsx)
sentry-6604789067, 6591445640, 6604916781, 6596056524, 6589051928
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#210729

If customers migrate to version 18 from a lower version, 'Create Bill' record newly introduced so it just create but not translated.

**Before fix:**
```
test_18=# select id,name from account_reconcile_model;
 id |                                                            name                                                            
----+----------------------------------------------------------------------------------------------------------------------------
  3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
  1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
  2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
  4 | {"en_US": "Create Bill"}
  5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
```

**After Fix:**
```
test_18=# select id,name from account_reconcile_model;
 id |                                                            name                                                            
----+----------------------------------------------------------------------------------------------------------------------------
  1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
  2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
  5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
  3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
  4 | {"en_US": "Create Bill", "es_AR": "Crear factura"}
```
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#213346

**Issue**
In the Mexican localization, the CFDI usage (`l10n_mx_edi_usage`) field is not visible on POS orders in the backend. This prevents users from selecting or modifying the usage when manually generating an invoice from the POS order.

**Steps to Reproduce**
1. Install the Point of Sale app and the Mexican localization (l10n_mx)
2. Complete a POS order without generating an invoice
3. In the backend, go to Point of Sale > Orders > Orders
4. Open the newly created order
5. Notice that the CFDI Usage field is missing

**Root Cause**
The usage field is given a default value at the model level: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L65-L70 However, this value gets lost during the order processing flow. When an invoice is requested directly from the POS UI, the usage is explicitly set in the `sync_from_ui` method: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L110-L112 But if no invoice is requested at the time of the order, the usage is not preserved or restored in the backend. 

**Fix**
Explicitly set the CFDI usage to its default value when an invoice is not requested during the POS flow. This ensures the usage field is retained and displayed properly in the backend, allowing users to create invoices manually.

opw-4776487

Forward-Port-Of: odoo/enterprise#85954

Currently, the VAT is split into two columns only if the VAT code
consists solely of numeric values. However, in practice, VAT code
may contain a combination of letters and numbers.

**Steps to reproduce :**

1) Install `l10n_de_reports` and switch to the `DE` company 
2) Create a partner with VAT as `NL000099998B57` from contacts
3) Now create a confirmed invoice for the above created partner
4) Go to "Accounting / Reporting / Audit Reports / General Ledger"
5) Download "DATEV DATA (ZIP)" and check "EXTF_customer_account.csv"

**Issue:**

Notice that the VAT was not split into country and VAT code for the above created partner.

**Cause:**

Previously, the code only split the VAT into country code and VAT code
if the first two characters were alphabetic and the remainder was numeric.

https://github.com/odoo/enterprise/blob/35944a38d306ea881e08e1d51ca77a3eab3a6e36/l10n_de_reports/models/datev_export_csv.py#L220-L227

This approach is insufficient because many countries have VAT codes that
include both letters and numbers.
For example vat formats for `NL` and `AT`
https://business.gov.nl/finance-and-taxes/vat/numbers-for-vat/
https://ec.europa.eu/taxation_customs/vies/#/faq

So by only checking whether the VAT code is numberic is not a valid thing.

**Solution:**

The code now uses the partner’s `_split_vat` method to separate the country code
and VAT code whenever a VAT is provided and has more than two characters.
It then validates the split VAT using the `simple_vat_check` helper method.

If the VAT is valid, the country code (in uppercase) and the VAT code are output
in separate columns; otherwise, the original VAT value is kept.

This change ensures that VAT numbers with alphanumeric codes are correctly
handled and split into their respective columns.


opw-4820929

Forward-Port-Of: odoo/enterprise#87167
Forward-Port-Of: odoo/enterprise#86992