The tax report (KMD report) and annex to the tax report (KMD INF report) for Estonia needed to be reworked to correct errors and fix rounding issues.

With this commit, the tax report:
1. Adds the balance_from_tags to allow auditing the report lines, since only aggregation was used before.
2. Fixes rounding issues by using the integer_rounding feature and adding rounding differences to the VAT closing entry.

This commit also rewrites the KMD INF report. It creates one report composed of two sections with different columns, using the custom engine to construct both parts.

Part A contains information on invoices issued, grouped by move_id and id, to allow showing multiple lines per invoice when different tax rates or special tax types are in one invoice. It only includes invoices with taxable supply at 22%, 20%, 9% and 5%. It excludes invoices of partners whose Tax ID is / and foreigner partners who have a Tax ID not starting by EE.

Part B contains information on invoices received, grouped by move_id. Each line showcases information about one invoice with taxable supply at 22%, 20%, 9% and 5%. It relies on a Tax ID starting with EE.

The reports follow the guidelines available in
https://www.emta.ee/en/business-client/taxes-and-payment/tax-returns-exchange-information/vat-return-forms-vd-and-vdp (forms valid from 01.01.2024 onwards).

task-3997203

Forward-Port-Of: odoo/enterprise#70371

### Steps to reproduce:

- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse
- Go to Inventory > Products > Products
- In the search bar type `foo` string > Search Warehouse for `foo`
- Click on any product Kandan record
- Click on the Forecast smart button of the product
#### > Traceback

### Cause of the issue:

Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains:
https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer.

### Fix:

The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else.

### Note:

This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue:
903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805

Community: https://github.com/odoo/odoo/pull/187808

opw-4290818

X-original-commit: 856409a1fb35c6c49fe4c404931587a95d99d370

Forward-Port-Of: odoo/enterprise#74188

Issue:
When printing PDF reports, long account names cause the report to overflow out of the page.

Steps to reproduce:
- Install the accounting app
- Enable "Analytic Accounting" in the settings
- Create one (or more) analytic account(s) with very long names
- Open either "Balance Sheet" or "Profit and Loss" reporting
- Do an "Analytic Group By" with the created account(s)
- Print the PDF

Cause:
The default style in the associated scss file does not use wrapping.
https://github.com/odoo/enterprise/blob/bf6c64b8fd5591f271e9b0f18f40d205a64cd5bd/account_reports/static/src/scss/account_pdf_export_template.scss#L41

Solution:
Override the default style by using the "o_overflow_name" class. This is the class already used for handling overflow in the tables' content lines. This gives a more readable result than just editing the "white-space" field (see below for comparison).


The proposed solution gives the following result:
![image](https://github.com/user-attachments/assets/265d96f4-fd8b-4152-a56a-07dcad662ef0)

As opposed to just editing to "white-space: wrap;"
![image](https://github.com/user-attachments/assets/b2a5a704-5ea2-4ef1-b2aa-48f778575b3a)

Ticket:
opw-4277596

Forward-Port-Of: odoo/enterprise#73761

## Steps to reproduce the issue

1. Activate Mexican Localization
2. In Mexican Company, create two Invoices with one product line:
    - Price Unit of 3.47, 16% Tax
    - Activate CFDI to Public
3. Select both Invoices and create Global Invoice ("Actions" drop menu)
4. Check the CFDI tab in one of the Invoices
5. One of those errors pops up depending on your rounding method:

#### Round per line:
>     Code : 301
>     Message : Error de validaciones adicionales [Error #CFDI40108] El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. Folio: 2. Serie: GINV/. El valor del atributo SubTotal (6.95) no coincide con la suma de los importes (3.47 + 3.47 = 6.94)

#### Round globally:
>     Code : CFDI40205
>     Message : El valor del campo TotalImpuestosTrasladados no es igual a la suma de los importes registrados en el elemento hijo Traslado.

## Explanation

#### Round per line:
With commit odoo/enterprise@933864a38af21a70b219d2824c64fff488acb15f, base and tax amounts were tweaked in order to satisfy some CFDI constraints. This change calculates amounts in an incorrect order: instead of calculating `tax_amount` with the formula `base_amount * tax_rate`, it calculates the base using `total / (1 + tax_rate)` then subtracts the base from the total to obtain the tax amount.
In our example, with a total of `6.94 + 1.12 = 8.06`, the base is calculated as such: `8.06 / 1.16 = 6.94827586207`, rounded to `6.95`, and the tax as such : `8.06 - 6.95 = 1.11`. The difference between the tweaked base `6.95` and the addition of the base of all invoice lines `3.47 + 3.47 = 6.94` is not accepted.

#### Round globally:
During a Global Invoice creation, we will first calculate the values of the Invoices separately. During this calculation, `total_impuestos_trasladados` is rounded with `precision_digits=2` while values in `traslados_list` are rounded with `precision_digits=6`. https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L583-L590 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L950-L961 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L963-L964 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L1000-L1001
In the example, `3.47 * 0.16 = 0.552`, is rounded to `0.56`. The addition of every rounded value gives `1.12` or `1.110400`, which gives the difference between `total_traslados_impuestos` and `traslados_list`.

## Fix reasoning

#### Round per line:
We will add a hack in `_get_post_fix_tax_amount_map`: CFDI accepts a difference of `1e-<precision_digits>`, which means that `precision_digits=2` would allow a difference of `0.01`. If the difference is lower, we will not perform the operation and only round the values.
In our example, the obtained tax amount is `1.12` and the expected tax amount `6.94 * 0.16 = 1.1104`. The difference between the two is lower than `0.01` and is accepted by the CFDI.

#### Round globally:
We will use the calculated values in `_get_global_invoice_cfdi_values` to compute the total price and totals of taxes at the end of the method instead of using the rounded values received from `cfdi_values_list` at the start.

opw-4085403

Forward-Port-Of: odoo/enterprise#72341

### Steps to reproduce:

- Enable "Multi-Steps Routes" in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in manufacturing in 2 steps
- Create an MO for a product and add an operation (no need of component)
- Confirm the MO and go to your operation in the shopfloor
- Click on the 3 dots > Add component > add any component
#### >  Back to the MO: No transfer was created from stock to pre-prod

### Cause of the issue:

When you add component from the shopfloor, you will trigger a call of the `add_product` method to create and confirm the raw move associated to the MO:
https://github.com/odoo/enterprise/blob/2e2efe8421b2f85950e50ff102cdabf98d2d91ab/mrp_workorder/wizard/additional_product.py#L36-L37 However, if the `procure_method`` of this move is not set to mto/mtso it will not trigger other rules in order to generate the other transfers

### Note:

A priori, the issue should not be reproducible in 18.0+ as this part of the code was refactored and the issue was fixed by 235047b68e6a24a14e32b94b1d4a15a580dc5ad2

opw-4236272

Forward-Port-Of: odoo/enterprise#74178

steps to reproduce:
- Install documents_account
- In Settings -> File centralization -> Activate "Accounting"
- Then click on Journals below
- Then add Jounal: Vendor Bill, Workspace: Finance
- Then upload a file in the app Documents, in the workspace Finance
- Select that file and update the partner to Azure Interior
- Click on the action "Create Vendor Bill"

The partner "Azure Interior" is not set on the created account move while it should.

For fixing this adding ``partner_id`` of document if present.

Now question may arise why account.move having null partner_id. because it being [set](https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/documents_account/models/documents_workflow_rule.py#L77) after creating [attachment](https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/documents_account/models/documents_workflow_rule.py#L76)
 and during create attachment ``document.partner_id`` is set to null and issue is raised.

opw-4077356

Forward-Port-Of: odoo/enterprise#74875

### Steps to reproduce:

- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse
- Go to Inventory > Products > Products
- In the search bar type `foo` string > Search Warehouse for `foo`
- Click on any product Kandan record
- Click on the Forecast smart button of the product
#### > Traceback

### Cause of the issue:

Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains:
https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer.

### Fix:

The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else.

### Note:

This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue:
903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805

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

Forward-Port-Of: odoo/odoo#187808
Forward-Port-Of: odoo/odoo#187413

**Current behavior:**
Having a manufactured product with components, all with
'average' costing, a series of receiptions for the components at
difference price points, followed by an MO, followed by another
reception at (again) a new price point will result in an
imbalanced "Cost of Production" journal if the aforementioned MO
is unbuilt.

**Expected behavior:**
The unbuild operation doesn't leave the journal imbalanced.

**Steps to reproduce:**
1. Create a stored product with average, real_time costing

2. Create a BoM for this product, with 2 stored components (also
with average, real_time costing)

3. Create a PO for the components (price is arbitrary), confirm
and receive the product

4. Create another PO for the components with a different price
from the previous PO, confirm and receive

5. Create an MO for the final product, confirm and
consume/produce all

6. Create a final PO for the components with prices different
from the previous two orders, confirm and receive

7. Create a second MO for the final product and
confirm/consume/produce-all

8. Unbuild the MO from step 5 -> in the "Cost of Production"
journal, observe that there is an outstanding balance

**Cause of the issue:**
When the unbuild operation happens, the current price of the
final product informs the SVL's `value` and `unit_price` fields-
which of course is not the same as when the MO was completed.

We end up with a `unit_price` on the SVL for the final product
which is not equal to the sum of the component SVLs'
`unit_price` which leads to the generation of account move lines
that won't be balanced.

**Fix:**
During an ubuild operation, stock moves for finished products
which may have this issue (i.e., have non-standard costing) with
linked SVL records will use that SVL's unit cost for the unbuild
SVL (and ensuing journal entries) as opposed to taking the
current cost.

opw-4062415

Forward-Port-Of: odoo/odoo#188016

**Steps to reproduce:**
- Install Accounting and l10n_de
- Switch to a German company
- Configure the customer invoice journal to enable "XRechnung UBL (Germany)"
- Create a German contact:
  * with a complete address
  * with an email address
  * without a VAT number
- Create an invoice for the created contact
- Confirm the invoice
- Generate the electronic invoice
- Validate the generated XML on an online XRechnung ValidationError

**Issue:**
The XRechnung (UBL Invoice) is not valid because the buyer electronic address is missing (cbc:EndpointID).

**Cause:**
`<cbc:EndpointID>` gets its value from contact's VAT, but the contact has no VAT.

**Solution:**
Since XRechnung 3.0.1, the email address can be used as electronic address with "EM" as schemeID.
So, fallback on email address if contact has no VAT.

**Reference:**
https://www.e-rechnung-bund.de/standard-xrechnung-3-0-1/
https://blog.seeburger.com/xrechnung-version-3-0-1-comes-into-force-on-february-1-2024/
https://erechnungsvalidator.service-bw.de/

opw-4261026



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

Forward-Port-Of: odoo/odoo#189183

current behaviour:
when buggy server action is introduced, we don't handle it well, eg:
```
name = record.name
if name != record.partner_id:
    raise UserError("Datatype")
```
here, comparing `name` and `record.partner_id` doesn't make sense, therefore our ORM default behaviour is to return false and rise `AttributeError`, but the problem occurs when pypdf2 attempts to format the warning message, which rises an error which isn't being handled:
```
  File "/home/odoo/.local/lib/python3.10/site-packages/PyPDF2/pdf.py", line 1069, in _showwarning
    file.write(formatWarning(message, category, filename, lineno, line))
  File "/home/odoo/.local/lib/python3.10/site-packages/PyPDF2/utils.py", line 69, in formatWarning
    file = filename.replace("/", "\\").rsplit("\\", 1)[1] # find the file name
IndexError: list index out of range
```
it is problematic since it is server action.

expected behaviour:
Even when buggy code is introduced, comparision should return False and error should be handled well.

steps to reproduce:
1) Create new database from scratch and create server action with the buggy code above, set model to `sale.orde` and add it to `contextual action`
2) Go to any `sale.order` record and trigger the action. 3) it outputs the error.
4) please note that, if you restart the server, error doesn't happen, because places where override happens doesn't get invoked.

task-4365106

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