In the community pr, we removed the uniqueness constraint on the name of a reco model. Indeed, when doing a set account on multiple statement line, we check if there is a common substring and create a reco model if there is one. But the reco model created has the name of the account. Which means that we couldn't have two automatically generated reco model for the same account.

This commit will remove the check to see if a reco model already exist for that account. Since we now want to have the possibility to have different reco model for the same account.

Changed the name of the reco model created to avoid having 2 reco models using the same account that have the same name.

Also change the way we compute the longest substring because it was not working for all cases. For example:
Let's make 3 statements lines: Rent March, Rent May, Rent April. The current method will get the longest substring between the two first which is Rent Ma and then compare with the third one. But the longest common substring should have been Rent.

task-4876374

PURPOSE
=======

Some users would like to use unique slots instead of having
recurring ones. This can only be done from the share availabilities
button in the calendar view. While the appointment can be modified,
it is not intuitive to do it that way. We want to make the 'custom'
appointments easier to use and accessible.

MAIN CHANGES
============

As 'custom' appointment type means 'flexible' schedule and vice versa,
we do not store any more field. Instead, we use an editable computed
selection field that allows the user to switch between options with
the radio widget, and update category and slots accordingly in the
onchange and inverse (on category) methods.

As custom appointments are likely to get more frequent, and to be used
in various contexts, we now allow restrict_to_x_ids for unique slots and
effective min_schedule_hours.

NEW SLOT CONSTRAINT
===================

Since unique slots are easier to user, let us add a sql constraint to
ensure that the start_datetime and end_datetime are set for the unique
slots, and that start_datetime <= end_datetime.

We make sure we correctly update the slots when changing the category
in the appointment type form (see onchange and inverse methods)

OTHER CHANGES
=============

- In a separate commit, remove chevron counters and related code as
deemed low-value and disposable.
- New 'Flexible' filter and 'recurring' renamed to 'weekly'
- Some tests are added to ensure constraint and form reactivity on
category change. For options as well.

UPGRADE
=======

- We remove the 'invitations' submenu in the configuration that allowed
to see all 'custom' appointments. It is not relevant anymore and is
replaced with an available filter on the appointment.type search view.
We also remove the associated view.

- We remove ill-configured slots. As they are only used to generate
slots and not linked to other records, we can remove them altogether.
(constraints would still make them fail in the booking flow, so they
are not really working anyway)

UPG PR: https://github.com/odoo/upgrade/pull/8206

Task-4997980

Currently, an IndexError traceback occurs when changing the order state 
in the preparation display if it contains only one stage.

**Steps to reproduce this issue:**
1) Install POS, Kitchen Display
2) Create a preparation display by removing all but
   one stage in the prep settings.
3) Open a restaurant session and create an order.
4) Open the preparation display and mark the created order as DONE. 5) A traceback will occur

**Error:**
```
IndexError: tuple index out of range
```

**Cause:**

When the Done button is clicked in a preparation display with only one stage, 
an ORM call to `change_state_status` is triggered. This then calls 
`_record_status_change_prep_time`, followed by `is_stage_position`.
https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_state.py#L31-L40
https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_stage.py#L21-L22
In `is_stage_position`, static positions [0, -1, -2] are used to access items in the `stage_ids`. 
If only one stage exists, accessing indices -2 results in an IndexError.

**Solution:**

Before accessing a stage by position, check that the length of stage_ids 
is greater than or equal to the absolute value of the position.
This prevents attempts to access out-of-range indices.

opw-4985306

Forward-Port-Of: odoo/enterprise#91918

**Issue:**
When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers

**Cause:**
The `partner_latitude` and `partner_longitude` fields were not reset for child contacts when the parent’s address changed

**Fix:**
We added a `partner_latitude` and `partner_longitude` reset when changing address in write
We added `partner_latitude` and `partner_longitude` in the _address_fields to update the value each time it can be required, like on address change or contact creation
The extension in the _address_fields is there to detect the changes on children synchronization, because it only replace the value that where present in vals for the fields in that list
In that way, it will detect more address changes and trigger the write for the children with the corresponding parent `partner_latitude` and `partner_longitude`
We also make sure that those extra _address_fields will not be displayed in the formatted address by removing them from `_formatting_address_fields`

**Limitations:**
One issue remains during import: the parent-child address synchronization is disabled on contact creation
This means children may be created with addresses different from the parent’s and have mismatch positions on Map
This can be corrected by updating or re-importing the parent to trigger synchronization

**Steps to reproduce:**
With Form:
- Add a parent contact company with a valid address
- Add a child contact related to company, with a valid address
- Open the Map View, both address must appear on Map
- Modify the parent address to remove street (make it invalid)
- Check that the child address match the parent one
- Check the Map View, before the fix the child should remain with a wrong position

With import:
Create an import file (an example is in on the ticket)
- Add a sheet for the Parent contact with an valid address
- Add a sheet to add the Child contact with a parent_Id, with a valid address
- Add a sheet to break the address on the parent, removing the street
- Open the contacts app
- Import the valid Parent and Child sheets (you need to select Related Company / External ID)
- Add a filter to get your created contacts
- Check the Map View (You should see both parent and child)
- Import the Break parent sheet
- Check that the child address match the parent one in the Form
- Check the Map View, before the fix the child should remain with a wrong position

A file can be found on the ticket with pre-made data

**Technical notes:**
The reset logic is duplicated from the `base_geolocalize` module, because this module is optional and may not be installed in all cases
Since `base_geolocalize` is not always present, its `write` override will not be triggered consistently

On the other hand, `web_map` is automatically installed with the Enterprise version of Odoo
Therefore, it is necessary to implement this fix in at least one of the two modules to ensure the behavior is active when Enterprise is used

We chose to keep the override in both `base_geolocalize` and `web_map` to cover both Community and Enterprise cases reliably

An alternative approach would be to move the reset logic directly into `res.partner` in the `base` module, making it always available regardless of installed addons and avoiding the duplication

opw-4842910

Forward-Port-Of: odoo/enterprise#92658
Forward-Port-Of: odoo/enterprise#90392

**Issue**:
Importing a SIE4 file without previous year information causes a traceback.

**Steps to reproduce**:
- Go to Accounting > Settings > Import
- Import SIE 4 file
- Check the box "Import account opening balances"
- Select the right xml and observe the traceback

**Cause**:
The method `_prepare_sie4_opening_balance_move` tries to directly access the previous year:
https://github.com/odoo-dev/enterprise/blob/6d4919658650a006c73d4aaf1f500d67723dda0d/l10n_se_sie4_import/wizard/import_wizard.py#L376C9-L376C58
This results in a traceback when the previous year is not present.

**Solution**:
Make `_prepare_sie4_opening_balance_move` more permissive by falling back to the day before the first day of the current year if the `-1` section is not there.

**Additional Notes**:
The client file does not support `UTF8` format, retry with the `ISO-8859-1` format in case of `UnicodeDecodeError`.

opw-4894495

Forward-Port-Of: odoo/enterprise#92174
Forward-Port-Of: odoo/enterprise#89425

[FIX] account_accountant: fix multi_currency payment_widget
To reproduce:
- Make a statement line for partner_a for 200 $
- Make an invoice for same partner for 100 $
- Reconcile it with the statement line
- Duplicate the invoice and post it
=> First issue, you don't see the 100$ left on the statement line
It's still reconciliable

To fix that, we only remove fully reconciled statement lines.

Second issue:
- Have a bank journal in EUR  with a rate of 2
- Make a statement line for 400€ in this journal
- Create an invoice for the same partner of 100$
=> The widget proposes a statement line of 400$ instead of a 200$
equivalent (with the rate conversion)

The issue is that we convert with a foreign_currency_id that is not
present in that case.

To fix both, we change the way we compute the amount to always use
the residual converted from the right currency

[FIX] account_accountant: partial on statement line for invoice widget
To reproduce:
- Make a statement line for partner_a for 200 $
- Make 2 invoice for same partner for 100 $
- Reconcile them with the statement line (via the widget)
- Unreconcile first invoice via the payment widget
=> The second invoice is also unreconciled

To solve:
Only unreconcile the lines that are part of the partial that we want to unlink

Forward-Port-Of: odoo/enterprise#92334
Forward-Port-Of: odoo/enterprise#92005