After this PR - transporter gst number is not required while submitting ewaybill if vehicle number is present and mode of transportation is by road - vehicle number can be left empty if transportation document no is set however transporter gst is required for that case task-4807693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213238 Forward-Port-Of: odoo/odoo#211088

After this PR

- transporter gst number is not required while submitting ewaybill 
  if vehicle number is present and mode of transportation is by road
- vehicle number can be left empty if transportation document no is set 
  however transporter gst is required for that case

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

Forward-Port-Of: odoo/odoo#213238
Forward-Port-Of: odoo/odoo#211088

Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on order confirmation; 2. give it a sales description; 3. add it to an order and confirm. Issue ----- The task is named using the sales description. Cause ----- Commits 47d223759f07 & c3877b2acd74 attempted to restore previous task/display name behavior by using the second line of the SOL description as the task/display name. This behavior only happened in previous versions when the line des

Versions
--------
- 18.0+

Steps
-----
1. Have a service product that creates a task on order confirmation;
2. give it a sales description;
3. add it to an order and confirm.

Issue
-----
The task is named using the sales description.

Cause
-----
Commits 47d223759f07 & c3877b2acd74 attempted to restore previous task/display name behavior by using the second line of the SOL description as the task/display name.

This behavior only happened in previous versions when the line description was manually modified.

Solution
--------
Only use the new behavior if the line name isn't the same as the default.

opw-4634149

Forward-Port-Of: odoo/odoo#213225

Author was set as "odoo" (lowercase). This commit removes the author key so it fallbacks to the default one, i.e. Odoo S.A. This also aligns keys with previous commits like 42bad1a6 and ef7005f5. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190655

Author was set as "odoo" (lowercase). This commit removes the author key so it fallbacks to the default one, i.e. Odoo S.A.

This also aligns keys with previous commits like 42bad1a6 and ef7005f5.


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

Forward-Port-Of: odoo/odoo#190655

This commit is a followup of [1] where we compute the minimum required width for date and datetime fields in list views. However, it didn't take into account decorations that could be applied to list views, in particular `decoration-bf`, which may, for certain fonts, increase the width of date values. We tested all languages, on different systems (thus different standard fonts), and an increase of 5% of the computed width is enough on those systems to display date and datetimes without an ellips

This commit is a followup of [1] where we compute the minimum required width for date and datetime fields in list views. However, it didn't take into account decorations that could be applied to list views, in particular `decoration-bf`, which may, for certain fonts, increase the width of date values. We tested all languages, on different systems (thus different standard fonts), and an increase of 5% of the computed width is enough on those systems to display date and datetimes without an ellipsis, even in bold.

[1] odoo/odoo#210584

No task, issue reported on our prod

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

When a loyalty program is already applied in a sale order, the same loyalty program could also be triggered in the POS. Steps to reproduce: ------------------- * Create a simple loyalty program with a discount of 10% on order that is applied automatically if the total of the order is more than 1$ * Create a sale order with a product of 10$ and apply the loyalty program * You will have a disount of 1$ in the sale order * Open the PoS and settle the order * A new discount will appear in t

When a loyalty program is already applied in a sale order, the same loyalty program could also be triggered in the POS.

Steps to reproduce:
-------------------
* Create a simple loyalty program with a discount of 10% on order that is applied automatically if the total of the order is more than 1$
* Create a sale order with a product of 10$ and apply the loyalty program
* You will have a disount of 1$ in the sale order
* Open the PoS and settle the order
* A new discount will appear in the PoS with a discount of 0.9$.
> Observation: You now have 2 discounts coming from the same program

Why the fix:
------------
We now adapt the `_programIsApplicable` function to check if the program was already used in the sale order. If it was, we ignore the program in the PoS.

opw-4381890

Forward-Port-Of: odoo/odoo#213047
Forward-Port-Of: odoo/odoo#209877

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

**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: Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. ### Current behavior before PR: Event updates/ new syncs with google_calendar might trigger email notifications, even for past events, causing useless invitations/ updated invitations to users. ### Desired behavior after PR is merged: Email notifications are only sent for active or future

### Description of the issue/feature this PR addresses:
Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over.

### Current behavior before PR:
Event updates/ new syncs with google_calendar might trigger email notifications, even for past events, causing useless invitations/ updated invitations to users.

### Desired behavior after PR is merged:
Email notifications are only sent for active or future events. Creation-from-sync / Updates to past events that have already ended are no longer triggering emails.

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

Forward-Port-Of: odoo/odoo#208302

This reverts commit 6d0d0e58b9f2c4ee2519e8e960e156c7e7be9841. The deployment of the reverted commit revealed an error: l10n_us_reports does not depend on l10n_us_account (only l10n_us), so it can't override the US tax report in data and crashes. We sadly cannot fix that in stable ; we'll do it in master. Forward-Port-Of: odoo/odoo#213363

This reverts commit 6d0d0e58b9f2c4ee2519e8e960e156c7e7be9841.

The deployment of the reverted commit revealed an error: l10n_us_reports does not depend on l10n_us_account (only l10n_us), so it can't override the US tax report in data and crashes. We sadly cannot fix that in stable ; we'll do it in master.

Forward-Port-Of: odoo/odoo#213363

Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213103 Forward-Port-Of:

Because the `location.assign` method also triggers a `beforeunload`
event, the `error_service` doesn't handle errors when downloading a file
with the action target `download` (for example download vCard). See [1]
for more details about the original fix.

task-4457865

[1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#213103
Forward-Port-Of: odoo/odoo#212432

Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 --- I confirm I have signed the CL

Issue:
The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected.
Solution:
If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document.
Addresses ticket-4715709
task-4756812

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

Forward-Port-Of: odoo/odoo#213152
Forward-Port-Of: odoo/odoo#212535

**Description of the issue/feature this PR addresses:** There's no hook to manipulate order values before write. **Current behavior before PR:** You cannot add custom logic easily w/o writing again on the order **Desired behavior after PR is merged:** Ease custom logic implementation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213167

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

There's no hook to manipulate order values before write.

**Current behavior before PR:** 

You cannot add custom logic easily w/o writing again on the order

**Desired behavior after PR is merged:**

Ease custom logic implementation.




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

Forward-Port-Of: odoo/odoo#213167

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 be

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

_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/ass

_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

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 wi

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

This commit fixes a test involving a boolean property field in list view that randomly fails. The problem was that we clicked twice to toggle the boolean value: once on the cell (I assume that it was done to switch the row in edition), and one on the checkbox to toggle it. However, boolean fields in list views don't require the row to be in edition to be toggled. So the first click already toggled the value, and the second click toggled it again, **sometimes** (I guess that's the non determinist

This commit fixes a test involving a boolean property field in list view that randomly fails. The problem was that we clicked twice to toggle the boolean value: once on the cell (I assume that it was done to switch the row in edition), and one on the checkbox to toggle it. However, boolean fields in list views don't require the row to be in edition to be toggled. So the first click already toggled the value, and the second click toggled it again, **sometimes** (I guess that's the non deterministic part, it was a question of timing there).

So this commit fixes the issue by removing one of the 2 clicks.

runbot error~224053

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

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

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

When executing follow-up actions, a KeyError could occur if the 'journals' key was missing from the options dictionary Steps to reproduce: Go to Accounting > Reports, open the Follow-up Report, and click Options. Untick journals so that the 'journals' list is effectively removed. Go to Customers, select any customer, Click on Customer Statement. Try to change Report (up right) to Follow_Up Report OPW-4798813 Forward-Port-Of: odoo/enterprise#87079

When executing follow-up actions, a KeyError could occur if the 'journals' key was missing from the options dictionary

Steps to reproduce:
Go to Accounting > Reports, open the Follow-up Report, and click Options. Untick journals so that the 'journals' list is effectively removed. Go to Customers, select any customer, Click on  Customer Statement. Try to change Report (up right) to Follow_Up Report

OPW-4798813

Forward-Port-Of: odoo/enterprise#87079

Previously, the `company_id` field on `budget.analytic` was mandatory. - Removed the `required=True` constraint on the `company_id` field in the `budget.analytic` model. - Updated the record rules `budget_comp_rule` and `budget_lines_comp_rule` to allow access to records where `company_id` is either in the user's companies or unset (`False`). task-4677599 Forward-Port-Of: odoo/enterprise#82955

Previously, the `company_id` field on `budget.analytic` was mandatory.

- Removed the `required=True` constraint on the `company_id` field in the `budget.analytic` model.
- Updated the record rules `budget_comp_rule` and `budget_lines_comp_rule` to allow access to records where `company_id` is either in the user's companies or unset (`False`).

task-4677599

Forward-Port-Of: odoo/enterprise#82955

This reverts commit 1e8f79bd0a5e53f34cd8dfaea0a4d3e199aca0c7. The deployment of the reverted commit revealed an error: l10n_us_reports does not depend on l10n_us_account (only l10n_us), so it can't override the US tax report in data and crashes. We sadly cannot fix that in stable ; we'll do it in master. Forward-Port-Of: odoo/enterprise#87195

This reverts commit 1e8f79bd0a5e53f34cd8dfaea0a4d3e199aca0c7.

The deployment of the reverted commit revealed an error: l10n_us_reports does not depend on l10n_us_account (only l10n_us), so it can't override the US tax report in data and crashes. We sadly cannot fix that in stable ; we'll do it in master.

Forward-Port-Of: odoo/enterprise#87195

Description ----------- When copying a document, a new attachment is created and linked to the copied document. Since `documents.document.is_multipage` depends on `documents.document.datas`, which is related to `attachment_id.datas`, and `attachment_id` was just written to, `_compute_is_multipage` will be recomputed during flushing before commit, as it's a compute stored field. This is problematic when copying multiple large documents, since this compute reads the entire binary data to dete

Description
-----------
When copying a document, a new attachment is created and linked to the copied document. Since `documents.document.is_multipage` depends on `documents.document.datas`, which is related to `attachment_id.datas`, and `attachment_id` was just written to, `_compute_is_multipage` will be recomputed during flushing before commit, as it's a compute stored field.

This is problematic when copying multiple large documents, since this compute reads the entire binary data to determine if it's more than one page.

This commits explictly writes on `is_multipage` to implicitly add it to the protected fields, which will prevent its' recomputation when flushing.

Benchmark
---------
Copying 5 documents (PDF) of 50MB each takes in total:

| Before | After  | Diff   |
|--------|--------|--------|
| 1.61GB | 1.17GB | -27.3% |

Reference
---------
opw-4829372

Forward-Port-Of: odoo/enterprise#86885

Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed. Steps to reproduce: ------------------- * Install `l10n_mx` * With company other than MX, go to the pos orders * Select multiple pos orders, select the button **Actions** > Observation: The action `Create Global Invoice` is visible * Select the action `Create GLobal Invoice` > Validation error, Selected orders are not eligible for CFDI Why the fix: -

Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed.

Steps to reproduce:
-------------------
* Install `l10n_mx`
* With company other than MX, go to the pos orders
* Select multiple pos orders, select the button **Actions**
> Observation: The action `Create Global Invoice` is visible
* Select the action `Create GLobal Invoice`
> Validation error, Selected orders are not eligible for CFDI

Why the fix:
------------
This is an `ir.actions.server` which is introduced in the `l10n_mx` localization.

It does not look possible to add `invisible` on the xml for the action. https://github.com/odoo/odoo/blob/2540155b5e00a6547fcceee4af4b83f385dcd4ad/odoo/addons/base/models/ir_actions.py#L179-L215

What we can do instead is to throw a more explicit error when trying to use the action outside the MX loca.

opw-4805257

Forward-Port-Of: odoo/enterprise#86612

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 (Z

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