**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#101620

_
## Short functional explanation of the error
When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly.

## Reproduction Steps
1. Go to attendances.
2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes.
3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12.

### Expected behavior
As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed.

### Unexpected behavior
12 minutes of overtime are computed.

## Origin of the issue
Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time.

Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code.

note: the same bug exists for the employee tolerance time, which
is corrected in this commit.
__
opw-5136861

---

Forward-Port-Of: odoo/odoo#244186
Forward-Port-Of: odoo/odoo#242517

## [FIX] website: add versioning for GallerySlider interaction
    
    The GallerySlider interaction (and its edit mode counterpart) is not up
    to date: the logic is still written for old snippets (before [9042b1c],
    so before 18.0).
    
    In the meantime, the pagination for the indicators was lost, meaning
    that if you add too many images, the indicators will have less and less
    space.
    
    Steps to reproduce:
    - Drop an Image Gallery snippet
    - Set the indicators to squared or rounded miniatures
    - Add 15 or more images
    => All the indicators are crammed into the same line.
    
    With this commit, we deprecate the old `GallerySlider` interaction and
    create a `GallerySlider001` for the snippets dropped since 18.0.
    For the indicators, instead of a pagination, we now use a horizontal
    scrolling container which centers on the active indicator.
    
[9042b1c]: https://github.com/odoo/odoo/commit/9042b1c 

## [FIX] website: preload available carousel images
    
    As images are lazy loaded, it means that in the context of a carousel or
    an image gallery, they only start loading once the user clicks either on
    its indicator or on the previous / next button (or after completing an
    auto-slide). While Chrome seems to optimize that to make it seemless, on
    Firefox this causes the carousel slide to appear blank for a moment
    before the image suddenly pops up, as the sliding animation arrives to
    its end.
    In effect, this causes a flicker and a feeling that the carousels, and
    especially the gallery, is extremely laggy.
    
    To mitigate that while trying to keep the advantages of image lazy
    loading, this commit partially backports [08d837e], which loads the
    images of the next and the previous carousel items.
    
    Additionally, we prefetch the target images on pointerdown / keydown on
    an indicator. That may seem like too small of a difference to be
    interesting, but it actually gives a little bit of time between the
    pointerdown and pointerup (which triggers the slide event) to start
    loading the images, which with a correct connexion already goes a long
    way towards mitigating the laggy feeling.
    
[08d837e]: https://github.com/odoo/odoo/commit/08d837e70f28a84a9bd97974f5d15d387a42b7c0
    
task-5245513

**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Forward-Port-Of: odoo/enterprise#99936

**Description of the issue/feature this PR addresses:**
This PR adds the AFIP document type 110 - CREDIT NOTE TICKET, which is required for the Argentinian localization

**Current behavior before PR:**
When users in Argentina tried to create a credit note for a ticket, the corresponding document type was not available as an option.

**Desired behavior after PR is merged:**
After this change, users can now select "110 - CREDIT NOTE TICKET" to issue the document correctly.

[HERE](https://app.screencastify.com/watch/fVBWwSD6DAcodKO57qUZ) is a video replicating the issue
1) In localization Argentina, check document types and see that 110 CREDIT NOTE TICKET exists
2) Create a new journal as shown in the video
3) Create an invoice selecting that journal, and (83) TICKET as Document Type
4) Confirm the invoice and try to create a credit note. See that (110) CREDIT NOTE TICKET does not appear as an option

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#228256