Login in a database where utm is installed, so you get a session in that database. Now go to /web/database/manager and create a new empty db, the installation completes but you get an Internal Server Error message, in the logs a traceback: UTM is not installed. The problem is that once the new database has been created, the user automatically gets a new logged-in session inside that new database, but the environment of the original request got (wrongly) updated too, so later on when the reque

Login in a database where utm is installed, so you get a session in that database. Now go to /web/database/manager and create a new empty db, the installation completes but you get an Internal Server Error message, in the logs a traceback: UTM is not installed.

The problem is that once the new database has been created, the user automatically gets a new logged-in session inside that new database, but the environment of the original request got (wrongly) updated too, so later on when the request wraps up, we are no longer using the same environment/registry as at the begining of the request and the http stack fails.

Solution: only update the request env if the new env is on the same database.

Btw, the original implementation with httpocalypse got that part right, but when we did f63c0f4 a few years later we couldn't remember why the `if request.db == dbname` was needed and we decided to remove it, turns out it is indeed needed.

Forward-Port-Of: odoo/odoo#209459
Forward-Port-Of: odoo/odoo#200145

Adds a test to ensure the Sales Details report computes the correct total base amount when products with multiple taxes are sold. This test covers a previously incorrect behavior where the base amount was summed multiple times for products with multiple tax lines, leading to inflated totals. Now, the report uses the accurate tax-excluded total to avoid duplication. Opw-4670643. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: o

Adds a test to ensure the Sales Details report computes the correct total base amount
when products with multiple taxes are sold.

This test covers a previously incorrect behavior where the base amount was summed
multiple times for products with multiple tax lines, leading to inflated totals.
Now, the report uses the accurate tax-excluded total to avoid duplication.

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

Forward-Port-Of: odoo/odoo#212377
Forward-Port-Of: odoo/odoo#203289

Help the users by creating filters automatically depending on the hierarchy of analytic plans. This allows to open any standard view (list/pivot/graph) by level of hierarchies. One usecase is, for a plan about localisation: * Main plan: City (i.e. Brussels, New York, Los Angeles) * Level 1 sub plan: Country (i.e. Belgium, USA) * Level 2 sub plan: Continent (i.e. Europe, America) This will generate (or delete) automatically new fields depending on the various levels in the hierarchy bei

Help the users by creating filters automatically depending on the hierarchy of analytic plans.
This allows to open any standard view (list/pivot/graph) by level of hierarchies.

One usecase is, for a plan about localisation:
* Main plan: City (i.e. Brussels, New York, Los Angeles)
* Level 1 sub plan: Country (i.e. Belgium, USA)
* Level 2 sub plan: Continent (i.e. Europe, America)

This will generate (or delete) automatically new fields depending on the various levels in the hierarchy being created or deleted.

When the feature is in use, the group by widget becomes a drop-down similar to the groupby selector of dates, allowing to select either the year/month/...

task-4763892

Forward-Port-Of: odoo/odoo#213995

Steps to reproduce: - add a property on Tasks - open a pivot view - group by this property - insert in spreadsheet => boom The pivot cannot be loaded because the property is not a real field. Hence it's not loaded by `fields_get` and we are missing the property metadata (type) We need to load the definition independently and we push it to the fields. It's a hack but it seems to work. opw-4858129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su

Steps to reproduce:
- add a property on Tasks
- open a pivot view
- group by this property
- insert in spreadsheet

=> boom

The pivot cannot be loaded because the property is not a real field. Hence it's not loaded by `fields_get` and we are missing the property metadata (type)
We need to load the definition independently and we push it to the fields. It's a hack but it seems to work.

opw-4858129


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

Forward-Port-Of: odoo/odoo#214449
Forward-Port-Of: odoo/odoo#213832

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1 with a BoM that includes: - Component 1 (sequence = 1) - Component 2 - KIT (sequence = 2), which itself contains: - Component 2-1 (sequence = 1) - Component 2-2 (sequence = 2) - Component 3 (sequence = 3) - Create a Manufacturing Order for P1. Observed behavior: - The

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.

Steps to reproduce:
- Create a product P1 with a BoM that includes:
  - Component 1 (sequence = 1)
  - Component 2 - KIT (sequence = 2), which itself contains:
      - Component 2-1 (sequence = 1)
      - Component 2-2 (sequence = 2)
  - Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.

Observed behavior:
- The generated stock moves are ordered as:
    1. Component 1
    2. Component 3
    3. Component 2-1
    4. Component 2-2

Expected behavior:
- The stock moves should respect the BoM line sequence:
    1. Component 1
    2. Component 2-1
    3. Component 2-2
    4. Component 3

Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430

Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.

opw-4809095

Forward-Port-Of: odoo/odoo#212761

Forward-Port-Of: odoo/odoo#214247 Forward-Port-Of: odoo/odoo#208639

Forward-Port-Of: odoo/odoo#214247
Forward-Port-Of: odoo/odoo#208639

to_reproduce: --- 1. Create a combo product (no company set) 2. Create a combo choice (no company set) 3. Add a product with company restrictions 4. Multi-company error appears: "Incompatible companies on records" 5. Set company on combo choice and product template - error resolves 6. Remove company from both combo choice and combo product template 7. Save succeeds despite invalid company configuration problem: --- - During combo choice updates, only the modified combo items are inc

to_reproduce:
---
1. Create a combo product (no company set)
2. Create a combo choice (no company set)
3. Add a product with company restrictions
4. Multi-company error appears: "Incompatible companies on records"
5. Set company on combo choice and product template - error resolves
6. Remove company from both combo choice and combo product template
7. Save succeeds despite invalid company configuration

problem:
---
- During combo choice updates, only the modified combo items are included in vals['combo_item_ids'], while existing unchanged combo items are not added to the validation scope.
 https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L68
- The company validation logic only checks items present in the vals,  missing the existing combo items that should also be validated for company consistency.
https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L1092

solution:
---
- Add another check on combo items

opw-4844678

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

Forward-Port-Of: odoo/odoo#213615

This commit introduces a hook filter method that allows to filter the amls taken into account in _get_invoiced_lot_values (verify the quantity of serial product previously delivered). PR enterprise: odoo/enterprise#81656 Ticket [link](https://www.odoo.com/odoo/project/49/tasks/4644031) opw-4644031 Forward-Port-Of: odoo/odoo#213413 Forward-Port-Of: odoo/odoo#202262

This commit introduces a hook filter method that allows to filter the amls taken into account in _get_invoiced_lot_values (verify the quantity of serial product previously delivered).

PR enterprise: odoo/enterprise#81656

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/4644031)
opw-4644031

Forward-Port-Of: odoo/odoo#213413
Forward-Port-Of: odoo/odoo#202262

To reproduce: ============= - Create a private project and a task in it - Create a subtask in this task and assign it to Demo - Log in as Demo and go to "My Tasks" - the subtask is listed but opening it gives an access error Problem: ======== the computation of the field `show_display_in_project` requires reading `project_id` from the parent task, which is not allowed for Demo Solution: ========= read through `sudo` opw-4850408 --- I confirm I have signed the CLA and read t

To reproduce:
=============
- Create a private project and a task in it
- Create a subtask in this task and assign it to Demo
- Log in as Demo and go to "My Tasks"
- the subtask is listed but opening it gives an access error

Problem:
========
the computation of the field `show_display_in_project` requires reading `project_id` from the parent task, which is not allowed for Demo

Solution:
=========
read through `sudo`

opw-4850408

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

Forward-Port-Of: odoo/odoo#214287
Forward-Port-Of: odoo/odoo#213755

### Problem: The discount display policy in POS invoices is designed to hide discounts when a pricelist with a percentage-based discount is applied to its items. However, if an additional discount is added directly to a POS order line, it will not be shown in the total. Additionally, if one of the lines has a manually modified price, the total will incorrectly reflect that line's discount. ### How to reproduce: * Add a percentage discount to one of the products in the pricelist

### Problem:
The discount display policy in POS invoices is designed to hide discounts when a pricelist with a percentage-based discount is applied to its items. However, if an additional discount is added directly to a POS order line, it will not be shown in the total.

Additionally, if one of the lines has a manually modified price, the total will incorrectly reflect that line's discount.

### How to reproduce:
    * Add a percentage discount to one of the products in the pricelist
    * Order two products and add a percentage discount to both
    * Modify the price of the order line for one of them
    * Complete the order (the printed invoice total discount is the total discount of the manually modified line)

opw-4776259

Forward-Port-Of: odoo/odoo#212259
Forward-Port-Of: odoo/odoo#212099

The test `test_website_event_tour_admin` fails randomly depending on the processing speed available. When clicking on `a[title='Back to All Events']`, if the website happens to still be in edit mode, the click will be prevented: https://github.com/odoo/odoo/blob/18.0/addons/website/static/src/client_actions/website_preview/website_preview.js#L424-L438 We can use the clickOnSave function made specifically for this. It ensures exiting edit mode before continuing. --- runbot-223022 Fo

The test `test_website_event_tour_admin` fails randomly depending on the
processing speed available.
When clicking on `a[title='Back to All Events']`, if the website
happens to still be in edit mode, the click will be prevented: 
https://github.com/odoo/odoo/blob/18.0/addons/website/static/src/client_actions/website_preview/website_preview.js#L424-L438
We can use the clickOnSave function made specifically for this.
It ensures exiting edit mode before continuing.

---

runbot-223022

Forward-Port-Of: odoo/odoo#211221

### Description: Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues. ### Fix: `_compute_picking_ids`, is improved by moving its search outside the loop and grouping by `group_id`, reducing the amount of calls to the ORM. A `skip_activity` context check is added in `_action_cancel` to bypass activity generation during cancellation, aligning with the existing check done later in `_

### Description:

Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues.

### Fix:

`_compute_picking_ids`, is improved by moving its search outside the loop and grouping by `group_id`, reducing the amount of calls to the ORM.

A `skip_activity` context check is added in `_action_cancel` to bypass activity generation during cancellation, aligning with the existing check done later in `_log_activity_get_documents`.

Also, a bug in `_action_cancel` was calling a filtering on`self`, rather than `production`, and that for each production, which was degrading the performance.

### Benchmark:

| N° of MO | Before | After |
|----------|--------|-------|
|       80 |    15s |    1s |
|      160 |    33s |    2s |
|     1000 |   2:52 |    8s |

### Reference:

opw-4734710

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

Forward-Port-Of: odoo/odoo#214347
Forward-Port-Of: odoo/odoo#207960

Fake tours were not working in the Point of Sale app because thier assets were loaded before the global assets. This commit ensures that the fake tours are loaded after globals one. Forward-Port-Of: odoo/odoo#214316

Fake tours were not working in the Point of Sale app because thier assets were loaded before the global assets.

This commit ensures that the fake tours are loaded after globals one.

Forward-Port-Of: odoo/odoo#214316

When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number. This happens because the method checks for the absence of both `picking_type_id`, `is_inventory`, and `lot_id`, assuming a lot is always mandatory outside inventory and picking flows. However, scrap operations may occur outside these flows and should not necessarily require a lot, especially when triggered programmatically (e.g. via

When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number.

This happens because the method checks for the absence of both `picking_type_id`, `is_inventory`, and `lot_id`, assuming a lot is always mandatory outside inventory and picking flows.

However, scrap operations may occur outside these flows and should not necessarily require a lot, especially when triggered programmatically (e.g. via API or automation), bypassing the form view validation.

This commit updates the condition in `_action_done()` to check the context key `is_scrap`, which is already passed in `do_scrap()` via `move.with_context(is_scrap=True)._action_done()`.

This allows tracked products to be scrapped without a lot in valid scenarios, without misleadingly assigning a `picking_type_id` to the move.


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

Forward-Port-Of: odoo/odoo#213536
Forward-Port-Of: odoo/odoo#206900

**Steps to reproduce:** - Purchase Order > Dashboard > hover on not acknowledged, late receipt and their counts **Issue:** - Tool tips of 'not acknowledged' and 'late receipt' mentions RFQ's instead of PO's. These two kpi are related with PO and filter only Purchase Orders not RFQ's **Solution:** - Update the title of divs to 'POs' opw-4848307 Forward-Port-Of: odoo/odoo#213142

**Steps to reproduce:**
-  Purchase Order > Dashboard > hover on
 not acknowledged, late receipt and their counts

**Issue:**
 - Tool tips of 'not acknowledged' and 'late receipt' mentions
 RFQ's instead of PO's. These two kpi are related with PO and 
 filter only Purchase Orders not RFQ's

**Solution:**
 - Update the title of divs to 'POs'

opw-4848307

Forward-Port-Of: odoo/odoo#213142

Versions -------- - 18.0+ Feature doesn't exist in earlier versions. Steps ----- 1. Create a product with a tag; 2. create another product with a different tag; 3. create a delivery method with these 2 tags as Must Have Tags; 4. add one product to the cart in eCommerce; 5. go to checkout. Issue ----- Delivery method isn't available for selection. Cause ----- While the "Must Have Tags" description states that the method should be available if at least one product on the or

Versions
--------
- 18.0+

Feature doesn't exist in earlier versions.

Steps
-----
1. Create a product with a tag;
2. create another product with a different tag;
3. create a delivery method with these 2 tags as Must Have Tags;
4. add one product to the cart in eCommerce;
5. go to checkout.

Issue
-----
Delivery method isn't available for selection.

Cause
-----
While the "Must Have Tags" description states that the method should be available if at least one product on the order has at least one of these tags, the `_match_must_have_tags` method requires *all* of the `must_have_tags` to be present in the order.

Solution
--------
Instead of using `all`, use `any` when matching must-have tags.

opw-4836137

Forward-Port-Of: odoo/odoo#214312

In odoo/odoo#199763, `_related_analytic_distribution()` was introduced to pass the existing analytic distribution in a sale order line to an invoice line. However, sale_line_ids is a Many2Many field, so to avoid singleton errors in the case of multiple SOLs, only the analytic distribution of the first sale order line is passed. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214035

In odoo/odoo#199763, `_related_analytic_distribution()` was introduced to pass the existing analytic distribution in a sale order line to an invoice line. However, sale_line_ids is a Many2Many field, so to avoid singleton errors in the case of multiple SOLs, only the analytic distribution of the first sale order line is passed.

no-task

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

Forward-Port-Of: odoo/odoo#214035

Versions -------- - 17.0+ Steps ----- 1. Have a partner with a `commercial_partner_id`; 2. for the `commercial_partner_id`, create an partner of type `invoice`; 3. create & confirm a sale order invoiced to the initial partner; 4. create & confirm a sale order invoiced to the invoice partner; 5. check the `credit_to_invoice` of the partner; 6. check the `credit_to_invoice` of the `commercial_partner_id`. Issue ----- The credit to invoice is twice what it should be. Cause ----

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

Steps
-----
1. Have a partner with a `commercial_partner_id`;
2. for the `commercial_partner_id`, create an partner of type `invoice`;
3. create & confirm a sale order invoiced to the initial partner;
4. create & confirm a sale order invoiced to the invoice partner;
5. check the `credit_to_invoice` of the partner;
6. check the `credit_to_invoice` of the `commercial_partner_id`.

Issue
-----
The credit to invoice is twice what it should be.

Cause
-----
The `_compute_credit_to_invoice` method sums up the `credit_to_invoice` on a partner's `commercial_partner_id`. By first checking the partner's credit to invoice, it searched all sale orders credited to the commercial entity. Before it can sum these, it first has to compute the `credit_to_invoice` of the `commercial_partner_id`, which retrieves the same sale orders, and hence get summed up twice.

Solution
--------
Only compute the `credit_to_invoice` on commercial partners by taking the intersection of `self` & `self.commercial_partner_id`.

opw-4855507

Forward-Port-Of: odoo/odoo#214343
Forward-Port-Of: odoo/odoo#213849

### Steps to reproduce: - Create a storable product - Click on the Forecast smart button > Replenish - Process the dialog or close it #### > Your browser will crash as you just started an infinite loop this can be seen in the logged by an infinite amount of `search_read` on the stock.warehouse model made to render the template an infinite amount of time. ### Cause of the issue: Closing on replenish will open a dialog. Closing this dialog will in turn call its `_onClose` method: http

### Steps to reproduce:

- Create a storable product
- Click on the Forecast smart button > Replenish
- Process the dialog or close it
#### > Your browser will crash as you just started an infinite loop this can be seen in the logged by an infinite amount of `search_read` on the stock.warehouse model made to render the template an infinite amount of time.

### Cause of the issue:

Closing on replenish will open a dialog. Closing this dialog will in turn call its `_onClose` method:
https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/stock/static/src/stock_forecasted/forecasted_buttons.js#L26-L28 Now the issue is that `res` does nto contains a special key and hence the `reloadReport` call will execute an `ir.actions.client` to relaod the forecast page:
https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/stock/static/src/stock_forecasted/stock_forecasted.js#L97-L106 This is highly problematic since executing such an action will call the `_updateUi` method and hence close all existing dialog: https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/web/static/src/webclient/actions/action_service.js#L1274 https://github.com/odoo/odoo/blob/ef356e1f803a6f82811a83f5b8a8dd54ef41cf32/addons/web/static/src/webclient/actions/action_service.js#L1111 Since our dialog hasn't been closed yet this will in turn call back the `_onClose` that started this call resulting in this chain of action: `_onClose -> updateUi -> closeAll -> _onClose -> ...` And, since the `noReload` parameter is not used in our `_onClose` we end up in an infinite loop.

### Note:

The infinite loop has become possible since saas-18.1 see commit d606be75c44fccf0b1ddf5216892f1d4b7162686
which changes the order on which a dialog is closed and its call back  method called (onClose). Prior to that change the dialog was closed and  then its call back called. It is now the opposite so that if the onClose of a dialog triggers an action closing all dialogs, it will in turn call the onClose of the dialog one more time. The way to avoid infinite recursion is therefore to ensure that the `noReload` parameter of the onClose is correctly used as introduced here:
https://github.com/odoo/odoo/commit/d606be75c44fccf0b1ddf5216892f1d4b7162686#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dL1123-R1108

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

Forward-Port-Of: odoo/odoo#214191

Before this commit: - The `_compute_l10n_in_state_id` method only considered `pos_session_ids` when assigning the state for Indian POS moves. - Reversed POS orders were ignored, leading to missing `l10n_in_state_id`. After this commit: - Added `reversed_pos_order_id` to the `@api.depends` decorator. - Updated domain to include moves with `reversed_pos_order_id`. Ensures correct place of supply is computed for reversed POS orders as well. OPW: 4862639 Forward-Port-Of: odoo/odoo#2142

Before this commit:
- The `_compute_l10n_in_state_id` method only considered `pos_session_ids` when assigning the state for Indian POS moves.
- Reversed POS orders were ignored, leading to missing `l10n_in_state_id`.

After this commit:
- Added `reversed_pos_order_id` to the `@api.depends` decorator.
- Updated domain to include moves with `reversed_pos_order_id`.

Ensures correct place of supply is computed for reversed POS orders as well.

OPW: 4862639

Forward-Port-Of: odoo/odoo#214293

Problem: Videos added in the operation worksheet are not visible on the Shop Floor interface. Cause: `embedded_components`, such as video iframes, are only supported within the HTML editor context and cannot be rendered elsewhere. This results in the video being silently dropped. Solution: Introduce a `disableVideo` flag for the `note` field in worksheet views. This avoids embedding unsupported video content and ensures the interface remains consistent. Steps to reproduce: 1. G

Problem:
Videos added in the operation worksheet are not visible on the Shop
Floor interface.

Cause:
`embedded_components`, such as video iframes, are only supported
within the HTML editor context and cannot be rendered elsewhere.
This results in the video being silently dropped.

Solution:
Introduce a `disableVideo` flag for the `note` field in worksheet
views. This avoids embedding unsupported video content and ensures
the interface remains consistent.

Steps to reproduce:
1. Go to Manufacturing > Operations > Worksheet.
2. Add a video in the worksheet's description field.
3. Create a Manufacturing Order (MO) for a product using this
   operation.
4. Confirm the MO and open it in the Shop Floor interface.
5. Open the worksheet tab.
→ The video is missing (not rendered).

opw-4783722

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

Forward-Port-Of: odoo/odoo#214210
Forward-Port-Of: odoo/odoo#209554

Adds a new module allowing for the support of withholding taxes at the time of registering a payment. task-3614935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214149

Adds a new module allowing for the support of withholding taxes at the time of registering a payment.

task-3614935

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

Forward-Port-Of: odoo/odoo#214149

## Background In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT. At the moment, several accounts created by default don't match the CoA pattern: - 999000001 Cash Difference Gain - 999000002 Cash Difference Loss. - 999300000 Cash Discount Loss - 999400000 Cash Discount Gain - 999999 Undistributed Profits/Losses ## Fix Given correct codes to the existing accou

## Background

In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT.

At the moment, several accounts created by default don't match the CoA pattern:

- 999000001 Cash Difference Gain
- 999000002 Cash Difference Loss.
- 999300000 Cash Discount Loss
-  999400000 Cash Discount Gain
-  999999 Undistributed Profits/Losses

## Fix

Given correct codes to the existing accounts and modifying data for some records:.

| Account                             | New code  | New name                                                                     | New Account type |
|-------------------------------------|-----------|------------------------------------------------------------------------------|------------------|
| 999000001 Cash Difference Gain      | 403.01.01 | Other Income                                                                 |  ~               |
| 999000002 Cash Difference Loss      | 601.84.02 |  ~                                                                           |  ~               |
| 999300000 Cash Discount Loss        | 402.01.01 | Returns, discounts or bonuses over sales and/or services at the general rate | other income     |
| 999400000 Cash Discount Gain        | 503.01.01 | Returns, discounts or bonuses over purchases                                 |  ~               |
| 999999 Undistributed Profits/Losses | 305.01.01 | Uncut Result                                                                 |  ~               |

---

opw-4288080

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

Forward-Port-Of: odoo/odoo#213430
Forward-Port-Of: odoo/odoo#196852

Steps to reproduce: 1. Install the german localization 2. Create company in DE 3. Create a partner that has country = PL 4. Create a customer invoice for the PL partner 5. Open: Accounting > Reporting > EC Sales List 6. Hit the wheel and create the CSV export. 7. Open the file Issue: see that the amount is a float Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4575788) opw-4575788 Forward-Port-Of: odoo/enterprise#87421 Forward-Port-Of: odoo/enterprise#83822

Steps to reproduce:
1. Install the german localization
2. Create company in DE
3. Create a partner that has country = PL
4. Create a customer invoice for the PL partner
5. Open: Accounting > Reporting > EC Sales List
6. Hit the wheel and create the CSV export.
7. Open the file

Issue:
see that the amount is a float

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4575788)
opw-4575788

Forward-Port-Of: odoo/enterprise#87421
Forward-Port-Of: odoo/enterprise#83822

Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration o

Problem
---------
Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...)

One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default.

But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration of the level. This always generates an additional PDF that is often not needed.

Objective
---------
Do not tick "Print" by default when manually executing a follow-up level, unless "Letter" is ticket in the configuration of the level.

Solution
---------
Set "Print" default value in the wizard to the "Letter" value of the follow up line instead of leaving it as True (which is the default).

task-4574971

Forward-Port-Of: odoo/enterprise#86750
Forward-Port-Of: odoo/enterprise#80116

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1 with a BoM that includes: - Component 1 (sequence = 1) - Component 2 - KIT (sequence = 2), which itself contains: - Component 2-1 (sequence = 1) - Component 2-2 (sequence = 2) - Component 3 (sequence = 3) - Create a Manufacturing Order for P1. Observed behavior: - The

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.

Steps to reproduce:
- Create a product P1 with a BoM that includes:
  - Component 1 (sequence = 1)
  - Component 2 - KIT (sequence = 2), which itself contains:
      - Component 2-1 (sequence = 1)
      - Component 2-2 (sequence = 2)
  - Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.

Observed behavior:
- The generated stock moves are ordered as:
    1. Component 1
    2. Component 3
    3. Component 2-1
    4. Component 2-2

Expected behavior:
- The stock moves should respect the BoM line sequence:
    1. Component 1
    2. Component 2-1
    3. Component 2-2
    4. Component 3

Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430

Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.

opw-4809095

Forward-Port-Of: odoo/enterprise#87003

**Current behavior:** Scanning a package type in an MO in barcode while having a raw move line (component line) selected will result in a traceback. **Expected behavior:** Put the comp line in a new pack of that package type. **Steps to reproduce:** 1. Make a packge type 2. Make a new MO -> open it in barcode 3. Scan some component, select the new line 4. Scan the barcode of the package type -> traceback **Cause of the issue:** We end up calling `action_put_in_pack` when `

**Current behavior:**
Scanning a package type in an MO in barcode while having a raw
move line (component line) selected will result in a traceback.

**Expected behavior:**
Put the comp line in a new pack of that package type.

**Steps to reproduce:**
1. Make a packge type

2. Make a new MO -> open it in barcode

3. Scan some component, select the new line

4. Scan the barcode of the package type -> traceback

**Cause of the issue:**
We end up calling `action_put_in_pack` when `this.resModel` is
`MrpProduction` (which does not define this method).

**Fix:**
Define the method for the barcode MRP model to display a
notification to, rather, scan a product (scanning a package here
doesn't make sense).

opw-4564834

Forward-Port-Of: odoo/enterprise#86498
Forward-Port-Of: odoo/enterprise#81374

Users can upload request documents from the kanban and the activity views. This commit extends this feature to the list view. task-4745800 Forward-Port-Of: odoo/enterprise#84518

Users can upload request documents from the kanban and the activity views. 
This commit extends this feature to the list view.

task-4745800

Forward-Port-Of: odoo/enterprise#84518

- Create a product with tracking by serial numbers then set a lot and serial number on the product - Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings - Create a sale order with the test product and confirm it - Create the invoice and send the cfdi report - Request a cancel and select the reason 01 Document issued with errors (with related document) . On the CFDI PDF report of the new invoice, there are no lines for lots and serial numbers—they are not

- Create a product with tracking by serial numbers then set a lot and serial number on the product
- Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings
- Create a sale order with the test product and confirm it
- Create the invoice and send the cfdi report
- Request a cancel and select the reason 01 Document issued with errors (with related document)
.
On the CFDI PDF report of the new invoice, there are no lines for lots and serial numbers—they are not printed.

The report uses the _get_invoiced_lot_values method from sale_stock to retrieve serial numbers. This method is first called when sending the CFDI for the parent invoice. However, when it is called for the child invoice, the method checks the quantity of the serial product, which is now depleted.

This commit introduces a hook that allows to filter the amls taken into account in get_invoiced_lot_values. In l10n_mx_edi, we do not take the amls from the parent invoice after a cfdi cancellation.

community PR: https://github.com/odoo/odoo/pull/202262

opw-4644031

Forward-Port-Of: odoo/enterprise#87229
Forward-Port-Of: odoo/enterprise#81656

[FIX] l10n_au_hr_payroll_account: avoid NewId warning in compute steps to reproduce: 1.install l10n_au_hr_payroll_account 2. without demo data 3. run the test test_form_new_record The compute method was being triggered too early, while the record still had a temporary NewId and not a real database ID. This caused a warning when using the field in a domain: Domains don't support NewId. We added a dependency on previous_report_id to make sure the compute only runs after the field is s

[FIX] l10n_au_hr_payroll_account: avoid NewId warning in compute

steps to reproduce:
1.install l10n_au_hr_payroll_account
2. without demo data
3. run the test test_form_new_record

The compute method was being triggered too early, while the record still had a temporary NewId and not a real database ID.
This caused a warning when using the field in a domain: Domains don't support NewId.

We added a dependency on previous_report_id to make sure the compute only runs after the field is set and the record is saved.
This avoids the warning and keeps the logs clean.

build_error-115303

Forward-Port-Of: odoo/enterprise#85292

Before this commit, if the module was installed, the delivered quantity for non-rental products in a sale order paid through PoS would be doubled. opw-4805368 Forward-Port-Of: odoo/enterprise#87231 Forward-Port-Of: odoo/enterprise#87175

Before this commit, if the module was installed, the delivered quantity for non-rental products in a sale order paid through PoS would be doubled.

opw-4805368

Forward-Port-Of: odoo/enterprise#87231
Forward-Port-Of: odoo/enterprise#87175

Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery order with one unit of P1, not linked to any sale order - Go to the delivery order list view - Select the created delivery order - Click on Action → Fetch shipping label Problem: A traceback is triggered: ``` ValueError: ValueError('Expected singleton: shopee.shop()') while evaluating 'records._fetch_shipment_label()' The above server error caused the following client error: ``` The `_fetch_s

Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery order with one unit of P1, not linked to any sale order
- Go to the delivery order list view
- Select the created delivery order
- Click on Action → Fetch shipping label

Problem:
A traceback is triggered:

```
ValueError: ValueError('Expected singleton: shopee.shop()') while
evaluating
'records._fetch_shipment_label()'

The above server error caused the following client error:

```

The `_fetch_shipment_label` function expects at least one item, but
we don't check it via a user error, because we're supposed to call
`_sync_shopee_pickings` instead, where all these filtering and checks
are done


opw-4812360

Forward-Port-Of: odoo/enterprise#86442

Currently, a raceback occurs when the user changes or adds the expression label of the column in the "Generic Tax report". **To reproduce this issue:** 1) Install "account_reports" 2) Open "Generic Tax report" from "Accounting Reports" 3) In columns change the "Expression Label" and save the record 4) Open the "Tax Report" in "Reporting" 5) A traceback occurs **Error:** ``` UnboundLocalError: local variable 'col_value' referenced before assignment ``` **Cause:** The "co

Currently, a raceback occurs when the user changes or adds the expression label 
of the column in the "Generic Tax report".

**To reproduce this issue:**

1) Install "account_reports"
2) Open "Generic Tax report" from "Accounting Reports" 
3) In columns change the "Expression Label" and save the record 
4) Open the "Tax Report" in "Reporting"
5) A traceback occurs

**Error:**

```
UnboundLocalError: local variable 'col_value' referenced before assignment
```

**Cause:**
The "col_value" is assigned based on the "expr_label" if it doesn't match the if conditions it leads to a traceback.
https://github.com/odoo/enterprise/blob/d154cbf1bd5b4cc104ff0e2443047aff0c05330f/account_reports/models/account_generic_tax_report.py#L921-L932

**Solution:**
This commit will resolve this issue by assigning a fallback value of an empty string to col_value.

opw-4841789

Forward-Port-Of: odoo/enterprise#87277

When generating the accounting entry from the Corporate Tax Report, the system first tries to find a miscellaneous journal with the short code `MISC`. If this specific journal does not exist, the logic attempts to fall back and find any other journal of type 'Miscellaneous' (`type = 'general'`). However, this fallback search fails with an error due to an incorrect search domain syntax. Steps to reproduce: 1. Go to Accounting > Configuration > Journals. 2. Ensure no journal exists with th

When generating the accounting entry from the Corporate Tax Report, the system first tries to find a miscellaneous journal with the short code `MISC`.

If this specific journal does not exist, the logic attempts to fall back and find any other journal of type 'Miscellaneous' (`type = 'general'`). However, this fallback search fails with an error due to an incorrect search domain syntax.

Steps to reproduce:
1. Go to Accounting > Configuration > Journals.
2. Ensure no journal exists with the short code MISC.
3. Ensure at least one other journal of type "Miscellaneous" exists (for example, with short code GEN or MSC).
4. Go to Accounting > Reporting > Corporate Tax Report.
5. Try to generate the accounting entry.

opw-4836686

Forward-Port-Of: odoo/enterprise#87300

Currently, an error is produced when the payslip start date is not set, but the end date is provided. **Steps to reproduce:** - Install `hr_payroll` module(with demo). - Create new **Payslip** for employee **Anita Oliver**. - Clear both the start and end dates under the "Period" section. - Set only the end date. **Error:** `TypeError: '<' not supported between instances of 'bool' and 'datetime.date'` **Cause:** The `_compute_warning_message` method performs a comparison between `s

Currently, an error is produced when the payslip start date is not set, but the end date is provided.

**Steps to reproduce:**
- Install `hr_payroll` module(with demo).
- Create new **Payslip** for employee **Anita Oliver**.
- Clear both the start and end dates under the "Period" section.
- Set only the end date.

**Error:**
`TypeError: '<' not supported between instances of 'bool' and 'datetime.date'`

**Cause:**
The `_compute_warning_message` method performs a comparison between `slip.date_from` and `contract_id.date_start` without verifying if `date_from` is set. When `date_from` is `False`, the comparison `False < datetime.date(...)` - [1], raises a `TypeError`.

[1] - https://github.com/odoo/enterprise/blob/a65314702b99df97c778d4f12f943191a19dafd1/hr_payroll/models/hr_payslip.py#L1029-L1031

This commit adds checks to ensure that start and end date is defined before performing date comparisons in warning message computation, preventing the error.

Sentry - 6618275041

Forward-Port-Of: odoo/enterprise#86091

Creating documents through a mail alias for a folder that was not the default company on the database would cause an error. This was due to the company on the inactive alias that was being created for this new document not matching the company of the owner document. Added the company id to the vals_list before the creation of the document in order to use the proper company on the alias. opw-4717277 Forward-Port-Of: odoo/enterprise#86602 Forward-Port-Of: odoo/enterprise#84719

Creating documents through a mail alias for a folder that was not the default company on the database would cause an error. This was due to the company on the inactive alias that was being created for this new document not matching the company of the owner document.

Added the company id to the vals_list before the creation of the document in order to use the proper company on the alias.

opw-4717277

Forward-Port-Of: odoo/enterprise#86602
Forward-Port-Of: odoo/enterprise#84719

#Description A total of 6 test were broken after changes(add/removal) in the accounts of the mexican localization in odoo community, the new expected values for the assesments were updated. Related PR #196852. Forward-Port-Of: odoo/enterprise#87238 Forward-Port-Of: odoo/enterprise#81270

#Description 

A total of 6 test were broken after changes(add/removal) in the accounts of the mexican localization in odoo community, the new expected values for the assesments were updated.

Related PR #196852.

Forward-Port-Of: odoo/enterprise#87238
Forward-Port-Of: odoo/enterprise#81270