Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels and Export Documents
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Set up commercial invoice (/invoice) to be sent to another printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Validate the delivery
> Observation: Nothing prints, jobs are sent to CUPS bu not printing

Why the fix:
------------
https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196

As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message.

In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46

Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing.

Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message.

opw-4546715

Forward-Port-Of: odoo/enterprise#83481
Forward-Port-Of: odoo/enterprise#82094

When importing a coda statement, in case of globalisation,
Odoo doesn't take into account the different levels of details.
Instead of that, we keep every lines even if one is already
the sum of each detailed lines.

According to https://febelfin.be/media/pages/publicaties/2023/archief-bankstandaarden/0c9e6e5026-1694763197/standard-coda-2.4-fr.pdf

Chapter 3.1

Transaction type are communicate like that:

- 0 -> simple amount without detailed data
- 1 -> amount as totalised by the customer
	- 5 -> detail of 1
- 2 -> amount as totalised by the bank
	- 6 -> detail of 2, simple amount without detailed data
	- 7 -> detail of 2, simple amount with detailed data
		- 9 -> detail of 7

Let's assume this case:

- 1 line with transaction type == 2, amount == 3000
- 1 line with transaction type == 7, amount == 2000
- 1 line with transaction type == 9, amount == 2000
- 1 line with transaction type == 7, amount == 1000
- 1 line with transaction type == 9, amount == 1000

Currently, Odoo will display lines 1, 2 and 4 in case of
split transactions instead of lines 3 and 5.
In case of not split transactions, Odoo sums up the same lines.

With this commit, we keep trace of last line's transaction type to:

- be able to delete it if it has detailed data, in case of split
  transaction
- to sum up only the relevant lines

opw-4619660
opw-4795349

Forward-Port-Of: odoo/enterprise#87523
Forward-Port-Of: odoo/enterprise#85006

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#87289
Forward-Port-Of: odoo/enterprise#86992

### Steps to reproduce:

- In the settings: Enable `Units of Measure & Packagings`
- Create a storable product with 100 units in stock and an associated packaging such as 'pack of 6'
- Create and confirm a sale order for 5 pack of 6.
> This creates and reserve a delivery for 30 units (5 pack of 6).
- Process the delivery in the barcode app and scan a pack of 6
#### > A new line is created for 1 pack of 6 instead of updating the quantity of the line referring to these packs to 5/30.

### Cause of the issue:

Since the packaging/uom refactoring, packagings are just uoms. Now, scanning the packaging will launch a call of the `_processBarcode` method. During this call, the existing line will not be be found and considered as an appropriate candidate to be updated since the its prodcut_uom is in Unit and the packaging uom is not: https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1710-L1711 As such, there will be no `currentLine` to update and a new line will be created:
https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1441-L1443

opw-4782296

Forward-Port-Of: odoo/enterprise#86659
Forward-Port-Of: odoo/enterprise#86180

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

### Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37 But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

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

opw-4798349

Forward-Port-Of: odoo/enterprise#87461
Forward-Port-Of: odoo/enterprise#86394

Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user.

**Steps to Reproduce:**
- Install **appointment_account_payment** module without demo data.
- Delete **Booking Fees** product`from `invoicing->customer->products`
- Click on `Paid Seats` or `Paid Consultation` in the Appointment App.

**Error:**
`ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have been deleted.`

**Root Cause:**
After deleting the **Booking Fees**, if user tries to open `Paid Seats` or `Paid Consultation`  the system will try to access id of `appointment_account_payment.default_booking_product` at [1] or [2] causing an error.

[1]-
https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L43

[2]-
https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L56

**Solution:**
This commit prevents error by restricting user from deleting the `Booking Product`.

Sentry-6013528364

Forward-Port-Of: odoo/enterprise#86159

Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name.

Purpose: When changing the country on a salary structure, the rules that appears on the payroll reporting needs to unlink outdated fields and regenerate the fields based on the new country value. The salary rule fields are dependent on the country due to its naming convention.

Steps to Reproduce on Runbot:
1. Install Payroll
2. Create a new salary structure with no country
3. Create a new salary rule and enable "View in Payroll reporting"
4. Check fields and observe that a field prefixed by 'x_l10n_xx' was created
5. Change the country set on the salary structure
6. Try to access a payroll report record and a traceback is thrown

opw-4649030

Forward-Port-Of: odoo/enterprise#87464
Forward-Port-Of: odoo/enterprise#83749