The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2].

On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly.

There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following:

- Chase specifies to left-justify them [^3]
- The most extensive open-source ACH library left-justifies them [^4]
- Another Python ACH library left-justifies them too [^5]
- Online images of ACH files seem to left-justify them as well

The only two remaining fields that are right-justified with spaces ({:>...}) are Immediate Destination and Immediate Origin. This is on purpose. Although they are numeric fields and thus right aligned, they are specified to start with a blank space, not a leading 0 [^2].

[^1]: https://web.archive.org/web/20230624090124/https://files.nc.gov/ncosc/documents/eCommerce/bank_of_america_nacha_file_specs.pdf
[^2]: https://achdevguide.nacha.org/ach-file-overview
[^3]: https://www.chase.com/content/dam/chaseonline/en/demos/cbo/pdfs/cbo_nacha_filespecs.pdf
[^4]: https://github.com/moov-io/ach/blob/073d011f811605e1b6051792163159a55feca533/converters.go#L81-L94
[^5]: https://github.com/travishathaway/python-ach/blob/cc8b6448d75f3815c91d3b8a5dadd6731aa96e71/ach/data_types.py#L57-L76

opw-4033830

Forward-Port-Of: odoo/enterprise#66286

### Steps to reproduce the issue:

1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy
2. Go to _Field Service > Configuration > Projects_ and choose a Project
3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created
4. Create a Task for the Project
5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour
6. Click on "Mark as done", then "Sales Order"
7. The Delivered Quantities have a correct value but the Ordered Quantities do not

### Explanation:

An uom conversion is performed in `_get_delivered_quantity_by_analytic` to compute `qty_delivered` but is missing in `_fsm_create_sale_order_line` for `product_uom_qty`.
https://github.com/odoo/odoo/blob/18e03c73691d9efa82cbf82b5e084172fe74665e/addons/sale/models/sale_order_line.py#L386-L392

### Suggested Fix:

To prevent unintended behaviours, any product that is currently used in a Field Service Project will have `invoice_policy`, `service_type` and `detailed_type` locked to match the domain of `timesheet_product_id` for every model using it.

opw-3858530

Forward-Port-Of: odoo/enterprise#66252
Forward-Port-Of: odoo/enterprise#63337

## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear

The aim of this commit is to make the report behaves correctly when
facing a DB with a lot of vehicles and a lot of accounts by making the
query `group by` and `order by` more robust.

Context:
- 1 account and 1 vehicle share the same number for the id
- the account is tagged with disallowed expense tag
- 1 `account.move.line` without vehicle in that account
- 1 `account.move.line` with a vehicle (with a dna rate) in the same
  account

Before the commit:
- The computation is giving wrong result in the report: 2 `account.move.line`
  were aggregated together under the hierarchy of the account without vehicle
  and the vehicle doesn't appear in the report at all.
  cause: the `CASE WHEN` could return, for example `92` as a `vehicle_id` and
  then `92` as an `account_id` and thus have them regrouped together.

- 2 lines of the report were sharing the same "line_id" (the id given by
  report framework id, see method `_build_line_id`) which are used in a
  t-key property in an OWL loop resulting in a crash for the front-end.

After the commit:
- The 2 lines are aggregated seperatly: The line without `vehicle_id` is under
  the hierarchy of the account and the line with `vehicle_id` is under the
  hierachy of the concerned vehicle.
- The line doesn't share any line_id anymore

task-id: None (issue discovered in our own prod)

## [IMP] account_reports: ensure line_id is uniq in tests

Moved to https://github.com/odoo/enterprise/pull/66216

Forward-Port-Of: odoo/enterprise#66462
Forward-Port-Of: odoo/enterprise#64166

Steps to reproduce
-------------------
- create a commission plan with:
    product category: "All"
    rate: R capped: True
    max commission: >>>
- create a partner level with the created commission plan
- create a partner with the created partner level

- create a product in the correct category with price P
- create a quotation template with the created product

- create a sale order with the partner as referrer
- add the quotation template (the product is added automatically)
- confirm
- create the invoice, confirm it and register the payment

At this moment, a purchase order is created (the commission) If we repeat these steps with a new sale order,
the amount of the purchase order will increase as expected.

- add a quotation template on the commission plan (in the rules)
- repeat the creation of a sale order.

No commission is added (purchase order line).

Cause:
------
We have no template when calling `_match_rules`.
However, our plan has a default template.
The result is that no rules are found.

Solution:
---------
Fallback on the sale order's template
if it is not a subscription.

opw-3933323

Forward-Port-Of: odoo/enterprise#64884

Issue
=====

When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity.

How to reproduce
================

- Enable "Product Packagings" and "Units of Measure";
- Select GS1 nomenclature as the Barcode Nomenclature;
- Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349);
- In the Barcode app, create a new receipt;
- Scan a GS1 barcode containing both the packaging barcode and a weight (e.g.: 10123456000123493103001500) => The scanned weight is used as the quantity and is multiplied by the packaging quantity (in this example, the quantity will be 6, because 4 units x 1.5 kg = 6 units)

Expected Behavior
=================

Since the associated product uses Units as UoM, the scanned weight can't be converted into quantity (we can't convert g or kg into units), so this information should be ignored and the packaging quantity should be used alone instead.

Note that the packaging quantity will still multiply the scanned quantity if the share the same UoM category. This behavior is still supported to be able to scan multiple packagings at once. That said, this use case make sense for products using Units only.

[OPW-3988826](https://www.odoo.com/odoo/11258/tasks/3988826?cids=1)

Forward-Port-Of: odoo/enterprise#66375
Forward-Port-Of: odoo/enterprise#65073