Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next invoice date of the subscription. This occurs if the client does not specify a timesheet period when creating the invoice. For example, the user invoices a subscription for the period of July 1st to July 31st and the next invoice date of the subscription is August 1st. There are timesheets dated in July and a timesheet dated August 1st. The quantity delivered for the invoice will only include timesheets within the July period. However, the linked timesheet to the invoice will mistakenly include the timesheet from August 1st.

Purpose: Although the linked timesheet has no effect on the computation of qty_delivered for the current period, the timesheets dated the same as the next_invoice_date will get linked to the invoice and no longer be considered as delivered hours for the next period, which could cause gaps in hours delivered. The next_invoice_date should not be
included in the date range when linking timesheets within the period of the invoice, since these hours were not included in the computation of quantity delivered.

Steps to reproduce on Runbot:
1. Install Sales, Project, Timesheet
2. Enable Timesheet in Project > Settings
3. Create a service product that is based on timesheet and creates project and task on order
4. Create a quotation for the service product and set the recurrence to be monthly and
set the start date to be the first of the past month
5. Confirm the quotation and set the next invoice date to be the first of the current month
6. Create timesheet hours within the period and one dated to be the first of the current month
7. Create an invoice for the subscription and notice that the timesheet from the first of the current month is linked to the invoice.

opw-4689894

Forward-Port-Of: odoo/enterprise#92368
Forward-Port-Of: odoo/enterprise#92250

The new appointment_google_reserve module allows to make your restaurant (or other booking based service) available to book via Google Maps Reserve. See: https://www.google.com/maps/reserve
https://developers.google.com/actions-center/verticals/reservations/e2e/overview

The integration works alongside with the IAP server, that plays the middleman between the client server and the Google servers.

It is split in three main concepts:

1. The Feed files uploads

See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/export-feeds

The Google Reserve Service is based on data coming from "feed files", which are manually uploaded once per day via a HTTP call to the IAP servers.

IAP servers will take care of the Merchant and Service feed files based on the merchants that registered for this service.

The merchant/service registration happens via a HTTP call to the IAP server when an appointment.type is configured accordingly.

This is simply done on the appointment.type form by specifying the "merchant" (which is a physical address and some contact details).

The same merchant could be re-used between several appointment.types, for example if a hotel allows booking rooms (1 appointment.type) and massages (with a second appointment.type): the merchant is the hotal (same physical location) and the services are both appointment.types.

The availabilities for all these services are uploaded to the IAP server with a HTTP call when the IAP server requests them.
(See IAP commit message / documentation for more details).

2. The Booking Server

See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/implement-booking-server

Once a end-user books something from Google Maps Reserve, they (Google) will hit a certain endpoint on the IAP server with the booking details.

IAP then needs to relay this information to the merchant (client)'s, acting as a proxy. The information is then stored accordingly, for example as a new calendar.event record on the related appointment.type.

The same principle is applied to other necessary concepts; modify bookings, cancel bookings, ...

3. Real-time API updates

See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/real-time-api-updates

This is in a way the same thing as the booking server, but the other way around.

Whenever something happens that modifies availabilities for an appointment, including:
- Creating a booking directly in the backend
- Creating calendar leaves for the appointment resources
- Modifying opening hours
- ...

We need to update the availabilities on Google's side.

In that case, the communication is thus initiated by the client server, that contacts IAP. IAP acts as a proxy again by relaying this information to Google.

===============================================================================

Limitations:
- Only works for auto-assign mode appointment types
- Payment and sales related flow are not implemented.

Task-3083812