The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced over time.

## How to reproduce
- Create product P, storable, tracked in Kg
- Create a receipt/delivery move for 14g of P -> Stock Quant is updated by 0.01Kg
-> Stock Valuation is updated by 0.02Kg

OPW-4734980

---

Test result without fix:
```
2025-04-22 13:40:45,088 38626 ERROR oes_test_16 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_valuation_rounding_method
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/16.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 4397, in test_valuation_rounding_method
    self.assertEqual(receipt.move_ids.stock_valuation_layer_ids.quantity, 0.01)
AssertionError: 0.02 != 0.01
 ```

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

Forward-Port-Of: odoo/odoo#207821
Forward-Port-Of: odoo/odoo#206884

Steps to reproduce:
Using POS configs in french company with l10n_fr_post_cert module installed.
- Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient time for payment.
- Cash desk 2: Prepare an order
- Cash-desk 1: Start order payment.
- Cash-desk 2: Start order payment while cash-desk 1 is still paying.

Issue:
When writing 'paid' in a pos_order the l10n_fr_post_cert sets the l10n_fr_pos_cert_sequence_id field. A competition error occurs on cash desk 2 during payment: could not obtain lock on row in relation “ir_sequence”. The odoo.service.model retries to create the order and since the ir_sequence of pos_config used in the pos_order name is not set to "no_gap", the pos_order names have a gap equal to the number of retries.

Task-4708543

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#207852
Forward-Port-Of: odoo/odoo#205935

## Version:
18.0+

## Issue:
PDF quotes on multiple pages having only the total table on the last page encounter a display issue. The total table is cut and partially displayed at the bottom of the penultimate page.

## Steps to reproduce:
- Install Sales app;
- Navigate to the Settings app:
    - Under the `Companies` section, configure the document layout: - Ensure the `Bubble` (or `Boxed`) layout is selected;
- Navigate to the Sales app:
    - Create a new quote with 8x `Chair floor protection`;
    - Via the `Actions` gear button, print the `PDF Quote`.

## Cause:
Complete code refactoring for documents layouts styles introduced by https://github.com/odoo/odoo/pull/169512 has probably not been tested on that use case.

## Fix:
<img width="1105" alt="Capture d’écran 2025-04-03 à 10 25 58" src="https://github.com/user-attachments/assets/67bce15e-c5e9-40f8-9fbf-7721afc98ae5" />

opw-4624623
opw-4627809

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

Forward-Port-Of: odoo/odoo#204575

Steps to reproduce the bug:

- Use Edge browser with zoom set to 150% (default zoom on Windows installations).
- On a screen with a resolution of 1920px (and the browser window set to full width).
- Install the Website app and go to the homepage.
- The page is displayed in desktop view.
- Enter edit mode by clicking the "Edit" button.
- The page width becomes smaller than the mobile breakpoint. As a result , the page switches to mobile view: the navbar turns into a hamburger menu, and the layout changes to mobile style.

This should not happen, as the edit mode is designed to remain in desktop view with 150% zoom on 1920px wide screens. The issue is caused by Edge adding a few pixels of border around the browser window, which leads to this problem specific to Edge.

To fix this in the stable version, we reduce the sidebar width in edit mode by 5 pixels to ensure the page stays in desktop view. This change is applied only if the browser is Edge and 150% zoom is used. In all other cases, no changes are made.

This fix is temporary. In the next redesign of the edit mode sidebar, the sidebar width will be adjusted accordingly so that this workaround will no longer be necessary.

Note: The Arc browser has the same issue, but we haven’t fixed it because there’s currently no way to reliably detect it in JavaScript. Since Arc is much less popular than Edge, it’s less critical.

task-4587203

Forward-Port-Of: odoo/odoo#207835
Forward-Port-Of: odoo/odoo#205721

Currently, since we read most data from cache, if an employee right was changed, it is not reflected in the pos.

Steps to reproduce:
-------------------
* Enable "Log in with employees" and set some records for each field.
* Open session, make a sale, close register
* Edit employees configuration, delete one, change rights advanced -> minimal
* Reopen the session
> Observation: The employee deleted is still visible in the list of cashiers
and the employee that has now minimal rights is still having advanced rights.

Why the fix:
------------
When removing rights from an employee it is important to have it reflected as soon as possible.

A possible solution would have been to recompute `last_data_change` when making any modification on the employee rights but this would recompute everything and we lose the performance added by the caching feature.

Instead, by adding the model to `uniqueModels` we ensure that anytime we reload the pos, all `hr.employee` records will be dropped from the indexedDB, which ends up using the data loaded.

https://github.com/odoo/odoo/blob/5d52373b4c9d64968316c4e883d6b49c7cd1d048/addons/point_of_sale/static/src/app/services/data_service.js#L246-L251

opw-4699241

Forward-Port-Of: odoo/odoo#206914
Forward-Port-Of: odoo/odoo#206099

When using an intermediate return location, the delivered qty of a 
returned kit is incorrect

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a location L:
   - Parent: WH
   - Type: Internal
   - Return location: True
3. Create a route:
   - Applicable on: Main warehouse
   - Add one rule:
     - Action: Push To
     - Operation Type: Internal
     - From: L
     - To: WH/Stock
4. Create a kit K
5. Sell and deliver 1 x K
6. Return it to L
   - It will create an internal transfer 
7. Process the internal transfer
8. Open the SO

Error: The delivered quantity of the kit is -1 instead of 0

Step 6, when returning the kit, the push rule is applied and create 
the SM from L to WH/Stock. Since we copy the SM from Customer to L, the
new SM also has the field `sale_line_id` defined.

As a result, step 7, since all SM are done, `moves` contain them 
(the delivery, the return and the internal transfer). We then filter 
them based on some criteria:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L67-L73
But, for `outgoing_moves` (which is actually the incoming ones, the 
name is wrong), since we look at the destination location, both the 
return and the internal SM will match. That's why we will decrease 
twice the delivered quantity. Hence, the bug.

A fix could be to avoid copying the `sale_line_id` field. That being 
said, when looking `sale_stock` side (i.e., same flow with a classic 
product), we don't have any issue because the filters are slightly 
different:
https://github.com/odoo/odoo/blob/418dc0cc3b3aa1ee2abbdb4852d9cd24fba7636e/addons/sale_stock/models/sale_order_line.py#L274-L278
(Here, we need to look at the `incoming_moves`. Again: the name is just 
incorrect on mrp side...)
We see that, for `incoming_moves`, we actually look at the source 
location. This explains why we don't have any issue with a non-kit 
product.

Therefore, the best fix would be to use the same filters everywhere. 
Good news, such a method already exist:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L115-L116
However, using this method might lead to some other issues (among them: 
the override in `sale_subscription_stock` reads a field although the 
method is an `api.model` one). So, let's minimize the diff on stable 
version and refactor the code (use the same filters everywhere) on 
master.

About the filter names, the confusion actually comes from:
https://github.com/odoo/odoo/blob/312572c7b8138a4800350cd7a524a37551a348ef/addons/mrp/models/stock_move.py#L624
There, we should rather talk about positive moves and negatives 
moves, since this method can be used either in a SO flow or in a PO 
one. This explains why, for now, SO sode, an "incoming move" is 
actually an outgoing one. So, on master, another commit will be 
added to also clean that part of the code:
\- Improve the expected filter names in `_compute_kit_quantities`
\- Fix the filter names in `_get_incoming_outgoing_moves_filter`

OPW-4625228

Forward-Port-Of: odoo/odoo#207739
Forward-Port-Of: odoo/odoo#206966

**Current behavior:**
With anglo saxon accounting and real-time valuation, purchasing
a kit product with a BoM that has components whose costs add up
to the exact price of the kit product and that is invoiced on
ordered qty and has avg costing, then billing before receiving
will prevent the reception from being validate-able.

**Expected behavior:**
Can validate

**Steps to reproduce:**
1. Create a kit product with avg costing, invoiced on ordered
qty, and a BoM with 2 components that have a cumulative cost
equalling that of the final kit product

2. Make a purchase for it, invoice -> post

3. Try to validate the receipt -> can't due to attempted
re-reconicilation

**Cause of the issue:**
When validating the receipt, we end up here:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L81-L90
And attempt to reconcile both the original kit product AML from
corresponding to the purchase line as well as the AML for the
component in the stock input account.

But we only will capture 1 exploded component AML in each loop
iteration, so the original kit product AML will not actually be
set `reconciled = True`, so we will also add it to be
reconciled again:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L90

The same thing happens in subsequent calls to
`_stock_account_anglo_saxon_reconcile_valuation()`, except on
a final call for the last component line- if the components'
cumulative cost aligns with the total cost of the kit product
(which it should) then the reconciliation attempt will succeed.

Then here: https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L92
`reconcile()` is called on the already-reconciled AML which will
cause the re-reconiliation error.

**Fix**
Reconcile all the resulting kit AMLs (component AMLs + actual
kit product AML from the bill) together.

opw-4668004

Forward-Port-Of: odoo/odoo#207803
Forward-Port-Of: odoo/odoo#205401

Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id

Actually this is not the case, different upsell order can have a line that have the same parent.

Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B.

Before this commit if the parent line of both order were computed at the same time one of them would end up without parent.

This situation is getting worse since odoo@42008de (saas-18.1) were all the parent_line_id are recomputed on every upsell order (even already confirmed one) as soon as line on the parent order are touched

The follow use case lead to duplicate line on the parent

A parent subscription A with 1 product Z
Create an upsell B with a line that upsell 1 product Z Create an upsell C with a line that upsell 1 product Z On both upsell the parent line is set properly

Confirm Upsell B, the parent line on Upsell C is set to false Confirm Upsell B, the parent subscription ends up with a two line for the product Z

After this commit,
parent_line_id are computed per order, so one order cannot have two lines with the same parent_line_id but two (or more) different order can have each one line with the same parent_line_id even if their parent_line_id are computed at the same time.

Forward-Port-Of: odoo/enterprise#84340
Forward-Port-Of: odoo/enterprise#84255

**PURPOSE**

ESG (Environmental, Social, and Governance) module was built with one clear mission: to make ESG reporting simple, integrated, and affordable for every business.
Today, ESG is no longer a nice-to-have, it's a legal, financial, and reputational necessity. With the EU's Corporate Sustainability Reporting Directive (CSRD) now in force, companies are required to report their environmental, social, and governance performance using formal frameworks like the European Sustainability Reporting Standards (ESRS).
But beyond compliance, the pressure is mounting from all sides: investors are assessing ESG risks before funding businesses, major clients are adding sustainability criteria to supplier evaluations, and consumers are choosing brands that act responsibly. At the same time, ESG opens up massive business opportunities; from lowering energy costs and improving employee retention to building long-term trust and brand loyalty.
That's where Odoo comes in. By natively integrating with apps like Accounting, Fleet, Payroll, and Employees, we automate ESG data collection, eliminating the manual burden and reducing the cost and time spent collecting the data required for carbon footprint reporting. Each business activity can be tracked, through expense type of account move lines, in real time, giving you an up-to-date view of your emissions and enabling you to measure the immediate impact of your sustainability efforts.
If you work with a carbon consultant, their configuration becomes a reusable asset, making year-on-year updates seamless. For environmental consultancies, we also offers the most affordable carbon tracking tool on the market enabling you to focus on expertise services while giving clients a powerful, integrated platform without the need for expensive external tools. With secure access rights, ESG professionals can collaborate directly on client data, just like accountants do.
With Odoo, ESG impact is no longer a burden or a side project, it becomes a natural, data-driven part of how you run your business.

**MODELS**

* Source Database (`esg.database`): connect to certified emission factor databases, including regional and sector-specific sources (e.g. ADEME, IPCC). Download the DB that the system proposes and that fit your business needs or upload yours by creating a new one.
* Gaz (`esg.gas`): includes the six gases defined under the Kyoto Protocol: CO₂, CH₄, N₂O, HFCs, PFCs, and SF₆. Each gas is assigned a Global Warming Potential (GWP) value, allowing for conversion into a standard unit — CO₂-equivalents (kgCO₂e). This ensures consistency and comparability across different emission sources, aligning with GHG Protocol standards.
* Emission Sources (`esg.emission.source`): grouped into three scopes based on their origin:
  - Scope 1: Direct emissions from owned or controlled sources (e.g. fuel used in company cars or on-site combustion).
  - Scope 2: Indirect emissions from purchased energy (e.g., electricity, steam, heating).
  - Scope 3: All other indirect emissions from the value chain, including both upstream (e.g. supplier emissions, travel) and downstream (e.g. product use, waste). Scope 3 often represents the majority of total emissions.
* Emission factors (`esg.emission.factor`): coefficients which allows to convert activity data into GHG emissions.
  - Computation method: physical vs monetary (choose how emissions are calculated)
    - Physical: based on quantity and unit of measure: e.g. kg CO₂ per liter of fuel or per kWh — more precise.
    - Monetary: based on amount and currency: e.g. kg CO₂ per € spent — useful when no physical data is available.
* Assignation Rules (`esg.assignation.line`): define how the emission factors will be assigned on the account move lines.
  - Product level (e.g. laptop, printer)
  - Partner level (e.g. emissions tied to a specific supplier)
  - Account level (e.g. expense account 6700 for Office Equipment)
  => Product assignation takes precedence over partner and account, and partner assignation takes precedence over account.
* Activity type mapping (`esg.activity.type`): link each emission to a lifecycle activity type (e.g. Raw Materials, Transport, Energy).
* Other Emissions (`esg.other.emission`): emissions that are not linked to a journal entry. This allows for the inclusion of emissions from activities that are not directly tied to financial transactions, such as employee commuting or waste disposal.

**MENU ITEMS**

* Collect:
  - Emissions: automatic data synchronization. Pulls data from Accounting for purchase and expense data and provides a “New” option to add Other Emissions (not linked to a journal entry) manually. The system will assign Emission Factor if there's a pre-configured assignation rule and if not, the user can add an emission factor on an emission manually.
  - Employee commuting pivot table: uses data from the Employee (distance from home to office), Fleet (Vehicle model and associated emission factor (gCO₂/km)). 
 Apply the formula: `Days * Distance * 2 (round trip) * 3/7 (average number of office days per week) * Vehicle emission factor`

* Measure -> Environment:
  - Carbon Analytics: visualize and analyze emissions per year, scopes (1,2,3), activity types (energy, transport, etc.), etc. To highlight where to act to have the biggest impact on your company's carbon footprint.
  - Carbon Footprint Report: automatically generate your company's carbon footprint report: in tCO₂e (tonnes of CO₂ equivalent), by scopes, with gas repartition, aligned with “Le Bilan Carbone” and “GHG Protocol” requirements, available in downloadable PDF and Excel formats for submission or internal use.

* Measure -> Social:
  - Gender Parity: view gender breakdown across departments, leadership levels, locations, job positions, etc.
  - Pay Gap Calculation: automatically calculates the median hourly pay gap between male and female employees, following the EU method: `(Median male pay - Median female pay) / Median male pay * 100`

* Act:
  - Initiatives as projects: Use the Project module to manage ESG actions.
  
[ task-4517841](https://www.odoo.com/odoo/project.task/4517841)

Related to https://github.com/odoo/odoo/pull/195951

Forward-Port-Of: odoo/enterprise#79004

Before this commit, achievement were performed using records on
account_move, sale_order and sale_order_log tables (+ move lines, order
lines, products etc).

Reading those table is extermely costly. We tried to limit what we
fetched using context depending on the current action:

- https://github.com/odoo/enterprise/commit/7c8621e71b1e8267cd6e0e7968cbb46705568e32
- https://github.com/odoo/enterprise/pull/80043

And we had to revert it here:
https://github.com/odoo/enterprise/commit/c6ee48faa967342c958b4410e71b49bf453cd316

Using a period_domain in the context computed on fly in _where_calc was
a bad idea. The record were correctly fetched but the following flow was
broken:

Go to an approved commission plan --> click on the commissions stat
button --> everything is correct
Now click on details for a commission line with non empty achived amount

All the achievements are correct but when we click on "Details" of
sale.commission.achievement.report (id=42) account_move (142), we may
end up on another record.

Because when the ORM does the fetch query, it will fetch
sale.commission.achievement.report where id=42 and at that moment, the
context is lost when we click on the line.

Therefore as ids are recomputed, the line 42 is not the one
corresponding to the account move 142 anymore.

This commit ensure we avoid doing a cross join on account_move or
sale_order or sale_order_log because these are really bad for
performance and we select the record in a CTE.
- We select them based on current users, teams if defined
- We avoid fetching records outside of plan date values

Forward-Port-Of: odoo/enterprise#84352
Forward-Port-Of: odoo/enterprise#82518