This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.

Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.

LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
  cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
  month following the month in which the transactions occurred. For example,
  the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
  transactions include:
  1. Intra-Community acquisition of Goods
  2. Intra-Community acquisition of Services
  3. Intra-Community triangular trades
  4. Intra-Community supplies of Goods
  5. Intra-Community supplies of Services

REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
  The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
  'DUKIntegrator'. This tool allows businesses to:
  1. Validate the generated XML file against the official schema to ensure it is
     correctly formatted.
  2. Generate the final PDF file with the XML attachment, which is the official
     format for submission.

TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
  with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
  attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
  'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
  For collecting these details, we've created a wizard that will be on the
  return validation action. Along with these details, we ask the user if the
  current return is the corrected/rectified one, with the 'corrective_declaration'
  field in this wizard. This wizard will then store these details in the
  respective return. And in the XML export file generator, we are retrieving
  these details from the return to show in the report.

REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
  software and XML report attribute explanation in English: (
  https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
  https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
  https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)

Forward-Port-Of: odoo/enterprise#109921

**_Steps to reproduce:_**

* Install `l10n_br_avatax` and configure Avalara Brazil.
* Create at least two customer invoices.
* Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**.
* Select the invoices and click **Action → Confirm Entries**.

**_Observed behavior:_**

* A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated.

**_Cause:_**

* During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records.
* Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices.

**_Fix:_**

* Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`.
* This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error.

opw-6334761

Forward-Port-Of: odoo/enterprise#126437
Forward-Port-Of: odoo/enterprise#124993

Steps to reproduce the bug:
- Install l10n_us_hr_payroll_adp without hr_attendance/hr_holidays_attendance
- Run the test suite (runbot build 941182)
- TestL10nUsHrPayrollADPExport.setUpClass fails

Problem:
setUpClass raised `ValueError: Invalid field 'overtime_deductible' in
'hr.work.entry.type'` when writing on the overtime work entry type.
The field overtime_deductible is only defined by hr_holidays_attendance
https://github.com/odoo/odoo/blob/saas-19.2/addons/hr_holidays_attendance/models/hr_work_entry_type.py#L10-L12
which depends on hr_attendance and auto-installs only when hr_attendance is
present. l10n_us_hr_payroll_adp's dependency chain (l10n_us_hr_payroll ->
hr_payroll) never pulls in hr_attendance, so the field doesn't always
exist in the test's registry.

However, when hr_holidays_attendance IS installed (e.g. on the full
runbot build), the field must still be set to False: leaving it at its
default causes hr.leave.create() to run
hr_holidays_attendance's _check_overtime_deductible(), which raises
"The employee does not have enough extra hours to request this leave."
for the overtime leaves created further down in setUpClass, since the
test employees have no recorded attendance/overtime hours.

Solution:
Only include overtime_deductible in the write() vals when the field
exists on hr.work.entry.type, keeping it disabled either way.

runbot-941182

Steps to Reproduce:

1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set  to any date and click into an aging bucket for that partner.

Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.

Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.

Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:

    action['context'] = {
        'recon_limit': options['date']['date_to'],
    }

Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.

Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.

opw 6333699

Forward-Port-Of: odoo/enterprise#126021

### Issue before this commit:
When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice.

### Steps to reproduce the issue:
1. Download Accounting and l10n_mx
2. Create an invoice and send it to CFDI
3. Select 'Request for cancel'
4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled
5. Print the invoice again
6. See PDF does not show fiscal information (QR, fiscal folio, etc.)

### Cause of the issue:
https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields.

### Reason to introduce the fix:
A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled.

opw-6393656

Forward-Port-Of: odoo/enterprise#126466

### Issue
When AI chat is used in views where `config.viewSwitcherEntries` is not initialized, sending a message raises a `TypeError` because the code attempts to call `.map()` on an undefined value.

### Steps to Reproduce
[Video](https://drive.google.com/file/d/1i7kWDnmv4mebGtf1to12BNHCG5omBTXl/view?usp=sharing)
1. Click the **Ask AI** button.
2. Open the AI chat.
3. Keep it open and navigate to the **Shopfloor** app.
4. Send a message in the AI chat.

### Error
```text
TypeError: Cannot read properties of undefined (reading 'map')
    at WithSearch.getCurrentViewInfo
```

### Fix
Safely handle cases where `config.viewSwitcherEntries` is undefined by using optional chaining and falling back to an empty array.

**Before**
```js
result.available_view_types = config.viewSwitcherEntries.map((v) => v.type);
```

**After**
```js
result.available_view_types =
    config.viewSwitcherEntries?.map((v) => v.type) || [];
```

opw-6414684

Forward-Port-Of: odoo/enterprise#125821

Steps to reproduce:
- set the company currency to XCG
- set the PoS sales journal currency and the PoS pricelist currency to USD
- configure a XCG <-> USD rate
- create a customer without any outstanding balance
- open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method
- open the Customers screen and look at the Total Due of that customer

Issue:
The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100.

Cause:
get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time.

opw-6403320

Forward-Port-Of: odoo/enterprise#126402
Forward-Port-Of: odoo/enterprise#125798

### Issue:
When an invoice has a down payment on a line with a withholding tax, the `PrepaidPayment/PaidAmount` in the UBL XML included the withholding tax amount, causing a mismatch with `LegalMonetaryTotal/PrepaidAmount` which correctly excludes it

### Cause:
`PrepaidPayment/PaidAmount` was set directly from `prepayment_move.amount_total`, which includes all taxes `LegalMonetaryTotal/PrepaidAmount` uses `_aggregate_base_line_tax_details` to exclude withholding taxes, but this was not applied to the `PrepaidPayment` node

### Fix:
Using `prepayment_move.amount_total` directly includes all taxes and does not match the rounding logic of `LegalMonetaryTotal`

Instead, `_aggregate_base_line_tax_details` is used with the same `total_grouping_function` as `LegalMonetaryTotal`, ensuring both nodes use the same rounding logic and exclude withholding taxes

Reversed down payment moves are also excluded from `AdditionalDocumentReference` to avoid referencing cancelled invoices

### Steps to reproduce:
- Install `l10n_pe_edi` and `sale_management` with demo data
- Switch to the PE company
- Create and confirm a Sale Order (Customer: PE Company, Product: Any, Unit Price: 200, Taxes: VAT 18% and 3% IGV Withholding)
- Create, confirm and pay a Down Payment Invoice (Fixed: 28.92)
- Go back to the SO and create the Regular Invoice
- Confirm it and click Process Now
- Open the EDI Document tab and download the XML

Before the fix, the sum of `PrepaidPayment/PaidAmount` did not match `LegalMonetaryTotal/PrepaidAmount`

opw-6273903

Forward-Port-Of: odoo/enterprise#121733

When using the click & collect option, the available qty for renting was not taking the selected warehouse into account.

Steps to reproduce:
-------------------
* Create 2 different warehouses with 2 different adresses
* Create a product available for renting
* Setup the product to use serial numbers
* Create 2 serial number, 1 in each warehouse
* Activate the click & collect option on the website
* Create a first sale order to collect in warehouse 1
* In the backend, confirm the order and pick it up
* Go back to the website and make a second order for the second warehouse
> Observation: When clicking on the "Add to cart" you get an error
  saying that there is no quantity available

Why the fix:
------------
When computing the `product_rented_quantities` it would look for `sale.order.line` in all the warehouse. So it would find the line from the first order even if it's not linked to the selected warehouse. So we just add a new element to the domain to filter out the incorrect warehouses.

opw-6328475

Forward-Port-Of: odoo/enterprise#126545
Forward-Port-Of: odoo/enterprise#124969

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#125703
Forward-Port-Of: odoo/enterprise#122038

## Issue
When generating an invoice for a service product with an invoicing policy based on timesheets, the amount of hours invoiced is wrong if there exists a credit note linked to that SO.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Create on Order: Task
    - Project: Any project
    - Invoicing Policy: Based on Timesheets
3. Create a SO
    - Any Customer
    - Product P (any quantity)
    - Confirm the SO
4. In the created task, add a timesheet entry
    - Date: Today
    - Time Spent: 10:00 (10 hours)
5. Create and confirm the invoice for the SO
6. Create a Credit Note from the invoice, set the quantity to 4 hours, and confirm it
7. From the created task, add a second timesheet entry
    - Date: Any future date (e.g., today + 7)
    - Time Spent: 15:00 (15 hours)
8. Create a second invoice, but set a Timesheets Period that only covers the second timesheet entry
9. **The quantity on the newly created invoice is 9 hours, even though we're clearly trying to invoice the 15 hours from the second timesheet entry.**

## Cause
The second invoice is impacted by the credit note generated from the first one. When generating that second invoice, the [`_recompute_qty_to_invoice`](https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L149) method incorrectly computes the amount to invoice by taking into account `account.analytic.line` from outside the provided range.

The delivered quantity is correctly calculated by taking into account the provided range (through the `start_date` and `end_date` added to the domain passed to `_get_delivered_quantity_by_analytic`:

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L176-L180

But then, for each `sale.order.line`, we look at the related `account.analytic.line` without taking into account the provided dates, which leads to lines outside of the range impacting the invoice.

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L182-L193

In the example described in the *Steps to reproduce*, we start with a (correct) amount delivered of 15.0, we find two `invoice_lines_to_calculate` (the invoice of 10 hours, and the credit note of 4 hours), which leads to the quantity to invoice being set to `15 - (-4 + 10) = 9`. This seems like an odd behavior as it:
- doesn't invoice all the hours within the provided range (15 hours within the range, and we're only invoicing 9)
- doesn't invoice **all** the hours left to be invoiced (6 hours are already invoiced, 25 should be in total, and we're invoicing 9)

opw-6373870

Forward-Port-Of: odoo/odoo#277727

Issue:
Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device uuid identifying that pairing is only generated when the customer display dialog is opened, so a PoS whose customer display was never opened sends `device_uuid: null` and the server publishes on `UPDATE_CUSTOMER_DISPLAY-null`, a channel nobody can listen to.

Steps to reproduce:
Open a PoS session, never open the customer display, and add a product to an order.

Current behaviour:
An rpc is sent for each change of the order, and each of them ends up as a bus notification that no customer display can ever receive.

Expected behaviour:
Nothing is sent as long as no customer display was ever opened.

Solution:
Skip the rpc while no device uuid exists. A customer display opened in the same browser as the PoS is served by the BroadcastChannel, which is unaffected.

task-6408513

Forward-Port-Of: odoo/odoo#277687

**Issue**
Selling a kit with dropshipping in AVCO/FIFO could wrongly set the standard_price of the component product to 0 after validating the dropship transfer.

**Steps to reproduce**
- Create a kit and component product
- Activate MTO and dropship route for the kit
- Activate dropship route for the component
- Add a vendor for the component (ex: 100 dollars)
- Set component to AVCO valuation
- Create and confirm a sale order
- Confirm the associate purchase order and the dropship transfer
- Go to the product -> The standard price is still 0 instead of being updated from the supplier price.

**Cause**
While confirming the PO, a picking is created:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_stock/models/purchase_order.py#L371 With its associated moves:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_stock/models/purchase_order.py#L383 During the move preparation, the `cost_share` is not propagated on the generated move values, so it remains equal to 0.

The `cost_share` is computed while exploding the kit BOM: https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/purchase.py#L94 https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/mrp/models/mrp_bom.py#L463 https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/mrp_bom.py#L62 https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/mrp_bom.py#L70

However, only the `bom_line_id` is propagated on the move values: https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/purchase.py#L94-L99

Later, while validating the dropship transfer:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/stock_move.py#L177 the move value is used to recompute the standard price: https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/product.py#L651 
While `move.value` is not zero, `move._get_value` is:
https://github.com/odoo/odoo/blob/cac987867b083355d3366228d0c551b34f366d92/addons/stock_account/models/product.py#L485-L487
since it depends on the move `cost_share`:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/stock_move.py#L25

Since the move `cost_share` is 0, the AVCO/FIFO recomputation uses an incorrect value and the component standard price is not updated.

**Solution**
No need to use `cost_share` to compute the value if the price_unit is already given for the component

opw-6176571

Forward-Port-Of: odoo/odoo#264341

Description of the issue/feature this PR addresses:

  Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so locale-based integer formatting remains enabled.

  Steps to reproduce:

  1. Enable developer mode.
  2. Go to Settings > Technical > Email > Outgoing Mail Servers.
  3. Create a server and set SMTP Port to `8069`.
  4. Move focus away from the field.
  5. The same issue occurs on an Incoming Mail Server with a port such as `10143`.

  Current behavior before PR:

  Ports are displayed with thousands separators, e.g. `8,069` and `10,143`.

  Desired behavior after PR is merged:

  Mail server ports remain unformatted, e.g. `8069` and `10143`.

  Fixes #275937

  ---
  I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
  
"As a recent Computer Engineering graduate, I made my first open-source contribution to Odoo." :)

Forward-Port-Of: odoo/odoo#278329

You'll need two users :
	- Internal User A that can create projects
	- User B with a granted portal access

Optionnal third user to compare the flows :
	- Internal User B that can create tasks in a porject

- With User A, create a new project with atleast a single stage
- Go to the project settings
- Make sure that Visibility is set to : "All internal users and invited portal users"
- Click on Share Project
- Add User B as a new Collaborator with the Edit acess mode
- Confirm by clicking on Share Project
- Still in the project settings, click on the blue user icon in the top right to edit the Followers :
	- Make sure you are following the project
	- Click on the edit button and make sure Task Created is checked

 Optionnal for easiness of testing :
 - Go to the User A settings and in Preferences > Notifications : In Odoo

- Log in with User B (in a new incognito tab on the side is best)
- Go to Projects > The project that has been shared
- Create a new task

No notification is sent to User A. If the same flow is done using User C, then a notification is correctly sent.

The fields that determine to which users the notifications are sent to is `message_follower_ids`. In our case, the value of that field does not contain User A, so no notifcation is sent to them.

The method responsible for assigning values to that field is `_message_auto_subscribe()` which adds follower using subtypes parent relationship. The parent subtype of tasks are projects. So, essentially, we look for followers of the parent project, and see if we can add them to our task.

Before proceeding with the assignation, we check that the parent subtype's field was actually edited :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L4778-L4781

So we look that `updated_values` contains "project_id". `updated_values` is created by the the `mail_thread` create method by joining the values in `vals_list` and the context default variables. In our case, this should be enough since `default_project_id` is provided when creating a task :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L340-L344

But, a bit before this, the task create method edits the context to replace 'default_project_id' by 'default_create_in_project_id' : https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/project/models/project_task.py#L1102-L1109

So we do not detect that `project_id` has been changed and don't actually add the followers.

We remove the custom 'default_create_in_project_id` context

opw-6026932

Forward-Port-Of: odoo/odoo#278474
Forward-Port-Of: odoo/odoo#278353

Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed.

This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'.

**Steps to reproduce:**
- Install the stock module.
- Open the Transfers list view.
- Add custom group for 'Printed'.
- Open a transfer in the 'ready' state and print the 'Picking Operations' report using the Print button. Notice that the transfer is marked as 'Printed'.
- Open another transfer in the 'ready' state and print the 'Picking Operations' report from the actions menu.
- Observe that the transfer is not marked as Printed. The same issue occurs when printing it from list view.

**Expected behavior:**
A transfer in the 'ready' state should be marked as Printed whenever the 'Picking Operations' report is printed, regardless of whether it is triggered from the 'Print' button or the actions menu.
close #235129

Forward-Port-Of: odoo/odoo#276582

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse deliveries in two steps
- Inventory > Operations > Tranfers > Internal > New
- Set the operation type as Pick, set a partner and add Partner: Bob
- In the sales & Purchase tab of the partner form set a customer location to be a child of the Customers location: Customers/Bob'Stock
- Confirm and validate the Pick for 1 unit of a product P
#### > A ship picking is created but the destination of the related move is still set to the default customer location.

### Note:

If the flow is performed by a sale order, the `property_stock_customer` location will appropriately be used as `location_final_id`: https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L297 https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L306-L309 https://github.com/odoo/odoo/blob/720598d0315dbb91628441078febfd43ffefb431/addons/stock/models/stock_rule.py#L263-L264 So that the bug does not occur in that case. By contrast if the pick move is created manually, we do not set its `location_final_id` and hence do not propagate the info. Even though it looks expected to be set set as location_dest_id of the ship move sas suggested by the `stock.picking.location_dest_id` compute method :
https://github.com/odoo/odoo/blob/fe3aea07a1964cd24f4c8ebf2bc93e483eca6b0b/addons/stock/models/stock_picking.py#L990-L1002

opw-6402483

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

Forward-Port-Of: odoo/odoo#278838

A user with role Inventory/User cannot validate the dropship of a product with an Average Cost (AVCO) Costing Method

Steps to reproduce:
1. Install sale_management, stock_dropshipping and stock_landed_costs module
2. Go to Sales > Configuration > Categories and change Furniture / Office's Costing Method to Average Cost (AVCO)
3. Go to Settings > Users and set Marc Demo's role on Purchase to User
3. Log in as Marc Demo
4. Create and confirm a quotation for customer Acme Corporation with product Large Cabinet (Dropship route and AVCO costing method)
5. Go to the related purchase order and confirm it
6. Go to the related dropship and validate it
7. An access error is raised

Issue:
Validating a dropship recomputes the cost of the product and reads `stock.valuation.adjustment.lines`
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/models/stock_move.py#L11 But only Inventory/Administrator have read access to these records https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/security/ir.model.access.csv#L4

Solution:
Call `_get_landed_cost` with `.sudo()` in order to update the cost even though the user has no landed costs access

opw-6366844

Forward-Port-Of: odoo/odoo#276285

Steps to reproduce
1. Go to Manufacturing > Configuration > Settings and enable By-Products
2. Go to Inventory > Configuration > Locations, find the location with type
   Production and set the Cost of Production account
3. Go to Inventory > Configuration > Product Categories and set the costing
   method to Standard Price and Inventory Valuation to Perpetual (at invoicing)
4. Set the finished product and byproduct as Storable with a non-zero Cost
5. Create a BoM with a component and a byproduct with a Cost Share % assigned
6. Create and complete a manufacturing order
7. Check the journal entries of the MO: the byproduct entry shows $0

Issue
Standard-cost byproduct moves have no price_unit set in either code path
of _cal_price, so their journal entries always show $0.

When the finished product is standard cost, _cal_price returns early at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L66-L68
without iterating byproducts at all, so no price_unit is ever set on them.

When the finished product is FIFO/AVCO, the byproduct loop at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L83-L84
only sets price_unit for FIFO/AVCO byproducts. Standard byproducts are
skipped, giving them $0 even though their cost_share was already deducted
from the finished product, making value disappear from inventory entirely.

For standard-cost products the MO has no influence on their value — they
always use the standard_price from the product form, regardless of cost_share.

Solution
In the early-return branch, iterate byproducts: standard ones get
standard_price, FIFO/AVCO ones get total_cost * cost_share.
In the FIFO/AVCO branch, add the same standard_price fallback so standard
byproducts are no longer left at $0 when their cost_share is set.

opw-6020065

Forward-Port-Of: odoo/odoo#257472