## Short functional explanation of the error
When a user checks in, a mail is sent in the chatter, containing a button 'Check out Visitor'. When a user who should have access to the Check Out feature clicks on the button, we are redirected to a 'Not Found' page.

## Reproduction Steps
1. Go to Frontdesk. Click on Open Desk and check in a visitor.
2. Go back to the Frontdesk app. Click on visitors.
3. Click on the visitor you just checked in.
4. Click on the 'Check Out Visitor' button in the chatter.

### Expected behavior
A page should appear with the text:
'The visitor has been successfully
 checked out'.

### Unexpected behavior
A 'Not found' page pops up.

## Origin of the issue
We filter users who can benefit from the check-out feature using groups. However, the group used to perform this filter is written incorrectly, leading to a condition that is always True, and always returning a request not found.

__
opw-5937326

Forward-Port-Of: odoo/enterprise#110022
Forward-Port-Of: odoo/enterprise#108331

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#113023
Forward-Port-Of: odoo/enterprise#107671

Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.

Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
    - Enable Lots/Serial Numbers > Create New
- Create a product
    - Barcode 23456789012344
    - Tracked by SN
    - 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details

> The line used the reserved SN

Cause
-----
The existing line gets matched in `_findLine`

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085

because none of the conditions before

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402

get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.

Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).

-----
Ticket:
opw-5216921

Forward-Port-Of: odoo/enterprise#112528
Forward-Port-Of: odoo/enterprise#109671

In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.

Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
    -  Never variant with at least two values
    -  MTO and manufacture
* Create a bom,
    - Company : company B
    - Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant

Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.

opw-5438723

Forward-Port-Of: odoo/enterprise#113031
Forward-Port-Of: odoo/enterprise#107122