Currently, editing a posted `miscellaneous` journal entry in Chile 
localization incorrectly raises a validation error.

**Steps to reproduce:**
- Install the `l10n_cl` module and switch to the `CL company`.
- Go to Accounting > Accounting > Journal Entries.
- Create a balanced entry using the `Miscellaneous journal `and `post` it.
- Reset it to draft, modify the `name`, and try to `save` it.

**Observation:**
`Validation error`: `The DTE document number (folio) must contain only digits.`

**Root cause:**
At [1], the constraint validation is applied to all journal entries in 
Chilean companies, including `miscellaneous` journals. However, 
`miscellaneous journals (move_type = 'entry')` are not linked to Chilean 
electronic documents, so the numeric folio validation should not apply to them.

**Fix:**
This commit ensures that the validation is not raised for `miscellaneous` journal 
types by excluding miscellaneous journals from the numeric folio validation constraint.

[1]:
https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30

opw-5926773

Forward-Port-Of: odoo/odoo#248965

When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others

Steps to reproduce:
-------------------
1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B
1. Create a sales order
2. Add two units of the product to the sale order
3. Confirm the sales order
4. Open the transfer, make the transfer retrieve the product from several location with the same lot.
5. Save the transfer
6. Open the sales order in POS
7. Load the SN/lots
-> Two line of qty 1 appear for the product A but only the first one has the lot number

Additional Issue:
8. Change the number of the product for the first line to 2 and erase the second line
9. Confirm and Pay
10. Close POS
11. Open move lines for this product (Inventory>product>In/out)
-> It moves 2 product from one location (when there is only product)

Observation:
-------------
When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten.

Addition Issue :
When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297

opw-5347992

Forward-Port-Of: odoo/odoo#251270
Forward-Port-Of: odoo/odoo#243347

Steps to produce:
---
- Install `website_sale` module.
- Go to website > open editor.
- Add an image snippet to the homepage.
- Click on the image and enable `Pop-up on Click`, then save.
- Click on the image.

Traceback:
---
`TypeError: Cannot read properties of undefined (reading 'length')`

Root cause:
---
- In the `setup` method, when the image is not part of a carousel,
  the element `.carousel-indicators` does not exist. As a result,
  `indicatorEl` is null, and the guarded block(at [1]) is skipped.
  Because of this, `this.liEls` is never initialized.
- Later, when the `onSlidCarousel` method is executed,
  its internal condition evaluates and find `liEls` as null and
  then `hide` method is called(see [2]).
- Inside the `hide` method, the code attempts to iterate
  over `this.liEls`(see [3]).

Solution:
---
- Initialized `liEls` in `setup()` to ensure it is always defined.
- Added a length check in `onSlidCarousel()` to execute the logic
  only when `liEls.length > 0`.
- This prevents this.page from being computed using invalid
  values and avoids it being set to `NaN`.
- Additionally, as requested by the boje(po), hide the popup
  on click setting on product images.
  
**Alternative approaches:**

1. We can also call the `onSlideCarousel` method from `setup`
    when multiple images are present.
2. Also, we can add a simple check inside the `onSlideCarousel`
    method to ensure that `liEls` is defined before proceeding.

[1]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L31-L57
[2]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L144-L152
[3]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L119-L120

opw-5921123
---

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

**Steps to reproduce:**
* Install  `stock` module.
* Go to the > Settings*, enable *Packages* and
  *Storage Locations*(warehouse).
* Create a storable product and set *Tracking Inventory* to
  **By Quantity** and set some *barcode*
* Update the on-hand quantity for the product and assign it to one packages.
* Open *Barcode > Operations > Internal Transfer* and create a new
  transfer.
* Click the *gear icon* in the top-right corner to open the barcode
  scanning flow.
* manually enter the created product barcode and apply it.
* Click the **Back** button multiple times in quick succession.
* Go to the backend and open the created internal transfer.

**Observed behavior:**
* The internal transfer is created with *double quantities*
 compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
  `exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
  again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
  duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

 * Prevent rapidly clicking the Back button multiple times
 does not multiply quantities.

---
opw-5375899

Forward-Port-Of: odoo/enterprise#109013
Forward-Port-Of: odoo/enterprise#103130

In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is not applicable to physical copies.

Previously, this logic failed during guest checkouts because the partner initially associated with the order is an archived public user. The persistent partner is only created/assigned after the address form is submitted.

This commit:
- Overrides `_create_or_update_address` instead of `_handle_extra_form_data` to ensure the paper format preference is saved on the correct, newly generated partner.
- Updates `_prepare_address_form_values` to correctly load existing preferences from the partner for registered users.
- Ensures the `l10n_tw_edi_is_print` flag on the Sales Order stays in sync with the partner's preference.

Task-5912985

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

Forward-Port-Of: odoo/odoo#247961

Steps to Reproduce  
------------------  
1. Open the Planning Gantt view.
2. Click a cell that belongs to a resource with **no** scheduled shifts.  
3. The Plan dialog opens with an empty list.  
  
Issue  
-----  
A previous change  keeps the clicked resource in the dialog context; the Gantt 
model turns it into a default search filter, so only shifts already linked to 
that resource are shown. Unassigned shifts are therefore hidden, preventing 
planners from assigning them by role or availability.  
  
Current Behaviour  
-----------------  
The Plan dialog is always filtered by `resource_id`, which returns no results 
for unscheduled resources, even when they have the right roles.
  
Expected Behaviour  
------------------  
The dialog should list all unscheduled shifts that match the resource’s roles, 
or every unscheduled shift if the resource has no roles, while still preserving
full context for scheduling once a shift is selected.  
  
Fix  
---  
Remove the automatic resource filter from the dialog context in 
`getSelectCreateDialogProps()`. This prevents the unwanted search restriction; 
role defaults remain, so the dialog now displays the correct shifts.  
  
Task-4922525  
Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d

Forward-Port-Of: odoo/enterprise#92100

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#108957
Forward-Port-Of: odoo/enterprise#101579

…bcontracted

**Problem:**
Landed cost added on the receipt of a subcontracted product
do not increase the valuation of the product and do not create 
account move lines.

**Steps to reproduce:**
- create a tracked product with avco perpetual category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product at a unit price 
of 1$ with the same partner as the subcontractor of the bom
- validate the receipt
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- navigate to inventory/reporting/stock
- search for your product and click on the unit cost

**Current behavior:**
1) the valuation of the product was not increased by the value 
of the landed cost
2) open journal items : no account move lines were created for the 
landed cost

**Expected behavior:**
1) the valuation of the product should have been increased:
in the unit cost view, the SBC move should have gone from a 
value of 10 to 20
2) account move lines should have been created with a value 
of 10

**Cause of the issue:**
both issues come from the fact that when creating the 
stock valuation adjustment line, the move linked is the receipt move
when it should be the move of the subcontracted MO linked to the 
receipt.

**fix:** 
if we create the adjustement line with move_id as the move of the MO
(instead of the move of the receipt as it is the case currently) : 
when button_validate is called on the landed cost : 
- when using the remaining quantity, it will be the correct one 
(in our case 10, instead of 0 for the move of the receipt because it's 
actually an internal move) so the account move line are going to 
be created
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L129-L130
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L372-L373
which solves problem 2) 

-  when calling _set_value on the move (which will be the move of 
the MO thanks to this fix), 
https://github.com/odoo/odoo/blob/064407d32f998ceb08601f9e0a6356c94ad10347/addons/stock_landed_costs/models/stock_landed_cost.py#L152
get_value_data will call _get_value_from_extra,
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_account/models/stock_move.py#L392
which uses _get_landed_cost to fetch the landed cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L18
before this fix the landed cost created from the receipt were linked to 
the receipt move so they were not fetched inside _get_landed_cost
which caused problem 1) but now the move_id of the adjustment lines 
is the move of the MO so they are fetched inside _get_landed_cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L7-L12
So now the adjustment lines do impact the valuation of the move of 
the MO which solves problem 1)

opw-5723126

Forward-Port-Of: odoo/odoo#248469

Issue
=====

The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors.

Steps to Reproduce
==================

1. Install `industry_fsm_sale` and `l10n_br`.
2. In the US company:
   - Create a Brazilian customer.
   - Set a fiscal position on the customer.
3. Switch to the Brazilian company:
   - Open the same customer.
   - Set a fiscal position on the customer.
4. Still in the Brazilian company:
   - Create a task for that customer in the Field Service app.
   - Add a product to the task.

Result
======

An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company.

Root Cause
==========

When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company.

Solution
========

Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used.

opw-5270522

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

Forward-Port-Of: odoo/odoo#250115
Forward-Port-Of: odoo/odoo#249482

An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change

Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown

Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0

Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked

opw-5931355

Forward-Port-Of: odoo/enterprise#108495

There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request. But it returns a request object and then executes the delete asynchronously. This would cause a race condition on the init where we would trigger the init of the indexedDB at the same time as we were trying to delete it and it would hang for ~10 seconds before finally launching the POS.

The second more important issue is that after the reset there is a `localData = []`. This would cause the line in `synchronizeServerDataInIndexedDB` `JSON.parse(JSON.stringify(serverData));` to return an empty array so no new models would get created in the indexedDB and the POS would launch with an empty indexedDB.

This commit changes the `indexed_db.reset()` method to return a promise and awaits it before reinitialising the indexedDB. And resets the `localData` to `{}` which fixes the `synchronizeServerDataInIndexedDB`

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

Forward-Port-Of: odoo/odoo#246476