**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#104686
Forward-Port-Of: odoo/enterprise#103333

_
## 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.
note: the issue doesn't persist in 19.0, forwarding the tests.
__
opw-5136861

---

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

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.

Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).

Error:
```
  File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
    cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
  File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
    record.ensure_one()
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```

Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.

Solution:
- Made the fields read-only via XML to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records. (for existing DBs that might have changed payment method codes).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.

[PR]: https://github.com/odoo/enterprise/pull/38046

[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423

sentry-7171030995

Forward-Port-Of: odoo/enterprise#104914
Forward-Port-Of: odoo/enterprise#103944

**Steps to reproduce:**
- Create a portal user
- Go to the documents app
- Click on the marketing folder
- Share the marketing folder through a link (Anyone with a link = viewer + discoverable)
- Copy the share link
- Login with the portal user in an incognito window
- Paste the share link in an incognito browser
- Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture
- Click on "brand 2"
- Click back on "brand 1" and now the folder and picture are visible
- If you click on a subfolder of "brand 1" you also get an error

**Issue:**
Discoverable subfolders accessed using `accessToken` are not available on
the first read of a user and this happens for each level of the
hierarchy (refresh is needed each time).

When using sharing link to display folders with a user,
the subfolder document access is created on `/documents/touch/` using
`_from_access_token`.

But on the js side the call is delayed (with debounce) and occurs after
the `web_search_read`. This means that subfolders are only accessible
after a refresh or by switching back and forth between folders.
Also, even after the folder is displayed, if there are other subfolders
in it, going deeper in the hierarchy won't work as well without a refresh
due to the `search_panel_select_range` missing the new folder.

**Fix:**
Not sure on the best way to fix this, the issue will always be related to
performance. Current fix checks if a reload is needed by sending a flag in the
`/documents/touch/<access_token>` request result when a new document
access was created.

opw-5156297

Forward-Port-Of: odoo/enterprise#104585
Forward-Port-Of: odoo/enterprise#99820

**Description of the issue/feature this PR addresses:**

Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time.

Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events.

**Current behavior before PR:**

Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer:
	•	the synchronization fails,
	•	and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo.

**Desired behavior after PR is merged:**

The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`.

If the parameter is not set, the behavior remains unchanged (default 3 seconds).
Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs.


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

Forward-Port-Of: odoo/odoo#245022
Forward-Port-Of: odoo/odoo#241921

Issue before this commit:
=========================

The high-priority maintenance request count (todo_request_count_high_priority) 
was not calculated correctly.

Steps to Reproduce:
=========================
- Install the maintenance module.
- Create a maintenance request and set the Priority to High (3-starred) in the form view.
- Open the dashboard.
- Observe that the high-priority request count is not displayed.
- The count always remains 0, even when high-priority requests exist.

Cause of the issue:
=========================
In this [PR](https://github.com/odoo/odoo/pull/94866), the logic was mistakenly changed. 
The priority field is defined as a Selection field, but while computing the count, the comparison 
was done against an integer(3, not '3') instead of the actual string value. Since the stored 
value is '3' (string), the condition is always evaluated to False, resulting in a count of 0.

With This Commit:
=========================
Ensure that high-priority maintenance requests are correctly counted and displayed on 
the dashboard when they exist. This provides better visibility of critical requests and
helps users prioritise maintenance work effectively.

Forward-Port-Of: odoo/odoo#244987

**Steps to reproduce:**
- Create a storable product "P1"
  - Product category: AVCO

- Create a purchase order with 100 units of P1 at $10
- Confirm the PO and validate the receipt
- Go to Inventory -> Reporting -> Stock

- P1 unit cost is $10 and total value is $1000

- Click on $1000
  - Select the first stock move
  - Action -> Adjust valuation
    - New value: $2000 -> Save

- Go back to Inventory -> Reporting -> Stock

**Problem:**
- The unit cost becomes $2,000 and the total value $200,000

When a valuation adjustment is made on an AVCO product, a `product.value`
record is created with the new total valuation value.

However, `product.value.value` can represent two different things:
- for a standard price update, `value` contains the new unit cost
- for a stock move valuation, `value` contains the total value of the move

When `run_avco` processes a `product.value` coming from a move valuation,
it incorrectly treats the value as a unit price and multiplies it by
the quantity

opw-5460829

This PR fixes the bug of not making the source location persistent when changing it from the form view.

To reproduce the bug:
1- Create a product tracked by lot.
2- Create 3 different lot locations with each having a quantity of 100. 
3- Create an out delivery of 140 and notice 100 are assigned from the first lot and 40 are assigned from the second lot.
4- Set the scanning source location to be mandatory in Barcode for deliveries.
5- Go to Barcode app, navigate to the delivery, you find it mandatory to scan a source location.
6- Scan the source location for the first lot location, choose the product and click on the edit pen icon.
7- Choose another lot location as your source location, let it be the third lot location and confirm.
8- Choose to assign the qty by clicking on the +100 button.
= See that the new chosen source location is not persistent.

The fix:
After this PR, if you follow the steps up to step 7 and after you confirm your new source location, the Barcode makes the lines inactive again and asks you to scan the source location (since it's mandatory) and it also shows the new source location on the line.

Another fix this commit addresses is that when you scan a source location, only the lines with this location are active to choose/edit not all the lines.

Task-4809491

### [FIX] mail: properly handle col overflow in bootstrap row
Problem:
The grid conversion logic only finalized a row when iterating through the
last column in the input list. If a row reached exactly 12 grid spans
while more columns remained (e.g., a `col-12` in the middle), the logic
did not start a new row. As a result, remaining columns overflowed the
current row visually.

Cause:
In a single row, if a column had a size 12 and was followed by another column of
any size, it would crash because the algorithm did not reset the index to the
start of the next row.

Steps to reproduce:
- Add a Marketing block.
- Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" />
- Save.
- Traceback.

### [FIX] mail: ensure -md variant of col and offsets are prioritized
Prior to this commit, if an element had a mix of `col-x` and `col-md-y` classes,
the regexes used in `convert_inline` would not guarantee that they would be used
consistently.

How to reproduce:
- create a new mailing and add the "three columns" snippet
- resize from the right the middle column (reduce the size and revert back to
  the original size)

Issue:
- when sending the email, the columns are not aligned horizontally in a desktop
  layout

Solution:
Prioritize usage of `-md` variants to compute the size of a column/offset, when
available (these are the one used by the mass_mailing editor for desktop mode),
and use any otherwise.

opw-5439481

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>
Co-authored-by: Walid Sahli <wasa@odoo.com>

Step to reproduce:
- install `l10n_it_pos`
- setup Italian fiscal printer for a pos
- refund a order and print receipt

Observation:
receives a traceback
```js
Caused by: TypeError: ctx.this.order.getRefundInfo is not a function
    at Header.template (eval at compile (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:16388:20), <anonymous>:11:62) (/web/static/lib/owl/owl.js:5807)
    at Fiber._render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12364:38) (/web/static/lib/owl/owl.js:1783)
    at Fiber.render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12356:18) (/web/static/lib/owl/owl.js:1775)
    at ComponentNode.initiateRender (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:13036:23) (/web/static/lib/owl/owl.js:2455)

```

Cause:
- A <Header/> component is used in invoices, which requires a method `getRefundInfo`.
- commit [1]  removes <Header> and its related files,
- commit [2]  removes dead code, hence removed `getRefundInfo`
- commit [3] brings back <Header>, but the method was not reintroduced

[1] https://github.com/odoo/enterprise/commit/3d532f6ee99884bce58a577eb68464e670fb059a
[2] https://github.com/odoo/enterprise/commit/1b03fe15916b7b86f79efcbb63895ae0c4363ef9
[3] https://github.com/odoo/enterprise/commit/d745a72e3f43febb3b39054dc9315eca13d86e36

Fix:
- Add the method back

After fix: 
**image from simulator**
<img width="600" height="300" alt="image" src="https://github.com/user-attachments/assets/f6caccca-caf6-477f-bf37-f942090535cc" />


opw-5485350

This PR fixes 2 bugs in self order when we are dealing with variants.

The first bug in commit https://github.com/odoo/odoo/commit/0cd3a64955052b7fb5507f8fbb3414e0a894250d
The order pricelist_id was not taken into accounting when adding a line corresponding to a product variant. So any price rules acting on the variant, that are specific to the current pricelist, will not be applied.

The second bug in commit https://github.com/odoo/odoo/commit/77dbf4b2cf1b1dea3bb5ba107da83e13e5283afb
The product page was displaying the price of the default product, instead of that of the selected variant.

A third commit https://github.com/odoo/odoo/commit/bf2e3d90e3f3405db9be78acfdf2558bf47b449a was to fix `price_extra` calculations and make it consistent between the product page and the rest of the app.

I have included the steps to reproduce and more details about the fixes separately in each commit.

However, the reproduction steps are the same:
1. Make a product with 2 variants, size S and M for example.
2. Create 2 pricelists, A and B, and make them available in PoS. The
   default one should be A.
3. For the created product, create 2 price rules:
    1. One changing the price of the variant S for the pricelist B
    2. One changing the price of the variant M for the pricelist B
4. Enable mobile self order and create a peset that applies the
   pricelist B
5. Open self order, and select that preset (it should apply the
   pricelist B).
6. Select the product of step 1, and choose the variant M.

opw-5467593

This happens only on Chrome, when switching between two identical t-if/else
structures.

In Odoo's t-if/t-else structures, Chromium may fail to properly update
the selection when switching between two structurally identical elements
via the group switcher.

This happens because Chrome's implementation of the [Selection API](https://www.w3.org/TR/selection-api/#selectionchange-event)
contains an optimization that suppresses the 'selectionchange' event if the
new Range has the same logical coordinates (Node type and Offset) as the
previous one, even if the underlying DOM node reference has changed.

This can break editor commands such as `/table` or `/field` like in the
following steps:

Steps:
- Install `sale_management` and `web_studio`
- Open report editor on PDF Quote
- Add a new column to the left in the table
- Click on the table body
- Select `t-else` in the group switcher
- Click again at the same place
- (Here the selection is not correctly set by chromium)
- Try to use `/field` to add a field
- It will not work as field selector doesn't have the right selection
You can use this [video](https://drive.google.com/file/d/1ua7nlla7km1_l-wqgL8zeHaM-tFLA9jJ/view) to reproduce it easily 
or you reproduce it [here](https://stackblitz.com/edit/javascript-v65edaq5?file=index.html,index.js)
If you click after the “1” and then after the “2,” you will see that
Chromium does not fire the selectionchange event, whereas Firefox does.

This commit fixes this by adding a "removeAllRanges()" to force Chrome to
"forget" the old range. This ensures that the next selection is correctly
treated.

opw-5219989

### Issue:
Due to this issue, by clicking twice on `Reward` button on SO, reward line unit price will be reset to zero.

#### To reproduce:
1- Create a `Buy X Get Y` program:
   rule: minimum quantity: 3, product: `Large Desk Wood`
   reward: 1 `Large Desk Wood` for free
2- Create a SO, and add a line with 3 `Large Desk Wood`
3- Click on `Reward` button. A new line should be automatically
   created. The unit price should be the product sale price and
   line `Amount` should be 0.
4- Re-click on reward. The reward line price unit is set to zero.

Expected: The reward line price unit should remain as product sale price with a discount of 100 and line.amount of 0.

### Cause and Fix:
In `_reset_loyalty`, price_unit is set to zero.
The method `compute_amount` depends on `price_unit`, which means setting `price_unit` will make amount to be recomputed: https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L843-L844 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L848 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/account/models/account_tax.py#L1613

Which leads to `_compute_price_unit`. In this compute, the unit price will not be recomputed if `technical_price_unit` and `price_unit` differ.
https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L606-L611 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L588-L595

So IMO if we want to recompute `price_unit`, we need to also reset `technical_price_unit` in `_reset_loyalty`.

opw-5467623

### Issue:
The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders
This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid

### Cause:
In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir`

### Fix:
After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value
All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank

### Steps to reproduce:
- Install `l10n_mx_edi` and switch to the MX company
- Create an invoice with today’s invoice date
- The payment policy is set to PUE
- Before the fix, the payment method is set to `Por Definir`

For Sale Order and POS Order tests, it's the default value as soon as you create an order

opw-5406038

Forward-Port-Of: odoo/enterprise#105058
Forward-Port-Of: odoo/enterprise#104164

Steps:
- Create a price list (or existing one)
- Create (or find) a product with only one variant
- Add price list rule for that variant (Should show as Variant:... in Pricelist listing)
- Go to the pricelist listing, select the pricelist
- Edit price list rule - Remove the product
- Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id)

(Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view)

Description of the issue/feature this PR addresses:
Fix corrupted data
<img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/db5e9f27-d004-4bce-875f-0512fba193d9" />

Current behavior before PR:
product_tmpl_id set to None
product_id / applied_on data stays the same

Desired behavior after PR is merged:
When product_tmpl_id is removed, reset the applied_on type back to 3_global

Reference:
opw-5411034

Affected: 18.0, 19.0, 19.1

Confirmed with Pricelist's PO: BOJE


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

**Description of the issue/feature this PR addresses:**
In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is not called. Instead, the ORM falls back to the field’s default domain and returns all `chatbot.script.answer` records, including those from other scripts. When a value is entered, `_search_display_name` is triggered and the results are filtered correctly.

This behavior changed after PR #201587, where the `operator_optimization` step started executing before `determine_domain`. Since `determine_domain` is the step that triggers `_search_display_name`, it no longer gets called when the domain `('name', 'ilike', '')` is stripped by `operator_optimization`. Therefore, filtering only works when a non-empty filter value is provided.

**Current behavior before PR:**
All `chatbot.script.answer` records are shown in the `triggering_answer_ids` dropdown when no search value is entered, even if they don’t belong to the current chatbot script.

**Desired behavior after PR is merged:**
The `triggering_answer_ids` dropdown only shows answers belonging to the current chatbot script, regardless of whether a search value is entered.

task-[4968490](https://www.odoo.com/odoo/project/1519/tasks/4968490)

Forward-Port-Of: odoo/odoo#245322
Forward-Port-Of: odoo/odoo#228192

### Issue:
When a product has multiple attributes and one variant is archived, the product page may appear grayed out and the product cannot be added to the cart.

#### Steps to reproduce (with demo data):
1- Create a product with two attributes:
   - attribute with 3 values
   - Brand: Adidas

2- Save product to generate variants. Publish the product.
3- From variant list, archive the first variant
4- Back in product page, from attributes & variants tab, remove
   the first value. This sets `ptav_active` to False.
5- Navigate to website shop page, and add the Brand Adidas to filter
6- This should show the created product active.
7- Open the product. You will see the product is grayed out and it's
   shown inactive and cannot add it to the cart.

### Cause:
In this scenario, `attribute_value_ids` only contains values from the single-value attribute:
https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L814-L824

For the multi-value attribute, no ptav matches `attribute_value_ids`, so the code falls back to selecting the first ptav: https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L823

If this ptav corresponds to an archived variant, the resulting combination resolves to an inactive product.

### Fix:
Ensure the fallback logic only considers active ptavs, preventing archived variants with prav inactive from being selected.

opw-5352224

### Steps to reproduce:

- In the settings enable By-Products
- Create a product with an color attribute and 2 values: white, black
- Create a bom for that products and add 2 by product lines:
    - 1 x comp1 with a cost_share of 50% specific to the white att-value
    - 1 x comp2 with a cost_share of 70% specific to the Black att-value
#### > Try to save and you will raise a UserError: The total cost share for a BoM's by-products cannot exceed 100.

### Expected behavior:

The error should not be raised as the total cost_share is 50% for the white variant and 70% for the black one but none of them exceeds the 100% cost share.

### Cause of the Issue:

Currently the constraint does not take attribute values into accounts and simply sums the value of the cost share of all by-product lines: https://github.com/odoo/odoo/blob/bcc1397c7d694dbe61ecbd44d0320b9518df84cb/addons/mrp/models/mrp_bom.py#L201-L202

### Fix:

Just as for the total cost_share on kit products, we rely on the exclusion util and check for each existing product variant if the cost share set up is valid:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/purchase_mrp/models/mrp_bom.py#L20-L23 see 3832793e3ce61aff0c7cf4673de84645a3469b3a

opw-5499773


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

**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

Forward-Port-Of: odoo/odoo#236536