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

Steps
-----
1. Create an individual partner;
2. assign them a pricelist A;
3. create a new company partner for them;
4. create a new pricelist A & sort it on top;
5. open a new quotation;
6. set new company as customer;
7. change customer to the individual partner.

Issue
-----
The quotation's pricelist changed from B to A. The pricelist used for the individual should be identical to the one used for their company.

Cause
-----
Commit de302c2d36305 added the `specific_property_product_pricelist` field to `res.partner`, as the way company-dependent fields are managed was changed on the database-level.

Commit 67cf577cd0a0 added the `_company_dependent_commercial_fields` method to enable syncing company-dependent commercial fields. The base method fetches all fields retrieved via `_commercial_fields`, and selects those whose `company_dependent` attribute is `True`.

In previous versions, the `_company_dependent_commercial_fields` override in `product` adds `property_product_pricelist`, as this field does not have the `company_dependent` attribute set, but it behaves as a company-dependent field. Starting from 18.0, the override adds `specific_property_product_pricelist` instead, which does have the `company_dependent` property set.

As a consequence, when `_company_dependent_commercial_sync` gets called, it does not sync the `specific_property_product_pricelist` as it's not included in the `_commercial_fields` override, nor does it sync when retrieving it from `_company_dependent_commercial_fields`, as it skips the current company, assuming the field was already handled by `_commercial_sync_from_company`: https://github.com/odoo/odoo/blob/c40760244d128cb57e11a233e89a93dd92b8fb56/odoo/addons/base/models/res_partner.py#L667-L668

Solution
--------
- Move `specific_property_product_pricelist` to `_commercial_fields`
    - This enables it to sync in `_commercial_sync_from_company`
- Remove the `_company_dependent_commercial_fields` override
    - `property_product_pricelist` shouldn't get synced by itself
    - `specific_property_product_pricelist` is already included by the base method

opw-4988736

Forward-Port-Of: odoo/odoo#222223

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

This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally require tracking (no lot/serial), but have been updated later to require it.

When unbuilding such a product, `stock.move.line._action_done` currently raises a UserError requiring a lot/serial number, because the component moves created by `mrp.unbuild`:
- do not have a picking_type_id,
- are not inventory moves,
- are not scrap moves,
- and lack lot/serial information.

However, in this context, the lot requirement is misleading, as the original `mrp.production` did not generate tracked components. It is valid to restore untracked components even if they are now tracked.

**Current behavior before PR:**
- Create an `mrp.production` for a product with untracked components.
- Complete the production.
- Later, enable lot tracking on one or more of the original components.
- Attempt to unbuild the production.
- ❌ Error is raised: “You need to supply a Lot/Serial Number for product…”

**Desired behavior after PR is merged:**
- The unbuild operation proceeds without error.
- The untracked components are restored correctly.
- Behavior remains unchanged for tracked components that did require lot info during the original MO.



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

Forward-Port-Of: odoo/odoo#222612
Forward-Port-Of: odoo/odoo#217282

Currently, an error occurs when a new user with the Member role and Administrator rights for the Point of Sale app attempts to open POS Category.

Steps to reproduce:
---
- Install the `point_of_sale` module (without demo data).
- Create a new User and give Administrator rights for POS & Accounting
- Now log in with a new user in a different browser
- Open the pos session(Clothes or bar)

Traceback:
---
```py
AccessError: You are not allowed to modify 'Product Category' (product.category) records.

This operation is allowed for the following groups:
	- Products/Admin en Products / Create

Contact your administrator to request access if necessary.

ParseError:while parsing /home/odoo/src/odoo/saas-18.3/addons/point_of_sale/data/scenarios/clothes_category_data.xml:5, somewhere inside <record id="product_category_clothes" model="product.category">
            <field name="name">Clothes</field>
        </record>
```

This commit prevents the error by displaying an "Access Denied" pop-up when a user with the "Member" role and Administrator rights attempts to open the POS Category.

sentry-6683335275, 6679363278, 6823710988

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

**Issue**
When creating an expense line, if the user selects an analytic distribution and clicks "Save & Close", the selected distribution is not saved. However, closing the popup with the "X" icon does trigger the save.

**Steps to Reproduce**
1. Go to Expenses > Expense Reports
2. Select an employee (e.g., Ronnie Hart)
3. Add a new expense line
4. Set an Analytic Distribution
5. Click Save & Close
6. Observe that the analytic distribution is not retained

**Root Cause**
The save behavior is triggered by a window click event, but clicks inside modals (like the analytic distribution popup) do not propagate as expected. Because everything within the popup is modal, the click does not satisfy the criteria to trigger saving the data.

**Fix**
Refine the modal detection logic in the `onWindowClick` handler. Specifically, allow modals that contain `this.widgetRef.el` to trigger the closing (and thus saving) behavior, ensuring that selections made in such modals are not lost when clicking Save & Close.

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

Forward-Port-Of: odoo/odoo#213996

Currently, an error occurs when trying to remove a move line from a bank statement line if the journal entry contains lines with different reconciliation models.

**Steps to Reproduce:**
1. Install the Accounting module.
2. Duplicate the "Internal Transfer" reconciliation model.
3. Accounting dashboard > click on Bank > create new record.
4. Add the invoice, apply "Internal Transfer" reconciliation model.
5. Edit the balance of the line to lower, apply duplicated model(Internal Transfers (copy)).
6. Try deleting the generated Liquidity Transfer line.

(Refer [this video](https://drive.google.com/file/d/1cz80Q5325x3rqYUlGahVzFIXH2iqrbRF/view?usp=drive_link) for steps to reproduce.)

**Error:**
ValueError - Expected singleton: account.reconcile.model(8, 6)

**Cause:**
In the method `delete_reconciled_line` at [1], the `reco_model_id` is fetched from `self.move_id.line_ids.reconcile_model_id`. If the move contains lines linked to multiple reconcile models, this causes a singleton error during subsequent processing.

**Fix:**
This commit uses the already computed `move_lines_to_remove` to retrieve `reconcile_model_id` instead of accessing it from `self.move_id.line_ids`, which may result in a multi-recordset.

[1] - https://github.com/odoo/enterprise/blob/89aa58029a79928788277489414f8192aa5353e4/account_accountant/models/account_bank_statement.py#L1041-L1049

sentry-6781788260

Steps to Reproduce:
1. Go to Delivery Methods.
2. Enable and configure Shiprocket, then publish it.
3. Go to Settings.
4. Search for Google Merchant Center Data Source.
5. Enable the checkbox.
6. Click on the Copy File Link button.
7. Open the copied link in a new browser tab.


Observation:
A traceback occurs, stating that some of the customer’s fields are missing.


Issue:
In the `_prepare_best_delivery_by_country` method, we create a temporary partner
record. Later, in `_check_required_value`, we validate the Street, Email, Pincode,
and Phone Number fields for that partner. However, these fields are not set
in the temporary record, which causes the validation to fail.


Solution:
Added a check on `recipient._origin` to ensure that required field validations are only
applied on actual partner records. This prevents raising validation
errors when using temporary partner records in Shiprocket flow.

Added `@mute_logger('odoo.tools.translate')` to suppress translation warnings in
test. In our test case, we are calling `_check_required_value` directly, which
internally calls `_get_lang`. The `_get_lang` method attempts to fetch the
language from `http.request`, but since `http.request` is not available in test
context, it fails to retrieve the language and logs a warning.

https://github.com/odoo/odoo/blob/642dde9546417115cbce5b826cdf996970dfbb48/odoo/tools/translate.py#L514C5-L517C1


opw-4972889

**Issue:**
Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS

**Cause:**
The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty` to the related `sale_line` each time it runs

When there is no PoS order, the method add 0 to the line, so the expected behavior work But when you have a PoS Picking, a quantity was added to `qty_delivered` each time the `rental.order.wizard` is used The issue also occured earlier when the `flush_all()` is called in `_process_order()`

**Fix:**
There is already a `_compute_qty_delivered` method in `pos_sale_stock_renting` that override the `qty_delivered` But it's restricted by `_are_rental_pickings_enabled()` That's not necessary because we don't use any `stock.picking` in the `_compute_qty_delivered` function, only `stock.move` so we removed that verification

To make the code working, we also need to extend the _get_outgoing_incoming_moves() results Because there were also block by a `_are_rental_pickings_enabled()` condition even if there is only moves here We need all the moves to calculate `qty_delivered` properly

**Steps to reproduce:**
- Create a New Product "Rental PoS" that Can be Rented
- Create and confirm a New Rental Order, with any customer and your product
- Open a PoS Session
- Click on Quotation/Order
- Choose the last Order and Settle the order
- Click on Yes (to confirm import to PoS)
- Click on Payment, select Cash and Pay
- Go in the Backend, and to your RO
- Click Return and Validate
- Before the fix, the Delivered should be 2.0

opw-4877019

Forward-Port-Of: odoo/enterprise#93279
Forward-Port-Of: odoo/enterprise#90510

**PROBLEM**
1. In Annexes D and E you can declare custom tax rate. If the custom rate is 0%, this percentage will not be exported into the xml. When submitting the xml to the ECDF, the submission will be rejected because the xml doesn't state how much % is the custom tax rate.
2. In Section V, code 110, 108 and 109 should be decimal since they are averages.

**STEP TO REPRODUCE**
1. install the l10n_lu module and select the demo lu company.
2. In accouting app, goes to the annual tax report (Accounting/Reporting/Tax Report, select Annual VAT Declaration).
3. Goes to Appendix D or E, and fill code 128, 136, 144, and 162, and leave the custom rate(%) above each of them at 0%.
4. Export to xml (using the little cog thingy).
5. Notice the code 396, 394 149, and 153 doesn't appear in the xml.

**CAUSE**
1. Field containing zero are filtered out the xml by default, which is the case of the custom rate (%) fields.
2. Average number of employee during the year is declared in the report data file to be of the integer type.

**FIX**
1. Adding custom rate fields to the mandatory fields.
2. Changing type of average employee fields to float.

opw-4978365

Forward-Port-Of: odoo/enterprise#91938