**PROBLEM**
When scanning two gs1 barcode with the same serial number, but for different products there is an error and the 2nd product is not added to the inventory count.

**STEP TO REPRODUCE**
1. install stock_barcode
2. activate the gs1 barcode and select the default gs1 nomenclature.
3. scan the following barcode
- 01000000000001232180085 (product barcode: 0000000000123, serial: 80085).
- 01000000000000482180085 (product barcode: 0000000000048, serial: 80085).
4. there is an unexpected error notification, and the 2nd product line isn't added.

**CAUSE**
In _processBarcode (barcode_model.py), we only check if:
- there is already a line with serial tracking with a non-null qty
- this line serial number is the same serial number that we are scanning

**FIX**
We should also verify if the product from the lines we are checking, and the line we want to create are the same.

[opw-5076045](https://www.odoo.com/odoo/project/49/tasks/5076045)

Forward-Port-Of: odoo/enterprise#96430

Steps to reproduce:
1. Create a resource with a "Working Time" calendar set with flexible hours
2. Create an appointment with this resource
3. Go to the website and try to book an appointment with this resource
4. Error 404 not found.

When booking appointments with resources that have flexible calendars, the system returns a 404 error during slot validation.

The issue occurs in `_check_appointment_is_valid_slot` (appointment controller) which validates that a slot is still available before allowing booking. This validation calls `_unavailable_intervals_batch` (resource.calendar) to check resource availability.

For flexible resources, `_unavailable_intervals_batch` generates inverted time intervals (e.g., start=18:30, end=18:00) which causes the overlap check to fail incorrectly, making valid slots appear unavailable.

This regression was introduced when the distinction between "fully flexible" (no calendar) and "flexible" (calendar with flexible_hours=True) was added. The check was only applied for fully flexible resources, leaving regular flexible resources broken.

Solution: Skip unavailable interval computation for both `_is_fully_flexible()` and `_is_flexible()` resources, since flexible resources by definition have no fixed unavailable periods.

opw-5026825

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

**PROBLEM**
Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should).

**STEP TO REPRODUCE**
1. install pos
2. create a lot tracked product
3. create a pricelist rule for the product, with a price based on min qty
4. from the pos, order the min qty but split it accross multiple lots
5. price will not takethe rule into account

**CAUSE**
Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually.

**FIX**
For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked.

**REMARK**
Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db.

opw-4751920

Forward-Port-Of: odoo/odoo#219110

Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is:
- We edit a move line lot in the form view;
- We save it;
- We validate the operation.

The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped.
With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored.

To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour.

To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts.

Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331)