**Steps to reproduce:**
1. Install the `Accounting` module.
2. Enable cash basis taxes in
   `Accounting → Configuration → Settings → Taxes → Cash Basis`.
3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a
   `Cash Basis Transition Account`.
4. Create an invoice with the cash basis tax and a payment term such as
   `30% now, balance in 60 days`.
5. Record a full payment on the invoice instead of just the first installment.
6. Review the generated cash basis journal entries.

**Observed behavior:**
* Cash basis entries are created for the full tax amount, not proportionally.
* Paying the full invoice with payment terms causes duplicated tax entries.

This came from the fact that we didn't consider a move would be fully paid by
several lines at the same time, like with installments.

We now only put the leftover amount when the move is fully paid and we're on
the last partial.


Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches

opw-5061136




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

On the iot box we check the number of printers connected rarely to avoid spamming the network.
This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface.
The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box.

However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds.
Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects.
The user in pos can then press "retry" which will lead to a double printing.


This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups.
Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed.
The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected

Forward-Port-Of: odoo/odoo#244076

## [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

Forward-Port-Of: odoo/odoo#232147

****Behavior:****
When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs.
This occurs because approving a leave creates a resource.calendar.leave linked to the hr.leave, and when refusing it, the system will try to unlink it.
https://github.com/odoo/odoo/blob/72e8a29dd0edb0ca3d464142ce869f38f96c730a/addons/hr_holidays/models/hr_leave.py#L896-L901

According to access rules of r.calendar.leaves, Time-off Responsibles are not allowed any access for entries of other employees.
Approving them doesn't cause an error because the create operation uses sudo(), assuming that the user must have had valid rights to access the function. This is not the case for the unlink.

**Solution:**
This fix checks wether the user has write access to the related hr.leave record, then uses sudo().
The idea is that if they are allowed to modify the state of the leave, they can refuse the leave, and therefore should be able to go through the following operations.
This is in a similar fashion as the behavior for approving the leaves.

****Steps to Reproduce:****
- Create a Leave Type that requires validation from a manager, and assign one to an employee.
- Remove any access rights to Time-Off for the user, but leave Time off Responsible checked.
- Assign the user as time-off responsible for the employee
- Log in as the user and approve the leave
- When refusing the leave, you should get an access error.

opw-5178783

Forward-Port-Of: odoo/odoo#238205

Problem:
When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines.

Solution:
We will convert the component cost to the invoice currency when computing price difference.

Steps to reproduce (runbot 18):
- Product with
	- Standard price auto
	- BoM: sbc, one component with nonzero value (e.g. $1)
	- Nonzero value (e.g. $5)
- Another currency
1. Create a PO for the subcontracted product
2. Set the Invoice currency to something other than the company default
3. Confirm the PO and validate the sbc and receipt
4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency)

A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference.

opw-5232917

Forward-Port-Of: odoo/odoo#243801
Forward-Port-Of: odoo/odoo#238428

[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export

Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data.

Steps to reproduce:
- Install `l10n_ma_reports` and switch to the MA company
- Create and confirm a bill:
	Bill Date: 10/01/2025
	Vendor: Azure Interior
	Invoice Lines: Price 100, Taxes 20% (S 140)
- Go to `Bank Reconciliation`
- Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo)
- Select the transaction and the invoice, then click Validate
- Open the Tax Return for November.
	Section D should show data linked to the created invoice
- Export the XML using the Gear → XML
	The created bill is missing in the XML and others may be present, showing inconsistent data

opw-5002779


[IMP] l10n_ma_reports: call the report to compute the prorata value

Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file.

Forward-Port-Of: odoo/enterprise#104619