Currently an error is generated when the user tries to save a report
with an empty XML format.

Steps to reproduce:
- Install web_studio and sale_management
- Sales > Studio > Reports > New > External > Type Text in report
- Save > Edit Sources > Remove full XML > Save

Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)`

This error occurs because line [1] in `web_editor` attempts to access
nodes by using `etree.fromstring()` with an empty `view.arch`, which is
empty, resulting in an error.

In earlier versions, this error was already handled by the `_check_xml`
constraint, which raised a validation error when an `etree.ParseError`
occurred while parsing `etree.fromstring(view.arch)` with an empty
`view.arch` (see code reference [2]). However, recent changes introduced
in commit [3] allow  `view.arch` to be empty. As a result, this error
is no longer handled by the constraint.

This commit fixes the issue by adding a condition to prevent calling
`etree.fromstring()` when `view.arch` is empty, avoiding attempts to access
nodes from invalid data. It also updates the logic in the `web_studio`
module's `get_xml_editor_resources` method to ensure resources are processed
only when a valid view architecture is available.


[1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367
[2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377
[3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f

sentry-6288795955

Forward-Port-Of: odoo/enterprise#88613

### Steps to reproduce:
	- Install the l10n_ae_hr_payroll module.
	- Configure at least two employees, who'll use the UAE Monthly pay structure.
	- On at least one of the employees, set the work entry source to attendance.
	- Register a paid leave time off entry, for the employee whose work entry source is set to attendance.
	- Compute a payslip batch using the UAE Monthly pay structure.
	- Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again.
	- The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually.

### Cause:
In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees

### Fix:
We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage.

opw-5979631

Forward-Port-Of: odoo/enterprise#111280

### Issue:

The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature.

### Steps to reproduce:

- Have 2 companies: company 1 and company 2
- Set the barcode nomenclature of company 1: default, company 2: GS1
- Incarnate a user allowed in both companies but with default company 1
- With company 2, create a product and set its barcode to 36939282410106
- From the main menu open the barcode app and scan 0136939282410106
#### > No product was found (even thought it is correct in GS1)

### Cause of the issue:

Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 
However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11
As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083
based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722

### Fix:

Setting the company slices the `current_company` in first position of the `allowed_company_ids`:
https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81
which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491
Note that passing the context in the arguments of the `main_menu` JSON  route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f

### Additional Issue:

The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Set the barcode nomenclature to GS1
- Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365
- From the main menu open the barcode app and scan 4133033710074365
#### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination)

opw-5847529

Forward-Port-Of: odoo/enterprise#111662

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs.

## Steps to replicate:
- Install Inventory
- Go to Settings and enable Multi-Step Routes > Set Warehouse Routes.
- Configure 2 steps for outgoing shipments.
- Go to Inventory and  create a new delivery with
   - **Source Location:** WH/Stock
   - **Product:**  [E-COM10] Pedal Bin with demand 1
- Mark as Todo then Archive the Pedal Bin product.
- Open that delivery in barcode app
- Pencil icon > +1 > Confirm

## Observed behavior:
TypeError: Cannot read properties of undefined (reading 'qty_available')

## Root cause:
After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above.

## Solution:
Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error.

It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button
followed by validation, ensuring consistency.

[commit]:
https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 
[2]-
https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45

opw-5980428

**Steps to reproduce:**
* Install the **account** and **fleet** modules.
* Create a vendor bill with two expense lines using the same tax.
* Assign a vehicle_id to one line but leave the other without a vehicle.
* Confirm the vendor bill.
* Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report.

**Observed behavior:**
* The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.'

**Cause:**
* The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`.
* When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`.
* The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency.

**Fix:**
* Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set.
* If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines.

opw-5956645

Forward-Port-Of: odoo/enterprise#110616