Scenario:

- install website, event
- add a form in website with action "Create Event Registration"
- add a field Event in that form
- send the form with an event that would accept registration

Result: the registration is saved but you see "An error has occured, the
form has not been sent." and server side you see this traceback:

  File "addons/website/controllers/form.py", line 45, in website_form
    with request.env.cr.savepoint():
  …
  File "/Users/odoo/src/odoo/18.0/odoo/sql_db.py", line 119, in _close
    self._cr.execute('RELEASE SAVEPOINT "%s"' % self.name)
  …
  psycopg2.errors.InvalidSavepointSpecification: savepoint "…" does not
  exist

Cause: creating an event.registration calls
event.registration()._update_mail_schedulers which depending on
configurations might end up sending mail after which we commit the
transaction (probably to avoid sending an email two times) but this
deletes all the current savepoints. So even if everything is commited,
successfully, the __exit__ method of the savepoint will raise an error
when trying to close a savepoint that is already deleted.

Fix: ignore cases where there has not been any error, but the savepoint
has been deleted before being released.

opw-4599918

### Issue:

It happens due to many reasons that the `stock.quant` object and the `stock.move.line` loose their synchronization and it could have a difference between the sum of `stock.move.line` and the quantity/reserved quantity on the stock.quant.
Starting from 18.0: Commit 766ec99dbc2701a237f082f3fb124793d9dfe596 the action `_clean_reservations` is called in the `_quant_tasks` to reconcile both. However, this action is performed in `inventory_mode` when we access quant view:
https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L394-L398 https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L1301-L1304 In certain cases this causes an invalid operation. For instance because we can not create a quants in a location that does not belong to a company`inventory_move`. This happens because the company_id of the quant will be false:
https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L57 But the `company_id` of the product will not and hence will fail the `check_company` performed for inventory_move:
https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L306-L311 https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/odoo/models.py#L4354-L4355

### Steps to reproduce:

- In the settings enable intercompany transactions and multi-step routes
- Create a storable product P and set the product company_id
- Create an internal transfer from the inter-company transit to stock for 1 unit of P
- Confirm the picking and set a quantity of 1
- Delete the quant that was created in inter-company transit with a reserved quantity of 1 (this can be done via a server action).
- Inventory > Reporting > Locations
> Invalid operation: inter-company transit belongs to company "False"
and product "P" belongs to an other company.

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

Versions
--------
- 18.0+

Steps
-----
1. Have a combo product;
2. confirm a quotation with the combo product;
3. fully invoice confirmed quotation;
4. go back to quotation.

Issue
-----
The "Create Invoice" button is still visible. Clicking on it will create an invoice with only the combo product on it (none of its constituent products).

Cause
-----
Commit 602ef86b8dcad changed how combo product lines get invoiced. Instead of display type `product`, they get displayed as `line_section` lines.

The `_compute_qty_invoiced` method requires the line to have linked `invoice_lines` that have a `quantity` value to properly calculate the quantity invoiced, and later on, the quantity to invoice: https://github.com/odoo/odoo/blob/bac9ed6d84ff64ef39741cb66afdf565c7e9f221/addons/sale/models/sale_order_line.py#L907-L913

Because these values aren't passed when creating an invoice line, the `qty_to_invoice` value of the combo product line will never be 0.

Solution
--------
Pass the requisite fields to the invoice line create values, along with the `optional_values` to ensure the correct `sequence` value gets used.

opw-4633972

### Summary
This PR introduces a new module, `hotel_restaurant_pms`, designed for hotel and restaurant businesses. The module includes functionalities for managing hotel rooms, guests, bookings, and restaurant POS orders. It also integrates with fiscalization printers to ensure compliance with local tax regulations.

### Features
1. **Hotel Room Management**: Manage rooms with attributes like type, rate, and availability.
2. **Guest Management**: Register guest information for tracking and invoicing purposes.
3. **Booking System**: Handle hotel room bookings with check-in/check-out and automated billing.
4. **Restaurant POS Integration**: Provides an interface for menu management and order processing.
5. **Fiscalization Support**: Integrates with fiscal printers to comply with tax regulations, enabling direct printing of invoices with fiscal data.
6. **Real-Time Data Synchronization**: Ensures seamless syncing between the PMS and POS components for smooth operations.

### Technical Details
- **Models**: Defines core models for `hotel.room`, `hotel.guest`, `hotel.booking`, `restaurant.menu`, and `restaurant.order`.
- **Views**: Provides form views for easy data entry and overview of rooms, guests, bookings, menu items, and orders.
- **Fiscal Printer Service**: Adds a service to send invoice data to fiscal printers, enhancing compliance capabilities.
- **Dependencies**: Built on top of the Odoo `base` and `point_of_sale` modules.

### Test Instructions
1. Install the module within the Odoo instance.
2. Set up test data in each of the models (rooms, guests, bookings, etc.).
3. Create bookings and restaurant orders to validate that invoices and stock movements are correctly generated.
4. Test fiscalization by printing an invoice with a fiscal printer (requires compatible hardware setup).

### Contribution Checklist
- [x] Module code is structured following Odoo guidelines.
- [x] Views and models are modular, promoting scalability and maintainability.
- [x] Fiscal printer integration has been tested in a local environment.
- [x] Documentation included in each model explaining field usage and constraints.

### Additional Notes
This module provides a valuable integration for hotel and restaurant businesses, especially in regions where fiscal compliance is essential. Feedback on additional features or improvements is highly welcome.

Thank you for reviewing this PR!