**Problem:**
When scheduling a message using an email template with custom attachments, those attachments will not have their `res_model` and `res_id` updated to relate to the scheduled message record. This can lead to access errors.

**Cause:**
When composing a message using an email template with attachments, those attachments are created with their `res_model` and `res_id` values corresponding to the mail composer record. However, when scheduling a message, only attachments with no `res_id` value (or a value of 0) are updated to correspond to the scheduled message record. https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mail/wizard/mail_compose_message.py#L1198-L1201
https://github.com/odoo/odoo/blob/30ca89b9e0d3c43d019167ec2de816c263f4bb92/addons/mail/models/mail_scheduled_message.py#L86

**Purpose:**
Modify the `mail.scheduled.message` override of `create` to not require an attachment have no `res_id` value to be properly updated.

**Steps to Reproduce in Runbot:**
1. Add an attachment to an email template.
2. Open a mail composer using that email template, then schedule the message for later.
3. Attempt to view the scheduled message with a different user.

More specific example flow:
1. Add an attachment to the Sales: Send Quotation email template.
2. Create a Quotation and send it with the Send by Email button, selecting Send Later instead of Send.
3. Attempt to view the Quotation with a different user.

opw-6293587

Forward-Port-Of: odoo/odoo#272261

Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project
---------------------
**Issue:**
  When a project is created from the sale app, it is not billable by default, and the sale order / sale order line are not set.

**Fix:**
 Remove default_allow_billable = False in the Create a Project

**Note:**
  default_allow_billable = True already exists in action_view_project_ids, but that default context is replaced when opening the project directly from the view. This happens because default_allow_billable = False is set in the Create a Project
  action.

Fix 2: sale_project: show only relevant project templates per company
----------------
**Steps:**
   - Install sale_project
   - Create two companies (A, B)
   - Create three project templates:
	 - Template A (company A)
	 - Template B (company B)
	 - Template C (no company → visible to all)
   - Create a sale order for company A with a service product
   - Confirm the sale order
   - Create a project and try to select a template

**Issue:**
   All project templates were visible even if the sale order had a company set.

**Fix:**
   Added a filter (domain) on the project template field so only templates for the sale order’s company or templates with   no company are shown. Users cannot select templates from other companies.

task-5074893

Forward-Port-Of: odoo/odoo#274417
Forward-Port-Of: odoo/odoo#229309

### Steps to reproduce:

- Have a company with a branch say "company1" and "branch"
- Create two products: Final product (FP), Component (Comp)
- Set the company_id of FP to "branch" and of Comp to "company1"
- Associate both products with a product category set to avco in company1 (the field is company dependant)
- Create a bom for FP with company_id set to "branch": 1 X Comp
- Impersonate a user whose only allowed and default is "branch"
- Create and confirm an MO for 1 unit of FP
- Set the qty_producing to 1 unit and validate
#### > Access Error: Access to unauthorized or invalid companies.

### Cause of the issue:

Validating the MO will, validate the component move and set its value: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/stock_move.py#L168-L173 But, in order to determine this value, it is necessary to determine its `property_cost_method`:
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L60-L69
Now, the issue is that the `product_template` of the component belongs to "company1" so that the user is unauthorized to read the valuation method of the product category for "company1".

opw-6216141

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

Forward-Port-Of: odoo/odoo#274108
Forward-Port-Of: odoo/odoo#272429

### Steps to reproduce:

- Have two companies: company1 and company2
- Create a producct P available in both company1 and company2
- with company1, create a kit bom for a product P
- with company2, create and confirm a sale order for 1 unit of P
- with company1, change the bom type of P from kit to manufature
#### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them.

### Cause of the issue:

Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18
https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42
However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol.

opw-6290304

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

Forward-Port-Of: odoo/odoo#273839
Forward-Port-Of: odoo/odoo#271119

*: mrp_subcontracting_{dropshipping, purchase}

### Steps to reproduce:

- In the settings: Enable subcontracting, dropshipping
- Create a storable dropshipped product FP with a set vendor for 5$ and subcontracting BOM: 1 X COMP. Value this product in avco perpetual
- Set the component to resupply subcontractor and standard price to 2$
- Create and confirm a sale order for 1 unit fo FP
- Validate the resupply to the subcontractor and then the dropship
> The FP standard price shoul dhave been updated to 5$ + 2$ = 7$
- Create and post a bill from the PO for 10$ rather than 5
#### > The FP standard price should have been updated to 11$ rather than 12$

Cause of the issue:

Posting the bill will call the `_set_value` method to re-evaluate the product in terms of the newly recorded `account.move`: https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/stock_account/models/stock_move.py#L393-L395 Now, the issue is that due to our config, there are two relevant moves linked to the `order_line`: the final move of the subcontracted production (which `is_in`) and the dropship move going from the subcontractor to the customer. When it comes to the subcontracted move, it is appropriately valuated at 12$ by the `_get_value_from_account_move` because of this override which adds the components value via the extra cost since the move has a `production_id`:
https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/mrp_subcontracting_purchase/models/stock_move.py#L14-L38 However, the dropship move will not add this extra cost (as no override sets it to have the same value as the subcontracted production it comes from) so that this move is valuated at 10$. This explains why the value of the avco product is then updated to 11$ since (12 + 10) /2 = 11

Note that the issue is not reproducible in the case of regular subcontracting since in that case the receipt from `subcontractor` to `stock` is not valuated.

opw-6318035

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

Forward-Port-Of: odoo/odoo#273137
Forward-Port-Of: odoo/odoo#272813

## Issue
In the attendance view of an employee, a recap of the current extra hours is displayed, showing four values:
1. Total Extra Hours Worked
2. Total Compensable Extra Hours
3. Time Off Taken from Extra Hours
4. Remaining Extra Hours

Each of the above values can be negative but the last one, which can seem odd as it appears to be calculated from the other values.

<img width="299" height="168" alt="6293174-before" src="https://github.com/user-attachments/assets/4377e2fd-f5f2-41a4-a82b-6f2598378499" />

## Steps to reproduce
1. Install *HR Attendance Holidays* (`hr_holidays_attendance`)
2. In Settings, toggle *Absence Management* and *Display Extra Hours*
3. For an employee E:
    - In the Payroll tab, set the Working Hours to the *Standard 40 hours/week* schedule
    - In the Settings tab, set the Overtime Ruleset to the *Default Ruleset*, and toggle the *Give back as time off* action for the *Employee Schedule Rule* rule
4. Create an attendance for employee E:
    - Any day where they are expected to work 8 hours
    - From 10am to 5pm (6 hours with lunch)
5. In the Employees app, go to employee E and click the *Monthly Hours* smart button
6. __In the *Balance* recap above the list of attendances, the *Remaining Extra Hours* row shows 00:00, which seems wrong compared to the other fields above (*Total Extra Hours Worked* and *Total Compensable Extra Hours*) which appear negative.__

## Cause
The `unspent_overtime` (*Remaining Extra Hours* in the balance recap) is computed by adding positive values, making it strictly positive.

https://github.com/odoo/odoo/blob/30c9e8c5b1e34b94c8aab8681e2c051a3b70f013/addons/hr_holidays_attendance/models/hr_employee.py#L62-L65

This was added by https://github.com/odoo/odoo/commit/2144bcfba1ac53c82fc7f2870a72bb13abee97e4, with no justification on why this value needs to be positive.

## Impact on "Time Off taken from Extra Hours"
Before this change, after following the above steps, a value of `-2:00` would be displayed in the *Time Off Taken from Extra Hours* row. This is no longer the case after this fix, since the `'unspent_compensable_overtime'` (*Remaining Extra Hours*) value is used to compute that row:

https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/hr_holidays_attendance/static/src/views/extra_hours_list_view.js#L39-L42

Instead, a value of `00:00` is shown. Before, we were substracting 0 hour of `unspent_compensable_overtime` to the -2 hours of `compensable_overtime`, now we are subectracting -2 hours of `unspent_compensable_overtime` to the same -2 hours of `compensable_overtime`. This is a side effect that was ignored, as it seems to make at least as much sense as showing `-2:00`.

<img width="321" height="179" alt="6293174-after" src="https://github.com/user-attachments/assets/907d5fb8-0c36-4b2e-bca7-1cec41baf22b" />


opw-6293174

Forward-Port-Of: odoo/odoo#274172
Forward-Port-Of: odoo/odoo#271272

Before this commit, joining a call in a mobile browser (Chrome, Safari, ...) would crop the bottom call controls (mic, camera, hang-up, ...) behind the browser's chrome (URL bar / bottom nav).

On mobile, entering the meeting uses the fullscreen overlay with `keepBrowserHeader: true`, so no native fullscreen is requested and the browser UI stays visible. The overlay was sized with the Bootstrap `vh-100` class (`height: 100vh`), and `100vh` resolves to the *large* viewport (as if the URL bar were hidden). Combined with `fixed-top`, the overlay extended past the visible area and pushed the control row off screen.

This commit sizes the overlay with `100dvh` (dynamic viewport height) instead, which tracks the currently visible viewport and shrinks while the URL bar is shown, keeping the controls on screen. This is a no-op in native/desktop fullscreen where `dvh == vh`, and matches the `dvh` usage already present in the codebase (welcome page, bottom sheet).

task-6353266


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

Forward-Port-Of: odoo/odoo#274651
Forward-Port-Of: odoo/odoo#273949

*: l10n_{ar,co,in,pe,uy}_pos

**Problem:**
The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS.

Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice.

**Solution:**
Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list).

Add a test to prevent future regression.


**Note:**
Another possibility is to re-inherit for each localization the new
standalone view, but this fix would need to update the module to work,
while this one works with just a restart.
There are still ongoing discussion with PoS team to see if we really
want to go back to each localization needing to inherit backend views.

[1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0bd77659b87359f2ca8763702462aaf92R26

opw-6244777 (many more)

Forward-Port-Of: odoo/odoo#270596
Forward-Port-Of: odoo/odoo#268158

**Issue**
In subcontracting, deleting a raw move line and adding a new one in the same editing flow can lead to a validation error during production recording.

**Steps to reproduce**
- Create a subcontracting product with a comp A
- Create and confirm a purchase order of that product (with the subcontracting partner)
- Open the associated delivery
- Open the move details (hamburger button)
- Delete the move line linked to the comp A
- Create a new move line for a comp B with a quantity of 1
- Record the production
-> A validation error occurs: the mandatory field `product_uom_id` is not set.

**Cause**
The regression comes from this commit: https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e

While assigning `move_raw_ids`, the inverse method is triggered:
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L34
At this stage, newly added lines are still virtual records (`line`):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L38
The previous implementation directly unlinked removed move lines (see commit https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L40-L43
Which will eventually flush and invalidate all the cache:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L4666
And since `line` is a virtual record (not in db), its associated values will be reset, among those, `product_uom_id`.
Later, when the move line is reassigned:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L49
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L5223-L5228

the validation fails because the virtual line no longer contains the required values.

**Additional note**
An alternative could have been using Command but since this line:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L42
can not be converted to:
`Command.set([line.id for line in lines])`
because `lines` may also contain virtual records.
This causes an invalid quantity for the move. Indeed, even if the command operator would update the quantity
on the `move_line` correctly, it won't for the quantity of the `move` because of its associated compute method:
https://github.com/odoo/odoo/blob/26ba95ac1c5bbb24975efb1a6f53c1ab47b61532/addons/stock/models/stock_move.py#L399-L400
that relies on `.ids`, which is `[]` on virtual records.
Therefore, keep the change minimal.

opw-6133281

Forward-Port-Of: odoo/odoo#270436
Forward-Port-Of: odoo/odoo#263058

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/odoo#270804
Forward-Port-Of: odoo/odoo#269552

This PR is needed for the fix of https://github.com/odoo/odoo/pull/272411

**Problem:**
lot's standard price are not correct 
when the product is fifo and move have 
different values and multiple lots

**Steps to reproduce:**
- product fifo tracked and valued by lots
- 20 IN @ 100 (all in lot 1)
- 10 IN @ 10 (5 in lot 1 and 5 in lot 2)
- on the product form click on the 
lot/serial number smart button and 
select lot 1

**Current behavior:**
the average cost of lot1 is 64
back on the product form the standard price is 
55

**Expected behavior:**
the average cost of lot 1 should be 20 * 100 (from move1) + 
5 * 10 (from move 2) / 25 = 2050 / 25 = 82
the standard price of the product should be 
2100 / 30 = 70

**Cause of the issue:**
Because the product is fifo, to compute 
the avg_cost of the lot we call _run_fifo()
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/stock_lot.py#L47
which calls _run_fifo_get_stack() to get the fifo
stack specific to this lot.
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L545

Issue 1) 
run_fifo_get_stack() stores the on hand quantity (for the lot 
if a lot is given as param) in fifo_stack_size and, 
as long as there is moves and fifo_stack_size>0, 
adds move (starting from the last one in date) to the stack
and removes the quantity of the move from fifo_stack_size.
It then returns the moves stack and the remaning quantity 
on the first move of the stack (for the rest we know it's the 
full quantity)
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L612-L618

Inside run_fifo_get_stack(), to do this, because 
we're only considering the quantities from 
this specific lot we should only remove the quantity from 
the move that went in lot, but currently 
we're removing the quantity from the entire move.
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L615-L618
So, at the first iteration of the while loop (for the move 
with 10 quantities), instead of doing 
fifo_stack_size(25) -= 5, we do fifo_stack_size(25) -= 10
The next move is the last one, so it's the one on which
remaining_qty_on_first_stack_move will be based on. 
remaining_qty_on_first_stack_move will be the minimum 
between the move's quantity and the fifo_stack_size. 
So because the fifo_stack_size is now wrongfully 
15 instead of 20 that's the value that will be returned
by _run_fifo_get_stack.

So inside run_fifo(), qty_on_first_move will be 15 instead of 20
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L545

Issue 2) 
Another issue is that inside _run_fifo when calling
_get_valued on the move, we don't use the lot 
parameter. So we use the entire quantity of the move 
instead of the quantity specific to the lot. 
https://github.com/odoo/odoo/blob/b07ff5843ee87741b293d9e67f72a77a2ed2ed88/addons/stock_account/models/product.py#L561-L562
And we use the full value of the move instead of 
the pro rata of the value for the quantity specific 
to the lot


As a consequence, inside _run_fifo the computation 
for the fifo_cost will be 
15 (because of issue1)  * 100 $ [first iteration of the while loop]
 \+ 10 (because of issue 2) * 10$ [second iteration of the while loop]
= 1600$
Instead of 20 *100 + 5 *10$ = 2050$

Therefore the avg_cost of the lot is wrong and the 
standard price of the product will also be false.

side note: those two issues balance each other if the price unit 
of the moves are the same

needed for PR of opw-6311341

Forward-Port-Of: odoo/odoo#273728

From saas-18.4, the expiration confirmation wizard can be triggered not only from expired lots, but also from stock move lines whose `removal_date` has passed.

For incoming receipts, tracked products use the `lot_name` field when the user is entering the lot. The corresponding `lot_id` is only created later once the receipt is validated.

As a result, it is possible for the expiration confirmation wizard to be displayed before the lot exists. In this situation, it attempts to display the product and lot information using `lot_id`, which is still empty, causing the message to show "False, False" instead of the actual lot name entered by the user.

It should use the move line information as a fallback when no `lot_id` has been created yet so it still displays the correct product and lot name.

Steps to reproduce
1. Enable Product Expiry.
2. Create a storable product with:
   - Tracking: By Lots
   - Use Expiration Date: enabled
   - Removal Time > 0
3. Create a receipt for the product.
4. Open Detailed Operations.
5. Enter a new lot number in the Lot/Serial Number field.
6. Ensure the removal date is in the past and validate the receipt.

Related Tickets: opw-6303140

Forward-Port-Of: odoo/odoo#273970
Forward-Port-Of: odoo/odoo#273143

**Issue**
In subcontracting, deleting a raw move line and adding a new one in the same editing flow can lead to a validation error during production recording.

**Steps to reproduce**
- Create a subcontracting product with a comp A
- Create and confirm a purchase order of that product (with the subcontracting partner)
- Open the associated delivery
- Open the move details (hamburger button)
- Delete the move line linked to the comp A
- Create a new move line for a comp B with a quantity of 1
- Record the production
-> A validation error occurs: the mandatory field `product_uom_id` is not set.

**Cause**
The regression comes from this commit: https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e

While assigning `move_raw_ids`, the inverse method is triggered:
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L34
At this stage, newly added lines are still virtual records (`line`):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L38
The previous implementation directly unlinked removed move lines (see commit https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L40-L43
Which will eventually flush and invalidate all the cache:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L4666
And since `line` is a virtual record (not in db), its associated values will be reset, among those, `product_uom_id`.
Later, when the move line is reassigned:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L49
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L5223-L5228

the validation fails because the virtual line no longer contains the required values.

**Additional note**
An alternative could have been using Command but since this line:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L42
can not be converted to:
`Command.set([line.id for line in lines])`
because `lines` may also contain virtual records.
This causes an invalid quantity for the move. Indeed, even if the command operator would update the quantity
on the `move_line` correctly, it won't for the quantity of the `move` because of its associated compute method:
https://github.com/odoo/odoo/blob/26ba95ac1c5bbb24975efb1a6f53c1ab47b61532/addons/stock/models/stock_move.py#L399-L400
that relies on `.ids`, which is `[]` on virtual records.
Therefore, keep the change minimal.

opw-6133281

Forward-Port-Of: odoo/odoo#270436
Forward-Port-Of: odoo/odoo#263058

### Description of the issue/feature this PR addresses:
International production payments processed via Redsys are failing with error code 9754 (SIS0754). This rejection occurs because the EMV3DS (3D Secure 2.0) payload is sending the billAddrState field with an invalid ISO code format for non-Spanish customers or customers without a state configured.

### Current behavior before PR:
The _redsys_prepare_merchant_parameters method hardcodes the billAddrState key into the DS_MERCHANT_EMV3DS dictionary payload. If self.partner_state_id.code is missing or empty, Odoo sends an empty/falsy value. Because Redsys enforces strict EMV3DS format validation, it rejects the entire transaction for having an invalid state format rather than simply ignoring the empty value.

### Desired behavior after PR is merged:
The DS_MERCHANT_EMV3DS dictionary is now constructed dynamically. The billAddrState key is only appended to the payload if a valid state code actually exists for the partner. RedSys allows this field to be optional, so omitting the key entirely when unavailable causes Redsys to skip the validation for that specific field, allowing certain international payments to process successfully.

opw-6237764

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

Forward-Port-Of: odoo/odoo#270899