If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing should be created in a period covered by a lock date.

As a result, these transactions would be created at a wrong date (if the current month is the first after the lock date or if the sequence has a monthly reset, then they would be appended to the current month, else if the sequence reset annually, then they would be created at the current date).

Additionally, the potential opening balance would be created at a wrong date too, since it would try to create it one day prior to the oldest transaction.

The date which the opening balance is created would not be the same as the transactions above, which adds a layer to the mess created.

To prevent this, at initialization, we set the last sync date one day after the lock date, not the same day.

As for the opening balance, we do not try to set it one day prior to the oldest transaction, but the same day. The `internal_index` computed will ensure it is displayed as the first transaction of that journal.

Finally, the test related to statement creation were adapted to this new behavior. Some ordering based on `date` in other tests were changed to `internal_index` to unify the test file with these changes.

opw-4890538

Forward-Port-Of: odoo/enterprise#95138
Forward-Port-Of: odoo/enterprise#93543

Currently, an error occurs when submitting the 'Send Email' form.

Steps to Reproduce:

 - Install the `website` and `web_studio` modules.
 - Go to `website` > `Click on Edit` > `Drag and drop form`.
 - click the form and in actions select the `more models`, and select
   `outgoing mails(mail.mail)` model and `save`.
 - `Submit` the form, and the error appears in the `logs`.

**Error:**
`KeyError: 'website_form_signature'`

**Cause:**
This error occurs when submitting the "Send Email" form from the
 website. By default, the form action is `"Send an E-mail"`, and when 
the user `changes` the form’s model to outgoing mails (mail.mail), 
which also has the action "Send an E-mail," the system checks the 
existing model [1] and retrieves it. Since `shouldRerender` is set to 
false, [2] is not executed, and as a result, the `email_to(hidden field)` 
is not present in the form. And the website_form_signature is added 
from [3], but due to the condition at [4], the code at [3] is not executed. 
When it is accessed at [5], KeyError is raised.

**Fix:**
This commit ensures that when the user changes the model, 
`rerenderXml` is executed so that the `hidden field` is also added.

[1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156

[2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

sentry-6746753251

Forward-Port-Of: odoo/enterprise#93287

The TableSizeComputer.compute() method can return cells with incorrect cell indexes. This can result in the _addColumn function only adding a column to some rows in the report editor.

TableSizeComputer.compute() does not handle cases where a conditional is used inside of a th element but the corresponding td element does not have a conditional.

Steps to reproduce
-----
1. Open the Delivery Slip in the report editor.
2. Click the header to show the dropdown and select elif: o.move_line_ids and o.state=='done'.
3. Hover over the last th element to select the column button.
4. Click Insert right and see that only the header row has an additional column.

Cause
-----
TableSizeComputer.compute() calculates how many possible cells can be in a row which can be more than the total number of columns you have if you have th or td elements with a conditional inside of them.

In the Delivery Slip report, a th element is present when using serial numbers and a different th element is present when not using serial numbers. The corresponding t-body has two different tr elements for these conditions. The compute method will have one less cell in these rows because the corresponding conditional is handled outside of the row.

Solution
-----
Only count mutually exclusive th or td elements once. This prevents the cellIndex from being larger than the total possible columns.

opw-ticket 5173345

Forward-Port-Of: odoo/enterprise#98207

## Short functional explanation of the error
When setting the 'DHLxw Package Type' of a DHL delivery method to 'DHL pallets' without changing default values, trying to validate an order delivery causes an error.

## Reproduction Steps
1. Type 'Delivery method' in the dashboard. Select DHL BE, set the region to Europe and the 'DHLxw Package Type' to 'DHL pallets'. Click on the arrow at the right of 'DHL pallets'. You should see the default values set to 1200, 1600 and 1200. These correspond to millimeters, while DHL expects centimeters.
2. Make sure you're using a company located in Belgium.
3. In the inventory settings, make sure that either 'multi-step route' is unchecked or that for your warehouse, the outgoing shipments are set to '1 step'.
3. Create a new quotation. Select a Customer with a Belgian address. Add a product for which there's at least 1 copy in stock.
4. Click on add shipping and select DHL BE. Then click add and ok.
5. Click on confirm. A smart button at the top of the page called "delivery" should appear. Click on it and set the scheduled date to a future day. Finally, click validate.

### Expected behavior
New labels should generate without issue.

### Unexpected behavior
An error occurs:
```Bad request Multiple problems found, see Additional Details
1001: The requested product(s) (N) not available based on your
search criteria.(687662d08999745d3df3783068fcca24)
410107: The piece height exceeds max, N/-
410304: No products available
```

## Origin of the issue
The default values for DHL are set to 1200, 1600 and 1200, which correspond to millimeters. However, DHL expects centimeters, for which the default value is thus too high.
Note: because the issue stems from default values, after implementing the fix, the module should be reinstalled.

__
opw-4804639

Forward-Port-Of: odoo/enterprise#90272

Version:
- 18.0

Steps to reproduce:
- Open document which is send for signature.
- Refresh the browser.

Before:
- Refreshing the page was hiding the `sign now` and `cancel` button from control panel and also the name of document get replaced by 'unnamed' in breadcrumbs
- The `needToSign` value was loaded from the context and used later to show those button, which is only available when navigating from `go_to_document`. On refresh, the context was lost, leading to the error.
- Breadcrumbs were not getting set properly on reload.

After:
- Added `needToSign` to the URL query string.On page refresh, the data is retrieved from the URL as a fallback instead of relying on the context.
- Add name of document to URL query string and on page refresh use that name to get correct name of document and update name to breadcrumbs using `setDisplayName`.

Impact:
- Buttons remain visible after refresh.
- Correct document name is shown in breadcrumbs.
- Ensures a smoother and more stable user experience when viewing documents.

task-4805166

Forward-Port-Of: odoo/enterprise#98251
Forward-Port-Of: odoo/enterprise#93589