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

## Steps to reproduce
- Install **Payroll**, **Planning** and **Time Off** apps
- Create a new working time of 56 hours per week:
	- Go to **Payroll** app
	- Go to **Configuration** > **Working Times**
	- Create a **NEW** working time -named 56 hours/week- that has 7 days (Monday to Sunday), each from **8:00** to **16:00**
	- Set a time zone of your choice, in my case it Africa/Cairo
- Go to **Employees** app and create a **NEW** Employee -named 56 hours/week employee- with the same time zone as the new working time
- Create a new Contract for the newly created employee:
	- Click on the Contract smart button
	- Click on **CREATE**
	- Set the **Contact Start Date** -ex. 1 Feb 2024-
	- Set the **Working Schedule** to the newly created working time (56 hours/week)
	- Set the **Work Entry Source** as **Planning**
	- Set the state of the contract to be **RUNNING**
- Create a 10 day planning:
	- Go to the newly created 56 hours/week employee
	- Click on the Planning smart button
	- Click on **NEW** to add a new Shift (example values):
		- from 20 Feb 2024
		- to 29 Feb 2024
		- from 8:00 to 16:00
	- Click on **PUBLISH**
- Go to the newly created 56 hours/week employee. Click on the Work Entries smart button. Set the view as _list_. We now have a planning of 10 days totaling 80 hours.
- Create a time off:
	- Go to the newly created 56 hours/week employee
	- Click on the Time Off smart button
	- Click on a day to request a time off -for our example set as 23 Feb 2024-
	- Go to the **Time Off** app > **Approvals** > **Time Off**
	- Remove **My Team** filter
	- Approve the newly created time off
- Go back to the Work Entries of our employee
- Click on **REGENERATE WORK ENTRIES**
- Set the Work Entries in _list_ view
- Notice how the duration of the last work entry is **_incorrectly_** calculated:
	- The 1st entry has 24 hours for 3 days of work (20 Feb, 21 Feb, 22 Feb) which is CORRECT
	- The 2nd entry is for the time off having 8 hours for 1 day (23 Feb) which is CORRECT
	- The 3rd entry has **24** hours! although it's for 8 days (24, 25, 26, 27, 28, 29 Feb) totaling **48** hours. There are **24** hours difference (3 days), which actually (3 holidays in my case)

## Investigation
#### First, let's see how we reach to recalculating the duration (allocated hours) of the planning slots:
- When the work entries are regenerated, the slots durations are recalculated via `_get_duration_batch()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L43 more precisely  `_get_planning_duration` which recompute the durations by creating new temporary planning slots -notice how we didn't pass the `resource_id` of the slot-https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L29-L36 passing the values from the original slot but the new start and end date.
- That triggers `_compute_allocated_hours()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L239 
#### Second we'll examine three cases:
1. What if the slot has no resource_id ? (This is actually the issue specific to the ticket, the `resource_id` is not passed)
	- the `planning_slots` will be empty, while the `slots_with_calendar` will have our respective slot which triggers the `if slots_with_calendar:` block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248
	- As we have no resource, we fall back to the `company_id.resource_calendar_id`  which is the standard 40 hours/week https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L269-L271
	- We then go into `_get_working_hours_over_period()` which will use the `company_id.resource_calendar_id` as it has no `resource_id` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1677-L1679
2. What if the slot has a resource with `flexible_hours = False`? Same as 1
3. What if the slot has a resource with `flexible_hours = True`?
	- the `planning_slots` will will have our respective slot https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248
	- which will trigger this block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L249-L252
	- going into the `_calculate_slot_duration()` function that has a drawback:
		- The period is a timedelta object https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1106 that has days (`period.days`) which is the number of full days in that period and seconds (`period.seconds`)
		- if the `period.seconds` is not ZERO that means we have a non-full day.
		- when `max_duration` is calculated we always round up the days by adding 1 https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1108 even though `period.seconds` can be 0. in that case we should only take `period.days` into consideration

## The Fix:
- By passing the `resource_id` when creating the new temporary slots, we make sure we are dealing with the correct `resource_calendar_id`
- The `_calculate_slot_duration()` modification addresses the issue when `resource_id` has `flexible_hours = True` basically if the employee work with flexible hours

opw-3662389

Forward-Port-Of: odoo/enterprise#58409
Forward-Port-Of: odoo/enterprise#57205

###   [FIX] event: Include unregistered attendee emails in total sent count
  
  Before this commit the Email Sent Count (located in the Communication
  tab of the event view) wasn't including emails sent to the attendees who
  weren't confirmed.
  
###   [This commit changes]
  Event mail scheduler will include seats_uncofirmed into calculation of
  the mail_count_done which is the count of emails sent. This is
  reflecting the actual number of emails sent.
  
###   [Reproduce]
  - Create event E starting in time T (Events/Events)
  - Add an "Unconfirmed" attendee
  - Add an E-Mail in the Communication tab of the event E
          - Set Interval time > T,
          - Template: "Email Reminder"
          - Trigger "Before the event"
  - Run scheduled Action sending email (Scheduled Actions / Event: Mail Scheduler)
  - BUG: email sent, but not included in the sent count in the communication tab of the event E
  
  opw-3693626

# Merge plan
in 16.3 We are adding whatsapp to fix bundle. Since whatsapp is present in the enterprise repo, fix was put in there. Unfortunetally since `event_test_full` is not depending on the `whatsapp_event` I need to create additional test just for the 
whatsapp module. Enterprise PR: https://github.com/odoo/enterprise/pull/58428

![image](https://github.com/odoo/odoo/assets/33809926/9a549d8a-7318-4162-b55f-b221542cd7c3)

Forward-Port-Of: odoo/odoo#156907
Forward-Port-Of: odoo/odoo#153795

Description of the issue/feature this PR addresses:

The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of the main warehouse location should be considered as a out move. The inverse condition doesn't make much sense.

Current behavior before PR:
Let's use a simple example:

- create a new product.
- create an outgoing movement from shelf 1.
- click on "Replenisment" menu. No orderpoint for the new product.

![image](https://github.com/odoo/odoo/assets/23449160/02033177-205f-4720-88a6-08086f4c23b3)



Desired behavior after PR is merged:

A new orderpoint should have been created at WH/Stock for that product. See below with the fix:

![image](https://github.com/odoo/odoo/assets/23449160/c13bd827-d0be-4605-b750-52059c9cb991)

@ForgeFlow

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

Forward-Port-Of: odoo/odoo#157287
Forward-Port-Of: odoo/odoo#156903

### Steps to reproduce:
- Install **Sales**, **Accounting** and **Inventory** apps.
- Go to **Inventory** > **Configuration** > **Products** > **Product Categories**.
- Open **All / Saleable / Office Furniture** and:
	- Set the Inventory Valuation as **Automated**
	- Set the Costing Method as **First In First Out (FIFO)**
- Go to **Inventory** > **Reporting** > **Inventory Valuation**
- Open the toggle header then Click on the plus button at the header.
- In the popup shown -Notice how the current value is 0-, set:
	- Added Value to **1000**
	- Counterpart Account to **600000 Expenses**
- Click on **REVALUE**, a new report appears.
- Open the newly created report > **Other Info**, open the **Journal Entry**.
- In the Journal Items tab, notice the label says that `the valuation was changed from 1000 to 2000` while it should be `the valuation was changed from 0 to 2000`.

### Investigation:
- the `current_value_svl` field is related to `product_id.value_svl` https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L34
- Which get computend using `_compute_value_svl()` depending on `stock_valuation_layer_ids`
- When we revaluate, we trigger `action_validate_revaluation` that performs this line https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L110 creating new stock.valuation.layer triggering the `_compute_value_svl()` method setting the product `value_svl` to the updated value (current + added) which then updates `current_value_svl` being a related field
- That's why now `current_value_svl` is the _new_ value and not the _old_ one.

opw-3715522

Forward-Port-Of: odoo/odoo#154239