To reproduce the issue:

1) Create a Belgian company, with CoA installed
2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to generate the French taxes

=> Some of the generated taxes are cash basis. All of them should have a transition account, but it's not the case (some have, some haven't).

This is due to the fact 0% cash basis taxes exist in France, and they are treated before some other taxes due to the order we declare them in in the csv. When creating those 0% taxes, the transition account had to be mapped. Since Belgium does not have any cash basis taxe, we relied on the first account used in the tax repartition of the tax to convert. However, those 0% taxes obviously had no account there (since they're 0% anyway), so we ended up not entering this condition https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L970 and mapping the transition account to None. Because of that, we did not create any equivalent for that account, for any of the taxes using it.

This commit solves that by sorting the tax templates to first treat those with accounts in their tax repartition.

We also fix here the fact that instantiating such cash basis taxes did not enable the "cash basis" setting on the company ; which didn't make any sense, and caused an error message when trying to edit the settings afterwards.

Forward-Port-Of: odoo/odoo#210070

Steps to Reproduce:

1. Go to the To-do module.
2. Create a link.
3. Select the entire content using Ctrl + A.
4. Change the font style from 'Normal' to another (e.g., 'Header 1').
5. A traceback is thrown, although the link’s font style is changed.

Description of the issue/feature this PR addresses:

- The issue was caused by the presence of a `FEFF` (zero-width no-break space) character inside the selected text. This caused a conflict during selection restoration after the font style change. The clean handler was being triggered after the font change attempt, which led to an invalid cursor state.

 Current behavior before PR:
- A Traceback occurred when changing the font style of a selected link text.

Desired behavior after PR is merged:

- The clean handler is now explicitly called before the font change tries to restore the cursor, avoiding the invalid range or selection error.

task-4743390

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

Forward-Port-Of: odoo/odoo#207202

When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt:
- An Exchange diff account move would be created, and the Stock Input Account would not be balanced

This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rate journal entry is created, and a discrepancy in the Stock Input Account balance is introduced.

When the bill is posted before the receipt is validated, we want the receipt to have the value of the bill, and there is no reason to have only the balance or the amount in currency from the bill, so we can take both of them.


https://github.com/user-attachments/assets/c6dc5e72-8f5b-4c0f-99fa-c5e98a9574ff


## How to reproduce:
- Install stock_account,purchase
- Create product P:
    * Valued in AVCO automated.
    * Control Policy to 'On ordered quantities'
- Add currency rates for the EUR currency:
    * 2.0 on the 2025-01-01
    * 2.1 today
- Create and Confirm a new purchase for 1 unit of P and a price of 100 Euros
- Create the Bill:
    * Set the bill's accounting date & bill date to the 2025-01-01
    * Confirm the bill
          => Amount in Currency: 100 Euros - Balance: $50 USD - Rate used: 2.0
- Go back to the PO and receive the product.
          => Amount in Currency: 105 Euros - Balance: $50 USD - Rate used: 2.1
- Check the created Journal Entries:
          => Currency exchange rate difference: $2.38
          => (105 - 100) / 2.1

OPW-4631348

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

Forward-Port-Of: odoo/odoo#210182
Forward-Port-Of: odoo/odoo#209118

Description of the issue/feature this PR addresses:
The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually available due to rounding. For example in the following case:
Product-A is made via Kit-BoM from 2 Units of Product-B. There are 3 units of Product-B in stock. The precision of the "Unit" UoM, used for Product-A, is set to 1 (only integer amounts). The actual amount of units available is 1.5, this is rounded as Half-Up to 2 Units. This is misleading, since only one unit of Product-A could be shipped.

Current behavior before PR:
For Kit-BoM Products, the quantities in _compute_quantities_dict() are all rounded with HALF-UP, potentially rounding up and claiming a higher availability than actually supported.

Desired behavior after PR is merged:
_compute_quantities_dict() rounds down to ensure it doesn't over-promise.



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

Forward-Port-Of: odoo/odoo#208575
Forward-Port-Of: odoo/odoo#208374

When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder.

Steps to reproduce:
-------------------
* Create 2 products, one with a cost of 20 and one with a cost of 0
* Create a PoS order with 2 lines, one for each product
* Validate the order using the shiplater option
* Close the session and go to the picking created
* Validate the delivery only for the product with a cost of 20 and make a backorder for the product with a cost of 0
* Go to the session accounting entries and check the COGS entries, you should see one entry for the product we just processed
* Validate the backorder
> Observation: A second COGS entry is created for the product with a
  cost of 20

Why the fix:
------------
Instead of creating the COGS entries based on the PoS order lines, we now create them based on the stock move lines. This way, we only create the COGS entries for the stock move lines that are actually processed. We also avoid creating COGS entries for the stock move lines that have no cost.

opw-4597430

Forward-Port-Of: odoo/odoo#210435
Forward-Port-Of: odoo/odoo#207075

- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment.
- Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account.
- Make a purchase using the `"demo"` payment method with the new partner.

The generated invoice and its corresponding journal entry do not share the same `account_id` (Account Receivable).

The invoice uses the `account_id` computed in `_compute_account_id` of `account.move.line`, which is not necessarily the same as the `account_id` set on the partner.

After this commit, the payment uses the same `account_id` as the related invoice, (same as _create_payment_vals_from_wizard)  avoiding any discrepancy.

opw-4669927

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#209318
Forward-Port-Of: odoo/odoo#204489

**Issue**
For example, in the case of a working schedule from 8:00 to 17:00 with
a 1 hour lunch period, 8 hours of work are expected. By taking the
lunch interval into account, the auto check out will happen at 17:00
if the company's tolerance in the attendance's setting is set at 0.
Previously, it would happen at 16:00, resulting in only 7 worked hours
for the attendance while the user may expect the attendance's worked
hours to match the expected working hours of the schedule.

**Solution**
- include lunch attendances (not taken into account by `duration_hours`)
in the total time that needs to be exceeded before an `hr.attendance` is
automatically checked out.
Note that this solution manages the case where `hr.attendance` are outside
lunch periods (e.g. 8-12 and 13-17, but no attendance between 12-13). Though
in that case, the automatic check out will be delayed by at least 1h.

Note: a change was also made to account for 2 weeks calendars.

opw-4402321

Forward-Port-Of: odoo/odoo#197395

Steps to reproduce:
- Install accounting, Sales apps
- Setup two companies for the current user with two diff currencies
- In company A, make a SO on a product and create an invoice
- Validate and confirm the invoice.
- Go to accounting, reporting, invoice analysis, and add group for the product
- Select the report of that specific invoice posted
- Observe the values untaxed_total, avg_price, inventory_value and price_margin
- Switch to company B, and add a currency rate between both currencies to observe a difference
- Make sure that you are selecting both companies, but B as the main company
- Go again to the report of the same Invoice.
- Observe the values again.

Issue:
When changing the currency, the fields untaxed_total and
price_avg are updated using the currency rate of the current
main company. However, inventory_value is not updated.

This inconsistency affects the calculation of price_margin,
which relies on both untaxed_total and inventory_value.
As a result, price_margin is computed incorrectly.

opw-4582973

Forward-Port-Of: odoo/odoo#210453
Forward-Port-Of: odoo/odoo#206582

Versions
--------
- 17.0+

Steps
-----
1. Create a coupon that grants a discount;
2. add a second reward giving free products;
3. use a product tag to turn it into a multiproduct reward;
4. save program, generate coupons, and copy a code;
5. add the free product tag to two or more products;
6. go to eCommerce;
7. add any product to cart and go to checkout;
8. apply coupon code;
9. claim a reward.

Issue
-----
- Claiming a free product results in a traceback.
- Claiming the discount does not apply the discount.

Cause
-----
Commit db3ffae3ef5a5 modified the reward claiming logic to allow for multiproduct rewards, but overlooked the possibility of the program having multiple rewards, multiproduct being one of them.

It therefore passes all of the coupon's rewards to `_apply_reward`, which only expects a single reward.

This is also a consequence of commit 6525d5fba40c, which moved part of the `claim_reward` logic to `pricelist`, without passing which reward was claimed to `pricelist`.

Solution
--------
Add an optional `reward_id` parameter to `pricelist`, letting it know which reward we intend to claim.

opw-4778945

Forward-Port-Of: odoo/odoo#210214
Forward-Port-Of: odoo/odoo#209610

The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by [[1]](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e), where the scroll handling was moved out of `div#wrapwrap`, which inadvertently affected the positioning of notifications.

Steps to Reproduce:
- Install `website_sale` and enable the 'Add to Cart' button from the website editor on the `/shop` page
- Navigate to the shop page and scroll to the last product
- Add the last product to the cart
- The pop-up does not appear unless you scroll back up

Issue:
- The add to cart pop-up is not visible when the user is scrolled down on the page

Root cause:
- The CSS class `position-absolute` restricts the pop-up to a specific location in the scrollable content

Fix:
- Replace `position-absolute` with `position-fixed` to keep the pop-up visible regardless of scroll position

opw-4686886
Affected version - 18.0

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

Forward-Port-Of: odoo/odoo#208973

When user tries to open accrued expense entry in purchase order,
A traceback will appear.

Steps to reproduce the error:
- Install ``accountant`` and ``purchase`` module
- Create a new Bill > Add a line > Don't add a product > Save >
  Purchase matching > Select your bill > Add to PO > Add Down Payment >
  New PO will be created
- Actions > Accrued Expense Entry

Traceback:
```
AssertionError: precision_rounding must be positive, got 0.0
```

https://github.com/odoo/odoo/blob/834eff6e770280e911bb99e2abab4ea42d4ca8ff/addons/account/wizard/accrued_orders.py#L170
Here, when ``is_purchase`` is true, ``is_downpayment`` will not be evaluated.
As a result, down payment lines in purchase orders are not excluded.
Since down payment lines do not have a ``product_uom``.
so ``rounding`` will be 0.0
So, it will lead to the above traceback.

sentry-6576645089

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

Forward-Port-Of: odoo/odoo#208254

1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine),
2. Modify it using the quote calculator,
3. Duplicate it,
4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do),

Expected behaviour: the quote calculator spreadsheet is duplicated for the new quote with the same values.

Implementation note:
Why not just `copy=True` on field `spreadsheet_ids`?

Because the spreadsheet should be copied, but not only! The `spreadsheet.revision` linked to the spreadsheet also need to be copied.

If they are not copied, revisions which are not part of the last snapshot will be lost on the new spreadsheet record and it won't lead to the same spreadsheet data.

Task: 4801418

Forward-Port-Of: odoo/enterprise#85746

## Description

This PR fixes several issues related to comments in spreadsheet cells:

- **Dark Mode Styling**  
  The comment styles were broken in dark mode because the dark SCSS file was in the wrong asset bundle. It's now removed from `assets_backend` and added to `assets_web_dark` to fix the issue.

- **Focus Issue When Using Keyboard**  
  When using the keyboard to move around the spreadsheet, opening a comment popup would focus the composer, stopping navigation. The composer now doesn’t take focus, so keyboard navigation keeps working smoothly.

- **Upload Button & Error Fixes**  
  - The upload button was showing for spreadsheet cell comments but didn’t work. This was caused by missing allowUpload checks in composer actions. The condition is now correctly handled, and the upload button is hidden where it’s not applicable.
  - There was also an error when editing a comment because `this.thread` wasn’t always available. Now it falls back to `this.message?.thread` when editing the message.

- **Popover Visibility Fix**  
  When posting the first comment and hovering over it, the action buttons (edit, favorite, delete) were partly cut off. This is now fixed by adding some padding to the thread style.
![image](https://github.com/user-attachments/assets/da774829-9fac-4ae0-a91a-6381c2404471)




**Task**: [4708400](https://www.odoo.com/odoo/project/2328/tasks/4708400)

Forward-Port-Of: odoo/enterprise#84334
Forward-Port-Of: odoo/enterprise#83410

**Steps to reproduce:**
- Install Planning app
- Set the type of view to Gantt
- (Create a shift if there is none)
- Click on `Publish` button
- The period end date doesn't take the last day into account (time is 00:00)

**Issue:**
Gantt model default `_buildMetaData` computation behavior was changed multiple times during previous refactoring:

Previously used:
```
export function computeRange(scale, date) {
    let start = date;
    let end = date;

    if (scale === "week") {
        // startOf("week") does not depend on locale and will always give the
        // "Monday" of the week... (ISO standard)
        const { weekStart } = localization;
        const weekday = start.weekday < weekStart ? weekStart - 7 : weekStart;
        start = start.set({ weekday }).startOf("day");
        end = start.plus({ weeks: 1, days: -1 }).endOf("day");
    } else {
        start = start.startOf(scale);
        end = end.endOf(scale);
    }

    return { start, end };
}
```
Which became:
```
export function getRangeFromDate(rangeId, date) {
    const startDate = localStartOf(date, rangeId);
    const stopDate = startDate.plus({ [rangeId]: 1 }).minus({ day: 1 });
    return { focusDate: date, startDate, stopDate, rangeId };
}
```

**Fix:**
Added `localStartOf` function in the context setup of PlanningGanttModel.

To avoid overwriting current changes for other modules (which could be intended), this was done instead of :
```
export function getRangeFromDate(rangeId, date) {
    const startDate = localStartOf(date, rangeId);
    const stopDate = localEndOf(startDate, rangeId);
    return { focusDate: date, startDate, stopDate, rangeId };
}
```

related commits:
https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6 https://github.com/odoo/enterprise/commit/c175a848369057cc69596737dcd9d21dd24c9d5c

opw-4580458

Forward-Port-Of: odoo/enterprise#85608

The tours fails because when we edit the value in the input field of customer it
clicks on the field and then fills out the value and then a change event is
propagated and text based autocomplete results are shown (and m2o fields with
partner autocomplete wizard are a tad bit slower), after that tours moves to
next step and the new result dropdown menu is not loaded and it gets its
reference from older menu which got closed in between and tries click it and no
change is reflected but the new menu is not closed and tour continues to
industry_fsm_report where we create a worksheet from a many2one field using
create and edit so we click on the m2o input and wait for options but as partner
field loaded dropdown is loaded it clicks on click and edit trying to create a
new partner and opening thus fails the tour.

Fix:

- After entering the text to instantly load the dropdown by clicking on it and
give time for loading of menu.

task-4800194

Forward-Port-Of: odoo/enterprise#85622