Issue
-----
Enabling signature requirement blocks US -> US deliveries.

Steps to reproduce
-----
- Setup UPS
	- enable signature requirement
- Set current company to US
- Create a US Customer
- Create a product with some weight
- Create a SO for the product
- Add UPS delivery and try to get a rate

> Error: "The requested accessory option is unavailable between the selected
locations."

Cause
-----
Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link)

https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US

US50 -> US50 & Canada -> Canada is package level
Everything else is shipment level

By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value.

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911

For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421

-----
Ticket:
opw-6173624

Forward-Port-Of: odoo/enterprise#117564

Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.

## Steps to produce:
- Install the Inventory module
- Go to Settings and enable Storage Locations.
- Inventory > Configuration > Operation Types > Internal Transfers > Barcode App
- Configure the Destination Location to require scanning after each product.
- Create an Internal Transfer for Pedal Bin, demand 1.
- Mark the transfer as To Do and open it in the Barcode app.
- Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493).
- Delete the newly added line and attempt to Validate.

## Observed Behavior:
The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line.

## Root cause:
This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates.

As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned.
[1]:
https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] :
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]:
https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948

## Solution:
We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product.

To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed.

However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned.

To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily.

opw-6069614

Forward-Port-Of: odoo/enterprise#119499
Forward-Port-Of: odoo/enterprise#113618

Before this fix:
The credit limit warning calculation only considered credit notes but ignored outstanding bank payments 
when computing the partner's effective outstanding balance. For example, if a customer had a credit limit
of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning 
would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the
actual outstanding amount was only 500.

After this fix:
The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases 
are handled:
- Bank payments received but not yet matched to any invoice, these are identified by their open suspense
  account entry and deducted from the partner's outstanding exposure.
- Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable
  line and deducted accordingly.

So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500
and does not show a warning since it is within the 1,000 credit limit.

task-5427613

Forward-Port-Of: odoo/enterprise#119691
Forward-Port-Of: odoo/enterprise#118957

### Issue:
In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled

However, these fields must only be used for EU countries

For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors

### Cause:
`_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries

As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU

Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create a customer in Switzerland with a valid VAT number
- Create and confirm an invoice for that customer
- Go to Accounting → Audit Reports → General Ledger
- Select the full year
- From the gear menu, export DATEV DATA (zip)
- Open the `EXTF_customer_accounts` file

### Before the fix:
`EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty

### After the fix:
`EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled

`Land` is filled using the following priority:
1. Partner country_code
2. Country extracted from the VAT number
3. Empty

opw-5902565

Forward-Port-Of: odoo/enterprise#119593
Forward-Port-Of: odoo/enterprise#113835

Opening the Inventory Valuation report iterated every storable product to compute total_value, which on large catalogs used several GB of RAM and timed out workers.

The report now searches only products that have stock (under the same valuation context that total_value uses) or that are lot-valuated, and feeds that smaller set into stock_value and stock_accounting_value. For historical (at_date) reports the search runs with to_date in context so qty_available is scoped to that date. _get_accounts_by_product() also switches to search_fetch so only categ_id is loaded upfront.

Benchmarks were measured on a customer database restore with ~360k storable products. After filtering, ~2.5k products feed into the valuation today and ~2.2k for a historical date.

Benchmark opening Inventory Valuation report (Accounting)
| Date       | Before | After  | Speed up |
|------------|--------|--------|----------|
| Today      | ~88s   | ~2s    | 41x      |
| Historical | ~245s  | ~173s  | 1.4x     |

The historical improvement is more modest because stock_value still has to compute total_value at the historical date for the remaining products, which traces SVL/stock.move history; the filter eliminates the dominant per-product overhead today but only the tail in the historical case.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#254010

When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it show any warning.

Steps to reproduce:
-------------------
* Install barcode and stock
* Enable packages in settings
* Open Inventory
* Create a product,
* Create a Package Type -> barcode PACKTYPE,
* Create a Package linked to this package type -> PACK,
* Add at least 2 unit of product to this package,
* Create a delivery for 2 unit of the product,

Open Barcode
* Operation > Delivery orders > your delivery
* Erase the destination package from the first line
* Scan PACK
( don't click on the green line)
* Scan PACKTYPE

**Actual behavior**
create a new package but does not link it to the new products

**Expected behavior**
create a new package and set it as destination package.

Observation:
-------------
When scanning the package (PACK), we will go through ```_processPackage``` -> ```async _processPackage``` where in the end the line is unselected:
https://github.com/odoo/enterprise/blob/39d8a473fe03038ca0494a6a8165e3eb75bd8492/stock_barcode/static/src/models/barcode_picking_model.js#L2090

When we scan our package type (PACKTYPE), we will go to ``` _processPackage``` -> ```_processPackage```->```_processPackageType```  
where we will obtains packagesIds checking that we have a source package:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2123-L2132
and will send us to ```_putPackInPack```:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2133-L2136

Where we will avoid the empty packageIds since we checked on the source package and not the destination package:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2296-L2299
and will call ```action_put_in_pack``` from the packaging model:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2301-L2306

In ```action_put_in_pack``` will create a new packaging and put it as a the new destination package, but since the ```previous_dest_package``` (saved in db) was itself, he will [erase the link](https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_package.py#L354-L363) he just made.

Which means that in our case, we created a package without linking it to anything.

Even if we avoid the function to erase the destination package, since the destination package shown in barcode is the one from move line :
https://github.com/odoo/enterprise/blob/d0d0a3cf4a02bf24cf502b533e494fe7ca155eb3/stock_barcode/static/src/components/line.js#L115-L117
It will not show the new package in barcode


opw-5449729

Forward-Port-Of: odoo/enterprise#104876

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

getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days.

So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1.

The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week.

### Current behavior before PR:

At the end of 2026, this will cause problems because the week number will run as:

* 2026, week 52 (all days in 2026, OK)
* 2027, week 53 (most days in 2026, last day in 2027, Not OK)
* 2027, week 1 (all days in 2027, OK)

### Desired behavior after PR is merged:

This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as:

* 2026, week 52 (no changes)
* 2026, week 53 (year is not incremented if week number is not reset)
* 2027, week 1 (no changes, but year is incremented when week number is reset)

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

Forward-Port-Of: odoo/odoo#267871
Forward-Port-Of: odoo/odoo#267656

### *Why this commit*: 
---
Ensures Quality Checks and Mass Produce options remain available on the
Shop Floor regardless of the "Auto-close Production" setting.

### *Steps to Reproduce*
---
1. Define a product tracked by Serial Numbers with a Manufacturing BoM.

2. Create a Quality Control Point for the product on the Manufacturing
operation.

3. In Inventory Configuration, disable "Auto-close Production" on the
Manufacturing operation type.

4. Create a Manufacturing Order (MO) and open it in the Shop Floor view.

5. If the MO has no operations, try to use Mass Produce.

### *Before this PR*
---
When auto_close_production was set to False, the Shop Floor card footer
incorrectly hid both the Quality Checks and Mass Produce buttons.
This blocked users from registering Serial Numbers and completing mandatory
quality check steps.

Additionally, for products without BoM operations, clicking Mass Produce 
triggered quality check validation instead leading to errors, preventing the
generation of serial numbers.


### *After this PR*
---
The visibility logic for Shop Floor actions is now decoupled from the closing
permission. The workflow follows this corrected sequence:

Mass Produce: Stays visible to allow serial registration and backorder
creation even if the MO cannot be closed from the Shop Floor.

Quality Checks: Remain accessible to ensure all mandatory tests are
passed before production progresses.

Close Production: Only appears if "Auto-close Production" is enabled
on the operation type.


OPW: 5473839

Forward-Port-Of: odoo/enterprise#115529
Forward-Port-Of: odoo/enterprise#103926

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119597
Forward-Port-Of: odoo/enterprise#118759

#### Description of the issue/feature this PR addresses:
In the Singapore localization (l10n_sg), reverse charge is modelled as a group tax pairing a -9% SRRC child with a +9% TXRC child, so the GST on a bill nets to zero while both legs are still reported in their respective GST return boxes. The child taxes "9% TXRC-TS" and "9% TXRC-ESS" shipped inactive, while their siblings "9% TXRC-N33" and "9% TXRC-RE" shipped active. Because children_tax_ids is a many2many onto account.tax (which has an active field), inactive children are filtered out of the group, so the groups "Reverse Charge - SRRC + TXRC-TS" and "Reverse Charge - SRRC + TXRC-ESS" only kept the -9% SRRC leg and computed a wrong GST amount, while leaving the +9% leg out of the GST return.

#### Current behavior before PR:
A vendor bill of S$10,000 taxed with "Reverse Charge - SRRC + TXRC-ESS" (or "+ TXRC-TS") shows 9% GST = -S$900.00 and a total of S$9,100.00 instead of net S$0.00 / S$10,000.00. The +9% TXRC leg never reaches Box 5 / Box 7 of the GST return. The sibling groups "+ TXRC-N33" and "+ TXRC-RE" are unaffected because their children are active. The only workaround is to manually activate the two child taxes.

#### Desired behavior after PR is merged:
The "9% TXRC-TS" and "9% TXRC-ESS" child taxes are active by default, so the group taxes aggregate both legs: a S$10,000 bill shows 9% GST = S$0.00 with a total of S$10,000.00, and both reverse charge legs land in their GST return boxes. New SG databases get this from the tax template; existing SG databases get the two taxes reactivated by a migration on upgrade.

opw-6199248

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

Forward-Port-Of: odoo/odoo#267670

Summary
=======

`_check_if_used_in_website_form`, the ondelete hook on
`ir.model.fields` that guards against deleting a field referenced by
a website form, performs poorly on realistic databases. It can take
multiple minutes to validate a single field deletion, blocking user
actions such as removing a Studio field.

This commit restricts the scan to columns that can actually contain
website form markup, bringing the hook from multi-minute to
sub-second without any loss of coverage.

The Problem
===========

Deleting any `ir.model.fields` record triggers this validation hook,
which must ensure the field is not referenced inside any website
form. The implementation iterates every stored HTML column returned
by `website._get_html_fields()` and runs one case-insensitive
`ILIKE '%data-model_name="<model>"%'` search per column against
`<model>.<html_field>`, then parses each match with `lxml` and
validates it with XPath.

Two root issues cause the multi-minute cost:

- **Unbounded scan surface**: all stored HTML columns are scanned
  (~95 on realistic databases), even though the vast majority of them
  declare `sanitize=True` and `sanitize_form=True` (the defaults).
  When both flags are True, `<form>` tags are stripped on write and
  the column can never physically contain website form markup.
- **Per-column `ILIKE` cost**: `ILIKE` on large TEXT/JSONB columns
  performs a sequential scan. A single large HTML column is enough
  to make the hook run for several minutes on its own.

Improvements
============

- Scan only columns that can actually contain forms:
  - `ir.ui.view.arch_db` , primary target; all website forms are
    stored there.
  - HTML fields whose sanitization either is disabled
    (`sanitize=False`, e.g. `blog.post.content`,
    `website.custom_code_head`) or explicitly allows forms
    (`sanitize_form=False`, e.g.
    `product.template.website_description`, `hr.job.description`,
    `event.event.description`). Any other HTML field strips `<form>`
    on write and will never contain a form.
- Batch searches: group the deleted fields by model once and emit a
  single `OR`-domain search per candidate column, instead of one
  search per (field, column) pair.
- Parse each returned record with `lxml` and validate with XPath
  directly. The `ILIKE` domain already filters out non-matching rows
  DB-side.

Benchmarks
==========

Profiled on a database containing ~95 stored HTML columns and ~5.2k
views. The hook was invoked read-only via
`field._check_if_used_in_website_form()` on a custom field.

| Metric                         |     Before |      After |
| :----------------------------- | ---------: | ---------: |
| Hook wall time                 |     ~444 s |    ~173 ms |
| HTML columns scanned           |         95 |          5 |
| SQL queries issued             |         96 |          6 |

Key results:

- Hook wall time reduced from multi-minute to sub-second
  (~2,570× faster on the profiled database).
- Scan surface reduced from ~95 columns to a handful (1 +
  the form-capable HTML fields installed on the database, typically
  under 10).

opw-6086536

Forward-Port-Of: odoo/odoo#268666
Forward-Port-Of: odoo/odoo#259846

Steps to reproduce:
---
- Install `website_sale`.
- Create a product and from the Sales tab, add alternative products, making sure all products are published on the website.
- Open the main product on the website.
- In the alternative products section, open the editor, click the `brush` icon under `card design`.
- Under Actions > Buttons, click on the `cart` icon.
- Save the changes and click the `Add to Cart` button on an alternative product.

Issue:
---
- Clicking the `Add to Cart` button on alternative products does nothing.

Root cause:
---
- At [1], the `AddToCart` interaction uses the selector `.oe_website_sale button[name="add_to_cart"]` to find and attach click handlers. When the dynamic snippet renders alternative products, `startInteractions` is called on the `.dynamic_snippet_template` div. It searches for the button inside that div, but at [2], no element wrapping the button has the `oe_website_sale` class in the rendered product card template. So the selector matches nothing, and no click handler is attached.

Fix:
---
- Add `oe_website_sale` to the `o_wsale_product_btn` wrapper div in the product card template so the button becomes a descendant of `.oe_website_sale` within the injected content, allowing the interaction to attach correctly.

[1]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/static/src/interactions/add_to_cart.js#L5
[2]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/templates/snippets/product_snippet_template_data.xml#L95-L113

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

Steps to reproduce:
- Ensure you're not in dev mode(`--dev xml` disabled)
- Create ≈200 custom website snippets
- Go into website edit mode
- Traceback appears

Because of the high number of snippets, rendering the snippets templates exceeds the 1024-entry template cache limit. Earlier compiled templates are evicted from the LRU cache and may need to be processed a second time during the same render.

The second compilation reuses the etree stored in the transaction preload cache. As this etree was already consumed by the first compilation, the resulting output can contain empty snippet wrappers and crash the website editor.

This commit always copies preloaded etrees before compilation so the transaction cache retains a clean tree that can safely be processed again after an eviction.
A fix was already done for the same error in [1], where it was only done for dev mode.

opw-6230580
opw-6270833
opw-6276599

[1]: https://github.com/odoo/odoo/commit/f04a5cfee1a5c43824b04dec89712414b79e6cff

Forward-Port-Of: odoo/odoo#268550

A product can have expiration date (use_expiration_date) enabled after being changed from lot/serial tracking to no tracking (quantity).

The issue this causes is that it can open the expiration popup since from saas-18.4 there is a line where if `ml.removal_date <= datetime.datetime.now()` the picking is expired.

So, if the product previously met these conditions, it will still be able to enter this flow.

And since this product doesn't use a lot_id it displays “You are going to deliver the product False, False which is expired or should at least be removed from stock”

What should happen:
When a product is not tracked, use_expiration_date should be False as expiration dates are intended to be managed through lots or serial numbers.

Steps to reproduce
1. Enable Product Expiry.
2. Create a storable product with:
- Tracking: By Lots
- Use Expiration Date: enabled
- Set a value greater than 0 for removal_time
3. Change the product tracking to By Quantity.
4. Create and validate a receipt for the product.

Related Tickets: opw-6255673

Forward-Port-Of: odoo/odoo#268135

**Steps to reproduce:**
1. Log in as a portal user.
2. Open a shared project and then open any task within it.
3. Observe the vertical spacing above the Follow/Unfollow button and the chatter 
component.

**Issue:**
The chatter UI has incorrect vertical spacing, causing elements like the
Follow/Unfollow button to sit too far down and appear misaligned.

**Cause:**
The pt-2 padding class was hardcoded in two separate locations: 
1. The compileChatter wrapper in project_sharing_form_compiler.js.
2. The portal.Chatter XML template.
When combined this caused a double-padding effect forcing excessive space.

**Fix:**
Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and 
the core XML template. This eliminates the double-padding conflict. This resolves 
the alignment issue in Project Sharing and does not affect the layout or 
functionality of other portal components.

task-4203362

Forward-Port-Of: odoo/odoo#268977
Forward-Port-Of: odoo/odoo#257490