Steps to reproduce:
-
- Go to Field Service app and create a new task.
- Use the smart button to access the catalog and add a product.
- Go back to the task and use the smart button to access the SO.
- Set the unit price of the added product to zero.
- Create the associated invoice.

**You are allowed to create the invoice and aline will be displayed for the SOL corresponding to the products with a unit price of zero.**

Notes: This is the expected behavior for invoices generated from regular SO. However, AJU the PO of the Field Service application decided to change this behavior for invoices generated from SO coming from field services see task 3266856 and commit 849241e (the SOL invoice status should be 'no').

Cause of the Issue:
-
When you create an invoice from a sale order, the `invoiceable_lines` are computed at this point:
https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1251-L1258 by the `_get_invoiceable_lines` method. As one can see in this method: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1220 if the `qty_to_invoice` of SOL is positive, the SOL will therefore appear in the `invoiceable_lines` and the associated invoice line will be created a few lines below to appear on the invoice: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1276-L1279

Fix:
-
In order for the SOL to not generate an`invoiceable_line` we set the `qty_to_invoice` to zero when the SOL comes from a field service task and display a product with a unit price of zero.

Notes: To keep the flow coherent between the `qty_to_invoice` and the `invoice_status` of SOL for field services SO and since `price_unit` is a float that should not be compared using an `==` we also changed the float comparaison of the `_compute_invoice_status` method introduced in the commit 849241e.

opw-3776475
---

Forward-Port-Of: odoo/enterprise#58609
Forward-Port-Of: odoo/enterprise#58057

Steps to reproduce:
-------------------
- being in Europe/Brussel timezone;
- create a contract based on attendance from 1st to 31st January;
- create two attendancescfot the employee linked to this contract:
    - 5th January from 8am to 4pm for example (A)
    - 31st January from 00:30am to 8:30pm (B)
- create a payslip for the employee from 1st to 30th January;

Issue:
------
The attendance count on the smart button on the payslip and the number of records on the list view (when the smart button is clicked) are not the same.

Cause:
------
The domain that determines attendance uses a condition on the `check_in` field, which is a datetime field, and compares it with a date. For attendance B, we will compare 2024-30-01 23:30:00 with 2024-30-01 23:59:59.

As a result, attendance B will validate this condition.

Solution:
---------
Make this information consistent by using the same logic and taking account of timezones.

Add a method that allows you to retrieve all attendances linked to a payslip. Use this to generate the domain that will select the correct records (based on their id) in the list view.

Note:
-----
`_read_group` manages timezones and therefore
`check_in:day` for attendance B returns 2024-31-01.

opw-3794161

Forward-Port-Of: odoo/enterprise#58587
Forward-Port-Of: odoo/enterprise#58431