Steps to reproduce:
-------------------
1. Install `sale_project_stock` and Accounting.
2. Create a storable product with **Real-time valuation** and 
configure the COGS account in the product category expense account.
(Ensure you have enabled automatic & analytic accounting from accounting>config.)
3. Create a project with a specific analytic account and ensure the project is billable.
4. Create a sale order with the created product and set the same
analytic account in the analytic distribution.
5. Confirm the order, deliver the product, generate the invoice, and post it.
6. Open the project and go to the *Profitability* report.
7. Click on the **Cost of Goods Sold** dashboard item.
8. Repeat steps 4–7 with multiple invoices.

Issue:
------
When there is only one invoice, clicking the COGS dashboard item correctly
displays the related move lines. However, when there are multiple invoices,
the action opens with empty results.

Cause:
------
`_get_action_for_profitability_section` sets `res_id` only when a single record exists. 
When multiple records are present, `res_id` becomes `False`, which causes the action to open without results. https://github.com/odoo/odoo/blob/8f79d407724f40ba8e48f1747b2e87311b7fb49e/addons/project_account/models/project_project.py#L78-L83

Solution:
---------
When `res_id` is not set, search `account.move` records using the
domain to retrieve the relevant move IDs, then apply a proper domain
to display all related COGS journal items.


opw-5949261



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

Forward-Port-Of: odoo/odoo#267097
Forward-Port-Of: odoo/odoo#253639

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

### 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

Version:
---------
- saas-19.2+

Steps to reproduce:
-------------------

- Install `mrp` and `knowledge`
- Open Knowledge and create an article
- Add a clipboard block and write some text
- Go to Manufacturing → Operations → Manufacturing Orders
- Create a new Manufacturing Order
- Open the `Miscellaneous` tab
- In the `Additional Notes` field, click the Knowledge icon(Top right corner)
- Search and open the created article

Issue:
------
The Knowledge article does not display the
`Use As Additional Notes` action.

Cause:
------

The Knowledge clipboard integration detects compatible editable HTML fields
 from the active form view through `form_controller_patch.js`.

The detection first checks whether the field:
- is part of `KNOWLEDGE_RECORDED_FIELD_NAMES`,
- is an HTML field,
- and is writable.

```
The `note` field already satisfies the first condition: const KNOWLEDGE_RECORDED_FIELD_NAMES = [
    'note',
    'memo',
    'description',
];
```
However, the detection logic also filters out readonly fields:

```py
fields[name].type === "html" &&
!fields[name].readonly
```

In `mrp.production`, the `note` field is computed `Html` field:

```py
note = fields.Html(
    string="Additional Notes",
    compute='_compute_note',
    store=True,
)
```
Since computed fields are readonly by default unless explicitly marked
otherwise, Odoo exposes the field as readonly at the model level.

Even though the form view contains readonly Flase:

https://github.com/odoo/odoo/blob/9b9c72cc2c2ec0f7f5a74b39a11044b5f21f5d2e/addons/mrp/views/mrp_production_views.xml#L583

the Knowledge detection relies on the model field definition rather than
the view attribute. As a result, the `note` field is filtered out and
the clipboard action is never proposed.

 Fix:
-----

Mark the computed `note` field as writable by setting
`readonly=False` in the model definition.

This allows the Knowledge clipboard detection to recognize the field as
a valid editable HTML target and restores the
`Use As Additional Notes` action in Manufacturing Orders.

---

opw-6209675


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

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

#### 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

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

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#119785
Forward-Port-Of: odoo/enterprise#118957