Currently, a missing exception is triggered when reopening a PoS session after a partner is deleted.

**To reproduce this issue:**

1) Install point_of_sale and pos_settle_due.
2) Open a PoS session
3) Create a customer and place an order with payment. 
4) Without closing the session, go to the backend. 
5) Delete the customer from Contacts.
6) Reopen the previously opened PoS session.

**Error:**
A `missing record` exception is triggered.

**Cause:**
When the user reopens a PoS session after deleting a partner, 
the method `setAllTotalDueOfPartners` is triggered during setup.
https://github.com/odoo/enterprise/blob/7c6ba26970698cb60121157c2cca0e414d5b62a0/pos_settle_due/static/src/app/services/pos_store.js#L7-L9
https://github.com/odoo/enterprise/blob/7c6ba26970698cb60121157c2cca0e414d5b62a0/pos_settle_due/static/src/app/services/pos_store.js#L44-L48

This method makes an RPC call to `get_all_total_due` to update all partners' due amounts.
Since the partner was deleted, this causes a missing record exception.
https://github.com/odoo/enterprise/blob/7c6ba26970698cb60121157c2cca0e414d5b62a0/pos_settle_due/models/res_partner.py#L28-L32

**Solution:**
Before calling `get_total_due`, verify the partner still exists in the database.

Related Community PR:- https://github.com/odoo/odoo/pull/219809

opw-4897814

Forward-Port-Of: odoo/enterprise#90596

Currently, a partner can be deleted even if they have associated PoS orders.
This causes inconsistent behavior, such as missing record tracebacks 
when reopening a PoS session.

**To reproduce this issue:**

1) Install point_of_sale and pos_settle_due.
2) Open a PoS session
3) Create a customer and place an order with payment. 
4) Without closing the session, go to the backend. 
5) Delete the customer from Contacts.
6) Reopen the previously opened PoS session.

**Error:-**
A `missing record` exception is triggered.

**Cause:**

- Starting from SaaS-18.1, PoS supports offline mode with limited functionality, due to this commit:
https://github.com/odoo/odoo/pull/184417/commits/711e248efd54500f91acfb1b9a30f48177c34925

- Before this commit, data was reloaded whenever a session was opened or reopened, 
ensuring proper synchronization with the backend.

- After this commit, IndexedDB is used to cache data and it is reused every time the session is reopened.

- When the user reopens a PoS session after deleting a partner, the method 
`setAllTotalDueOfPartners` is triggered during setup.

- This method makes an RPC call to `get_all_total_due` to update all partners due amounts.
Since the partner was deleted, this causes a missing record exception.

**Solution:**

- Prevent users from deleting a partner who has PoS orders and an open session. 
- Before calling `get_total_due`, verify the partner still exists in the database.

Related Enterprise PR:- https://github.com/odoo/enterprise/pull/90596

opw-4897814

Forward-Port-Of: odoo/odoo#219809

Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged.

Cause:
- The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns.

Fix Applied:
- Updated frontend (`filters.js`) to call `format_column_values_from_client` via
  `dispatch_report_action` instead of calling `format_column_values` directly.
  (this enables proper routing through the custom handler system)
- Added `format_column_values_from_client` override in `JournalReportCustomHandler`
  that intercepts the formatting call and applies special handling for tax summary
  lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines`
  monetary fields using their `_no_format` counterparts.
- The custom handler then delegates to the base method via
  `report.format_column_values_from_client()` to format standard columns.
- Also added missing `_no_format` fields in `account_journal_report.py` for
  `base_amount` and `tax_amount` to enable proper reformatting.

Forward-Port-Of: odoo/enterprise#98508
Forward-Port-Of: odoo/enterprise#94660

Steps to Reproduce:
- Create a Sale Order containing two combo products placed consecutively.
- Change the quantity of the first combo → corresponding combo items update correctly.
- Without saving, change the quantity of the second combo.
- Observe that the combo items now appear misplaced — items from the second combo are inserted before those of the first combo.

Issue:
- The order of combo items becomes incorrect when multiple combo products are updated consecutively in the same unsaved Sale Order.

Cause:
- During `onchange`, the `self.order_line` recordset reflects the *in-memory order of applied commands* rather than the database `sequence` field because they are not saved in the DB during the edition.
- Each `onchange` rebuilds `order_line` using concatenated command lists (`delete + create + update`), So when multiple combos are modified without save, newly created combo items are appended according to command evaluation order — not by logical grouping.
- This causes combo items to shift relative to their parent combo lines.

Solution:
- Restrict the recomputation of order lines to non-combo lines by filtering out combo item lines during the rebuild. As combo items will always be in their desired sequence.
- This ensures that combo items always stay under their respective parent combos and their sequence is preserved, regardless of the order in which combos are updated.

opw-5148770
Affected Version:18.0

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

Forward-Port-Of: odoo/odoo#233740

### Issue:

Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors.

### Steps to reproduce:

- In the settings enable "Batch Transfers"
- Inventory/Operations/Transfers/Batch Transfers
- Create a new batch and do not confirm it
- Go to the barcode app > Batch Transfers > Clear filters
- Select your draft batch
- Scan anything
#### > Traceback

#### Other issues:

The same flow with a cancelled batch triggers the same tracebacks and, with a done batch triggers the message: "This picking is already done".

### Cause of the issue:

Since `this.state.view === "barcodeLines"`, scans are processed as if we were processing an existing `BarcodePickingBatchModel` with lines: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/components/main.js#L204-L209 In particular, if the scan corresponds to a product, and error will be raised because the scan can not process a `createNewLine` for the scanned product in the current view and if the scan does not correspond to anything valid, it will raise an error because `this.picking` is undefined and `this.picking.use_existing_lots` raises an error:
https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/models/barcode_model.js#L1115 https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L177-L179

opw-5162164

Forward-Port-Of: odoo/enterprise#98022
Forward-Port-Of: odoo/enterprise#97526

```
  File /home/odoo/src/odoo/saas-18.4/addons/website_sale_product_feed/models/product_feed.py, line 105, in _check_product_limit
    raise ValidationError(feed.env._(
odoo.exceptions.ValidationError: A single feed cannot contain more than 5,000 products. Please separate products with Categories.
```
```
(Pdb) feed.env['product.product'].search_count(feed._get_feed_product_domain())
12433
```
During migration I am getting the traceback mentioned above, which is occurring because [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/__init__.py#L14) we have populated feed records in _post_init_hook which will create feed records without any [category ID](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/website.py#L21) because of which, [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/product_feed.py#L101) we get all records without a category, which is of course higher than our soft limit of 5000, and a validation error occurs: the customer database does not have GMC enabled. Still, it calls _populate_product_feeds, which is why I have moved it to a condition.

opw-5180407

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