Steps to reproduce:
 - Install the planning module.
 - Open Gantt view in day scale.
 - Create a planning slot from 11am to 12pm for an employee whose working hours
   are 8-12 and 13-17
 - The default hours will be shown as 13 to 12

Issue:
 - When an employee works two shifts for example 8-12 and 13-17, and we are
   creating a slot from 11-12, the slot timing will show as 13-12 instead of
   8-12.

Cause:
- here is an example of how the planning slot will be calculated and what is
   miscalculation
 - When click on cell 9-10 the calculated hours
   <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table>
 

   so that slot timining will be 8 - 12

- When click on cell 11-12
  <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table>
   So that the slot timining will be 13-12 which should not be possible

Fix:
- We previously relied on the ```_adjust_to_calendar``` method to calculate the
  resource's working hours. However since the working hour intervals are
  already computed using ```_work_intervals_batch```, we are removing the method
  call to reduce code duplication. Calculate the working hours using
  ```_work_intervals_batch``` and return the appropriate work intervals based on
  the resource's working calendar.

task-3916687

Forward-Port-Of: odoo/enterprise#75594
Forward-Port-Of: odoo/enterprise#64961

### Steps to reproduce:
- Activate developer mode
- Install the 'l10n_ec' module and switch to an Ecuadorian company
- In Settings > Technical > Database Structure > Decimal Accuracy change the number of decimals for "Product Price" to 4 for example
- In Accounting, create a new Customer Invoice
- Select 'Instituto Ecuatoriano' as Customer
- Add a line with a price with 4 decimals
- Select 'Sin utilization del sistema financiero' as Payment Method
- Confirm
- On the blue popup at the top of the page, click 'process now' to get the XML in the chatter
- In the XML the "precioUnitario" field only has 2 precision digits, it has been rounded
- When adding a discount of 100% this field has all precision digits needed

### Cause:
The price_unit is calculated differently if the discount is 100%. The "precioUnitario" field should always have the number of precision digits specified in the settings.

### Solution:
We need to find the unit price without the discount, but without the included. This value is not computed.
As the values computed in the account.move.line are already rounded based on the currency (2 digits) we need to
recompute the values using `compute_all` and multiplying by the `price_digits` to not round in `compute_all`.

The way the rounding is made here is by taking the decimal precision from the settings and making it a power of 10 in `price_digits` (4 decimals results in price_digits = 10000). Then we compute the taxes with `price_unit * price_digits`. As, per definition,  `price_unit` has the number of digits used in the calculation of `price_digits`, we end up with an integer. But after the results of `compute_all` may no longer be an integer. We need an integer to keep the decimal precision. This is why, in the result, there is a call to `round()`.
The call to `float_round()` is to make sure there are not more decimals than 6. This is needed as the number displayed in the XML will always be of 6 decimals, so if the client set a number of decimals greater than 6, it will be rounded in the XML but not on the invoice. To ensure that both values are the same, we round the value here.

Some tests had "precioUnitario" with strange values that did not match the actual price_unit. It was because the precedent way to calculate this field was not perfect, I guess.

opw-4120341

Forward-Port-Of: odoo/enterprise#75152
Forward-Port-Of: odoo/enterprise#68555

### Issue:

Worksheet quality checks can not be validated if they bypass the Quality wizzard, e.g. when when there is no notes on the QC and it is not related to worksheet data's.

### Steps to reproduce:

- Install `quality_control_worksheet`
- Create a BOM for a product with an operation + add instr (list icon):
    - Control per operation, type: worksheet, template: Quality issues
- Create ans confirm an MO for 1 unit of your product
- Go to the shopfloor and fill the worksheet > Save
#### > You are never able to validate the instruction and hence the WO can never be marked as done.

### Cause of the issue:

Since ee1913d7080f6aee06dac004d56203f2c09d4bad (saas-17.2) e.g the change on the "if" condition:
https://github.com/odoo/enterprise/blob/4238d6b071a57b3378968064ad322ea39a8b1294/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L23-L28
the worksheet quality check is not marked as passed by the `action_worksheet_check` when the record is saved if no `quality_wizard_id` is set in the context. It is therefore expected to mark the quality check as passed only if it set through the validate button of the worksheet dialog. However, if the quality check does not have specific data's such as notes or a worksheet url, the worksheet dialog will be bypassed and there will not be a `quality_wizard_id` in the context of the action returned by `this.openWorksheet`:
https://github.com/odoo/enterprise/blob/4238d6b071a57b3378968064ad322ea39a8b1294/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L357-L362
https://github.com/odoo/enterprise/blob/0353a4c4307c2ac8d5a109a0e49be34a510e99ef/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L82-L85
https://github.com/odoo/enterprise/blob/0353a4c4307c2ac8d5a109a0e49be34a510e99ef/quality_mrp_workorder_worksheet/models/quality.py#L25-L27
It is therefore impossible to validate the quality check by any mean. Furthermore, the mark as done button of the WO is only visible once all the QC are either "pass" or "fail".

### Fix:

If we were to call the `action_open_quality_check_wizard` rather than the `action_quality_worksheet` the same action would be used but with an additional wizard would be in the context:
https://github.com/odoo/enterprise/blob/0353a4c4307c2ac8d5a109a0e49be34a510e99ef/quality_control_worksheet/models/quality.py#L53-L67
That way, if the `this.openWorksheet` is called without a worksheet dialog we will always have a wizard to rely on for the `action_worksheet_check` to be performed `onRecordSaved`.

### Other issue:

In the bypass condition is wrongly set since the `operation_note` field is used but is not defined on the `quality.check` model: https://github.com/odoo/enterprise/blob/4238d6b071a57b3378968064ad322ea39a8b1294/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L358 This condition should rather refer to the `note` field and the length should be used to determine if the string is falsy...

opw-4347352 and opw-4354876
---

Forward-Port-Of: odoo/enterprise#75137

Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually.

However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transactions" to start and handle all the invoices & payments created by "_create_recurring_invoice". The 2 CRON were then likely to create SerializationFailure due to a concurrent update.

With this commit, each batch creates its own deliveries before triggering the next batch. If the delivery creations do fail:
 - The error is caught as to not prevent the next batch from being triggered.
 - An exception activity is created on the subscription to notify the customer about the error.
 - A contextual action is available to manually trigger the delivery.

OPW-4319019

---

When the delivery creation failed, you can easily spot it on the list view thanks to the activity warning:
![image](https://github.com/user-attachments/assets/8d16147f-e336-41ff-9704-e1a5114c7ff3)

---

## Example log

```
2024-11-14 07:48:53,757 96554 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (30.353s). 
2024-11-14 07:58:26,142 96886 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 
2024-11-14 07:58:57,145 96886 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (31.003s). 
2024-11-14 08:05:51,910 97204 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 
2024-11-14 08:06:46,734 97204 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (54.823s). 
2024-11-14 08:06:53,143 97262 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 
2024-11-14 08:07:46,207 97262 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (53.064s). 
2024-11-14 08:07:55,496 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 
2024-11-14 08:08:30,928 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 
2024-11-14 08:08:44,957 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (49.461s). 
2024-11-14 08:08:50,945 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 
2024-11-14 08:09:18,543 97300 ERROR customer-database odoo.addons.base.models.ir_cron: Call from cron Sale Subscription: generate recurring invoices and payments for server action #705 failed in Job #10 
2024-11-14 08:15:52,854 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (441.926s). 
2024-11-14 08:18:31,161 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 
2024-11-14 08:21:16,823 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (165.662s). 
2024-11-14 08:28:31,865 99066 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 
```

- At the beginning: `payment: post-process transactions` take ~30 secs
- Then, `Sale Subscription: generate recurring invoices and payments` runs a few times (as expected).
- `payment: post-process transactions` re-runs, and it takes 441.926. During this time, `Sale Subscription: generate recurring invoices and payments` starts and failed.

---

## A few points of information/discussion:

- The SerializationFailure is systematic on the customer database, who has ~200 subscriptions invoiced each day.
- The added action "Subscription: Generate delivery" is optional, I am amenable to remove it from this PR, but we would just block the customer with undelivered stock.
- In master, it would be better to automatically detect the deliveries not done and re-generate each day. However, I was unable to find a proper way to do it without adding a field or changing the behavior of an existing one.
- I originally wanted to create to add a button to the form view like "Create Delivery", however, like above I was unable to properly detect undelivered subscriptions.
- The exception activity does not directly notify the users via discuss, do you think I should add the option?
- I did not (yet) created tests for this error. To properly do so, I would need to reproduce a SerializationFailure which I'm unsure of how to do without doing commits. I could simply fake it by overwriting the `_action_launch_stock_rule` to raise an Error... TBD

Forward-Port-Of: odoo/enterprise#75107
Forward-Port-Of: odoo/enterprise#73911