Issue:
The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence 

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

Forward-Port-Of: odoo/enterprise#123707
Forward-Port-Of: odoo/enterprise#123633

Issue
-----
Delivery does not always work from/to some cities in Colombia, like Antioquia.

Cause
-----
There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian localisation were padded in

https://github.com/odoo/enterprise/blob/390acf532e8932fd9b9a708382a5e36cdbb35754/delivery_envia/models/envia_request.py#L726-L727

However, some of the colombian cities listed in `l10n_co_edi/data/res.city.csv` have 4 digit codes (like `SANTA FÉ DE ANTIOQUIA`, code `5042`).

https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/l10n_co_edi/data/res.city.csv#L12


These 4 digit codes have to be right-padded to 5 characters before the left-padding to match the official colombian zip codes. See colombian gov official document (PDF download) where the code is actually `05042`.

https://www.dane.gov.co/files/censo2005/provincias/subregiones.pdf

-----
Ticket:
opw-6248252

Forward-Port-Of: odoo/enterprise#123344
Forward-Port-Of: odoo/enterprise#120164

On the website booking page, moving to a later month can show no available times even though the weekly schedule clearly has some.

### Steps to reproduce

- Install Appointments.
- Create a recurring appointment type available on a single weekday (say Monday), with a user or resource assigned and a date range spanning a few months.
- Set `Allow bookings at least` (the minimum booking delay) so that the current time plus the delay falls after this month's last Monday. Close to the end of a month, a day or two of delay is enough.
- Open the booking page: the first month shown is next month, because the delay skipped this month's last slot.
- Click the arrow to move forward one more month.

=> the reached month shows no slots, even though it has Monday availability.

### Cause

The calendar computes availability one month at a time. It builds a list of months, and the browser refers to each month by its position in that list (0, 1, 2, ...). Clicking the next arrow sends that position back to the server.

The server turns the position into a real month by adding it to a start month, which it computes as `now` plus the minimum booking delay. But the list shown to the visitor does not start there: it starts at the month of the first slot that can actually be booked.

These two are usually the same, so the position lines up. They stop matching when the delay moves the earliest bookable time past the last availability day of the current month. In the steps above, `now` plus the delay lands after the month's last Monday, so the first bookable slot is a Monday in the next month. The visitor's list then starts one month later than the server assumes, every position points one month too early, and the server computes availability for a month the visitor is not looking at. The reached month comes back empty.

### Fix

Count the visitor's month position from the same first bookable slot the list starts from, instead of from `now` plus the delay. The navigation offset is passed to the slot computation and resolved against that slot, so the filled month always matches the month the visitor sees.

opw-6353569

Forward-Port-Of: odoo/enterprise#122494

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

When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to access the interface from within the POS app's sub-menu.

This occurs because the dashboard menu triggers a server action (`action_pos_preparation_display_kitchen_display`) to route the user. When a server action has no explicitly defined `group_ids`, Odoo's `_can_execute_action_on_records` method falls back to requiring `write` access on the underlying model (`pos.prep.display`) to execute the code. Since standard POS users do not have 'write' access to this model, the execution engine blocks the routing attempt.

This commit resolves the issue by explicitly appending the POS User group to the server action's `group_ids`.

opw-6305014

**Steps to reproduce:**

- As Mitchell Admin:
    - Settings > Users & Companies > Users > Marc Demo > Access Rights > Sales > set POS to User
- As Marc Demo:
    - Attempt to access Kitchen Display app > observe Access Error
    - POS > Orders > Preparation Display > observe no error


**Current behavior before PR:**

- POS Users receive an Access Error when attempting to access the Kitchen Display app from the main dashboard

**Desired behavior after PR is merged:**

- No Access Error when POS Users access the Kitchen Display app

Forward-Port-Of: odoo/enterprise#121419

**Problem:**
On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist).

**Steps to reproduce:**
1. Create a subscription product with a recurring plan.
2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price).
3. Open the product page on the website.

**Current behavior:**
The page fails with a 500: Internal Server Error during price computation.

**Expected behavior:**
The page loads and shows the discounted recurring price.

**Cause of the issue:**
For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion.

**Fix:**
Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record.

opw-6306105

Forward-Port-Of: odoo/enterprise#121466

### Steps to reproduce:

- In the settings enable: "Storage Locations" and "Consignment"
- Create a storable product and put 1 unit in stock with a set owner
- Go to the barcode app > Operations > Delivery Orders > New
- Scan your product and validate
#### > The owner was not set on the stock move line so that a new quant was created and updated in stock rather than using the available unit.

### Cause of the issue:

The mechanism of prefilling an owner or a package in the barcode app is currently gate-kept behind the existence of a lot name: https://github.com/odoo/enterprise/blob/0be4f71de3420fb9b72fd4e70d48c6cbbbc0ecb4/stock_barcode/static/src/models/barcode_model.js#L1382-L1407
However, the option also make sense for none tracked products.

### Note:

Performing the flow form the backend and adding quantity will generate the move line by setting the owner if possible since the quantity of a move is set via the back end, move lines are generated by looking at the existing quant data's:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2364 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2328-L2330
Setting the same owner on the new move line as on the quant we are going to reserve:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2337 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L1715

Additional subtelties appearing when prefilling for non tracked product:

1. Currently the available quantity is not taken into account to determine if the the value provided to the prefilled is actually
relevant, in particular if there is a quant with an available quantity of 0, it will be used as a valid value to prefill and it will parasit the prefill that could be done by other quants.

2. The location source used to determine the quants taken into account is not set on the first scan since the scan is performed without any existing line:
https://github.com/odoo/enterprise/blob/4f0d25f9fe4ca8ff1b0ecd7900899a2a246ba888/stock_barcode/static/src/models/barcode_model.js#L1387
> This was not problematic with respect to tracked product since the product needs to be scanned prior to the lot, hence there is always a current line when the the lot is scanned.

opw-6050657

Forward-Port-Of: odoo/enterprise#123173
Forward-Port-Of: odoo/enterprise#115021

Bug :
	- Create a new employee (also works with old employees)
	- Create an allocation of Paid Time Off that is available in the future.
	- Create a Time Off request for this employee in the future.
	- When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. 

Reason :

clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today

Fix :
pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation.


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

Forward-Port-Of: odoo/odoo#273670

…chinese

## Current behavior:
When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN).

## Expected behavior:
When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal should show up in traditional Chinese (zh_TW) also.

## Steps to reproduce:
In Odoo 19.0,
1. Install modules: payment_ecpay, website, ecommerce
2. Change the company and website language to Traditional Chinese (zh_TW). Make sure the currency is in TWD (Taiwanese Dollar)
3. Add ECPay as a payment method
4. Add some test products and checkout with ECPay
5. Observe the language on ECPay portal website, and payload in V5 package in network tab

## Cause of the issue:
Initially the locale mapping was wrong, mapping CHI to zh. There's no "zh" locale, must either be "zh_TW" or "zh_CN".
So when the Odoo locale is set to traditional Chinese (zh_TW), it included Language=CHI in the payload and redirect to ECPAY, making ECPay think that we're trying to request the simplified Chinese site. Caused by commit: 76c81d6f67b54940879b1020068c7140c4f2199b

## Fix:
Fixed the language mapping following ECPay developer docs, and what language code to be included in the payload sent to ECPay from current Odoo locale.

opw-6270820

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

Forward-Port-Of: odoo/odoo#269206

_**Steps to reproduce:**_

* Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings.
* Switch to a Polish company.
* Create an EU customer with a valid VAT number.
* Create a sale order containing a service product taxed with **0% EU S**.
* Confirm the sale order and create a down payment invoice.
* Send the invoice to KSeF and inspect the generated XML.

**_Observed behavior:_**

* The generated KSeF XML does not contain the `P_13_9` field.

**_Cause:_**

* For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` was not being assigned during XML generation, causing the tag to be omitted from the exported KSeF document.

**_Fix_**:

* Populate the value of `P_13_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML.
* This PR updates the computation of tag `P_13_10` to ensure consistency with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

opw-6294181

Forward-Port-Of: odoo/odoo#270986

Issue:
-------
When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor.
for ex: `#snippet-anchor` in the `Button URL` field in the settings.

Cause:
--------
This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place.

Solution:
------------
To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on.
This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside.

Steps to reproduce:
-----------------------
1. Create a db in version 18.3 with website_sale installed.
2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings.
3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button.
4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings.
5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet.

Ref PR:
----------
https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399

Attachments:
-----------------
**Before Fix:**
[vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0)


**After Fix**:
[vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5)


- OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517)


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

Forward-Port-Of: odoo/odoo#249110
Forward-Port-Of: odoo/odoo#247587

Currently when the user reverts an inventory adjustment move line with a package the package contains extra line showing negative quantity of the product.

## Steps to produce:
- Install Inventory without demo data
- Settings Enable 'Packages'
- Create a product:
   - Cheese burger
   - On hand > Create a new quant
   - Package: 'Burgerbox' and 'On Hand Quantity`: 1 and save
- Set the On Hand quantity to zero and save
- History > Revert the Inventory adjustment line from WH/stock to Inventory adjustment by selecting it and reverting via actions.
- Products > Packages > BurgerBox

## Observed Behaviour:
After reverting an inventory adjustment that set the product's physical quantity to 0, the package contains two lines for the same product with quantities 1 and -1.

This is inconsistent because a package should not contain a product with a negative quantity.

The package should be restored to its original state and contain only the expected positive quantity.

## Root cause:
When the user reverts the move line, `action_revert_inventory` is called. This method creates the revert move and then marks that move as done at [1].

Marking the move as done subsequently marks all related move lines as done at [2]. During this process, the system first unreserves the quantity from the virtual location / inventory adjustment and then removes the quantity from that location (resulting in a -1 quantity move line at that location). This is performed through `_synchronize_quant`, which is responsible for synchronizing the physical inventory with the move line at [3].

The `_synchronize_quant` method uses the move line's `package_id` when updating the corresponding quant at [4]. As a result, `_update_available_quantity` creates a new quant with the following values at [5]:
```
{
    'product_id': 1,
    'location_id': 14,
    'lot_id': stock.lot(),
    'package_id': 1,
    'owner_id': res.partner(),
    'in_date': datetime.datetime(2026, 6, 22, 12, 42, 11),
    'quantity': -1.0,
}
```
This creates a quant with a negative quantity that is linked to the package because `package_id` is set on the newly created quant. Consequently, the move line with the negative quantity becomes associated with the package.

[1]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L1016-L1035 
[2]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move.py#L1956 [3]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L662-L666 
[4]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L678-L687 
[5]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_quant.py#L1130-L1143
## Solution:
Remove the source `package_id` when creating revert moves for inventory adjustment locations.

When an inventory adjustment sets a product's quantity to 0, the adjustment is completed without a destination package, meaning the product is effectively removed from the package. Therefore, the corresponding revert move should not retain the package as its source. Keeping the package as the source is inconsistent because package information should not exist on a virtual inventory adjustment location, and the original inventory adjustment removes the product from the package (there is no destination package).

By removing the source `package_id` from the revert move, the system avoids creating negative quants associated with the package during quant synchronization. This also ensures that, after the inventory adjustment is reverted, the quantities of products inside the package are restored correctly and match their state prior to the adjustment.

opw-6285739

Forward-Port-Of: odoo/odoo#274167
Forward-Port-Of: odoo/odoo#271440