ISSUE
=====

Introduced in odoo/enterprise@bce7e94650c337a9046958a7689c81db5b2a4c73 , we now allow configuring a number of max simulatenous appointments per resource / user per slot, when manage_capacity is False.

However, this broke the booking flow when enabling a payment on the appointment type as well, for resources with capacity > 1. More specifically, as soon as the remaining capacity is lower than the resource's own capacity.

STEPS TO REPRODUCE
==================

0. Install payment_demo, in order to be able to test the payment issue. Install website_appointment_sale to ease the testing too.
1. Create an appointment type for 'Resources', enable 'Up-front payment'.
2. Set a new resource with capacity = 2 on the appointment type.
3. Make sure manage_capacity is False, and number of simultaneous appointments (max_bookings) is set to 1.
4. Go to the front end and pick any slot.
5. Fill the form and 'proceed to payment'
6. Try to 'pay now'
7. You get a validation error message telling you that the slot is not available anymore. But it is not the case since it is a new type and new resource.

FIX
===

For resources, created booking lines were setting capacity_used to the resource's capacity, unless shared. (meaning: the resource is completely used, even if the reserved quantity is smaller). It made sense before but not for this new feature. It should only use 1 capacity, as we count the number of different simulatenous appointments, and it is unrelated to the resource's own capacity.

When creating the meeting at the end of the regular flow, the computed field on capacity_used on appointment.booking.line will set it to 1 when manage_capacity is False. Hence, no issue will happen there in practice as the meeting is always created in that case and capacity_used updated.

However, when enabling a payment, we create a calendar.booking instead, with calendar.booking.lines. And based on those, we evaluate availability when checking the cart before going to payment.

Those are simply created from values in the controller, and the model is much simpler. Therefore, we fix the issue by manually setting the capacity_used to 1 when creating the booking lines in the front-end booking flow, in the case of an appointment without capacity management.

Task-4963012

Forward-Port-Of: odoo/enterprise#94434
Forward-Port-Of: odoo/enterprise#91700

### Steps to reproduce:
- Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company
- Have a bank with a BIC number and an account for that bank with a clearing number
- Create a vendor bill for a Swiss partner
- Pay with "Swiss ISO20022"
- Create a batch payment with that payment and validate
- In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId))

### Cause:
The code directly inputs the value of `clearing_number` in `ClrSysMmbId`.

### Solution:
Add `MmbId` to contain the clearing number.

### Note:
The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`.

This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations.

opw-4872507

Forward-Port-Of: odoo/enterprise#94460

Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings.

**Steps to reproduce:**

- Install the `l10n_ec_edi_stock` module and switch to the `EC company`.
- Uncheck `Barcode Scanner` in the Inventory `settings`.
- Create a new warehouse and set the `Entity` and `Emission Point`.
- Navigate to Inventory > Operations > Deliveries and create a new delivery.
- Add details > mark as Todo > Validate > Generate Delivery Guide.

**Error:**
`AttributeError: 'stock.move.line' object has no attribute 'qty_done'`

**Root Cause:**
At [1], the code references `line.qty_done`, but this field is defined in the
`stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, 
the field is not available, leading to the `error`.

**Fix:**
This commit updates the delivery guide values to use `line.quantity` instead
of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3],
`qty_done` is derived from `quantity`.

[1]:
https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354

[2]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23

[3]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50

[4]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165

sentry-6851008674

Forward-Port-Of: odoo/enterprise#93775

## **Issue Before This Commit:**
In the workcenter planning view, the total hours displayed were misleading,
as they always showed 24 hours of the day instead of the workcenter’s
defined working hours.
This caused confusion for users since the displayed total hours did not
match the actual available working time of the workcenter.

## **Steps to Reproduce:**
- Create a Manufacturing Order (MO).
- Add "Drawer" as the product.
- Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM.
- Set the quantity to produce as 10.
- Confirm the MO and plan it.
- Open the planning view and notice that the total hours count
  incorrectly shows 24 hours instead of the defined working hours.

## **Cause of the issue:**
The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486),
as the related changes were not adapted here.
Because of that, pill.record.workcenter_id[0] returns an undefined value.

## **With This Commit:**
The calculation of total hours has been corrected to consider only
the workcenter’s defined working hours.
Users now see accurate hours in the planning view, making it easier
to plan and schedule work orders reliably.

task - 4900885

Forward-Port-Of: odoo/enterprise#93035