**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

When returning tracked-by-serial products from an incoming picking for
an exchange, the exchange move will have selected existing serial numbers
for the new incoming picking.

This happens because `move_orig_ids` is set on the exchange move(s),
then `_action_assign()` happens. If there's a `move_orig_ids`, it will
use the available move lines from the move_orig_ids and so assign the
corresponding serial number.

Additionally, the buttons to generate/import serials/lots are invisible
because `origin_returned_move_id` is set on the same exchange move(s).
Again, the exchange move(s) should be considered 'new' move thus having
no origin.

task 4893860:
Additionally (again), it fixes an issue where on-hand quantities and
forecasted quantities of the exchanged product were incorrect after
validating the exchange.

task 4778066:
Finally, this PR also hides the 'Return for Exchange' button for
pickings that are neither `incoming` nor `outgoing`.

tasks 4748294 (& 4778066 & 4893860)

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

Description of the issue/feature this PR addresses:
This PR aims to fix certain compliance issues apparent in the UBL structure of Nilvera. an access right issue was also occurring when account is installed but not account_accountant when doing check_nilvera_customer.

Current behavior before PR:
- access right error when doing check_nilvera_customer with account_accountant uninstalled.
- negative lines were allowed in nilvera invoices and were reflected in the xml document.
- StandardItemIdentification displays the products barcode under the invoice line.
- multiplierfactor was not reflecting the discount % of the invoice line

Desired behavior after PR is merged:
- added read access to account module specific groups.
- raise a blocking error if there are discount lines in the invoice.
- remove the StandardItemIdentification node from the xml document
- show discount % in the multiplierfactor 


task-4907751

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

Forward-Port-Of: odoo/odoo#223136

Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total between the sale and pos app.

Steps to reproduce:
-------------------
* Modify the product precision to have 4 digits
* Modify the burger menu combo product
  * Sale price 26.5
  * Burger choice: Cheese burger, remove taxes, change price to 10
  * Drinks choice: Coca cola, remove taxes, change price to 10, extra price set to 4.5
  * Add another combo choice with 1 product only, no tax, price 10
* Open pos session
* Add the combo, select the product that were modified
> Total is 31.01 when it should be 31.00

Why the fix:
------------
Point of sale was using the decimal precision set on the product price to compute the price unit of the child lines. We can notice that the sale app was using the currency precision.

We will use the same approach as sales. The decision was driven by the fact that 1) both scenarios could make sense, 2) total should be as set, 3) child line prices are not as important as the total and don't have a big influence.

opw-4769227

**Current behavior:**
Since https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3, we valuate an unbuild operation by attempting
to match the ensuing OUT layer with the IN layer from the
original MO.

The point being to eliminate a potential valuation imbalance for
the manufactured product (might affect cost, etc.).

**New behavior**
Don't attempt to match an unbuild valuation layer with the
original MO valuation layer. If there is some cost difference
between build time and unbuild time, make a corrective journal
entry for it.

**Issue with current behavior**
The following sequence:
1. Create Product A with average costing, real-time valuation
2. Create 2 components, avg costing, real-time val
3. Create a BoM for Product A with the components
4. Manufacture 3 units of Product A with different component
quantities (can set flexible consumption on BoM)
5. Unbuild the first manufactured unit

Results in Product A's cost not matching the expected average
cost according to the valuation layers.

**Cause of the issue:**
Unbuilding the first MO created an out move at the original
"build time" cost, but since we've built 2 additional qty, that
original cost is not the current average cost- thus the
"theoretically current" standard price of the product (sum of
layers value divided by remaining qty) is no longer the value we
see on the product form.

**Fix:**
Don't try and match the valuation layers. Aside from issues such
as the one described above, it might not actually make
functional sense to do so (e.g., FIFO isn't actually adhering to
first-in-first-out if we're preferring the original IN layer for
an unbuild valuation).

Instead we make a journal entry with any excess cost of
production (it was actually a solution proposed in the
discussion on https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3 in the first place).

Additionally, now that we aren't doing this mapping, we can
revert the non-test difference of https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47, as this commit was
fixing an issue introduced by the change which added the
mapping.

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

Forward-Port-Of: odoo/odoo#221718

Currently, an error occurs when creating a channel that includes guest members.

Steps to Reproduce:
 - Install the `mail` module.
 - Go to `Channels > New`.
 - Fill in the `channel name` and `Under Members`, add a member with a `guest`, and `save`.

`KeyError: 'partner_id'`

This error occurs when a user creates a channel and adds a guest in the Members section. This error occurs after [this commit]( https://github.com/odoo/odoo/commit/ad612321bcafe6dfdaabf3aa37f26af364185a69), where the partner_id and guest_id fields dynamically become readonly [1], so that if only the guest is entered, the partner becomes readonly, and when the record is created, the partner_id key does not exist, and raises the error [2].

This commit ensures that the partner_id is accessed only if it is present in the record.

[1]- https://github.com/odoo/odoo/blob/5bddf9bfb634d09d3264e4fe4734d75f1083775a/addons/mail/views/discuss_channel_views.xml#L87-L88

[2]- https://github.com/odoo/odoo/blob/5bddf9bfb634d09d3264e4fe4734d75f1083775a/addons/mail/models/discuss/discuss_channel.py#L235

sentry-6791956423

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

Forward-Port-Of: odoo/odoo#222211

**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

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