Currently, a traceback occurs when the user tries to generate a payment link and tries to refresh it.

To reproduce this issue:

1) Install `Accounting`
2) Create a confirmed Customer Invoice
3) Generate a Payment link from `Actions`
4) Change the `Amount` and refresh the tab
5) You can see the error in the terminal

Error:- 
```
KeyError: 'installment_state'
```

This traceback occurs because when the user refreshes the tab, 
it executes the `default_get` method, with self as `payment.link.wizard`.

https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/odoo/models.py#L1897-L1899

In that `payment.link.wizard`, we have overridden the `default_get` and updated the values from the `_get_default_payment_link_values` method with the model as `account.move`.

https://github.com/odoo/odoo/blob/4787c91c434c7e22ca030bc7a62588482c24b2ab/addons/payment/wizards/payment_link_wizard.py#L21-L23

The method mentioned above will return a dict containing the `installment_state` key-value pair.

https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/addons/account_payment/models/account_move.py#L128-L132

But `installment_state` is not a field. It is just a variable 
that gets its value from the `_get_invoice_next_payment_values`. 

https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/addons/account_payment/models/account_move.py#L104

So eventually it leads to the above traceback from the below line. 

https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/odoo/models.py#L1897-L1899 

sentry-6058398917

When "Automatic Check-Out" was enabled for the Attendance app, a scheduled action will run every given interval to clock out employees who are still clocked-in after their defined work hours for a day (typically 8 hours.) The issue is that this action was clocking every employee out every time it ran because the condition was comparing a value in seconds to a value in hours, where the former would dominate every time.

This change fixes this by normalizing the units to hours in all calculations.

This can be tested on Runbot by following these steps: 
1) In Attendances > Configuration, check the "Automatic Check-Out" box and set the tolerance to 0. The tolerance won't make much of a difference here because it is measured in hours and we'll find later that we are calculating time in seconds, but this is the tolerance that the customer has set.)

2) In Attendances > Overview, create a new attendance record for any given employee by clicking "New." Set the check-in date and time to be the current time to simulate a small interval of working time. Delete the check-out date entirely so that we functionally have a "checked-in" employee. (You could also clock this employee in using other methods like the kiosk, but I think this way is clear and easy too.)

3) Now that there is a short interval of time for this employee, navigate to Settings > Scheduled Actions > "Attendance: Automatically check-out employees" and run it manually to simulate what would happen when it should run 4 hours later.

4) Observe that the employee has not been clocked out because they have not gone over their allotted work hours for the day: BUG SQUASHED. 💥🐛

opw-4383268

How to reproduce:
- Install documents_hr_payroll
- Go to Marc Demo employee file
- Activate debug and click on View:form item of the debug menu
- Move the field "work_contact_id" in the sheet tag and make it visible
- Return on the Marc Demo employee file
- Set a new work contact for Marc Demo (using the field): newContact
- Go to the payslip and confirm one of the payslip of Marc
- Open HR Payroll directory in the Document App
- The payslip of Marc is present, select it and click on "Share"

The payslip is shared with "Mitchell Admin" and "newContact" so Marc Demo won't be able to see it because it is not shared with the partner of his user.

The problem was that the employee work_contact_id partner was used to give access to the payslip (and as contact of the payslip document) while for some employee, the work contact is different than the partner associated with their user. In that case, the payslip is shared with a partner different than the employee user partner and the employee cannot see the payslip.

We solve the problem by always sharing the payslip with the partner of the employee user if it exists and we fallback only to the work contact if there is no user associated with the employee.

Task-4404015

[FIX] pos_preparation_display: Prevent Cancel When Payment
This commit is a forward port of https://github.com/odoo/enterprise/commit/5108b400d1f7c4b7239fbc3f5651cf9b835d385c.

In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed.

1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order.
2. Add another order with the same product and internal note but with a quantity of 5.
3. In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready."
4. In the POS, reduce the quantity of the second order line (quantity 5) to 4.

Reducing the quantity of the second order line inadvertently reduces the quantity of the first display line (the one in the "Ready" stage).

In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. Commit `55f2b24870b664815fe7b926835d07259608ae09` added the `uuid` field, which allows the correct display line to be adjusted when reducing the quantity in the POS order line.

Added a tour to test the following use case fixed by this commit (only in version 18.0 and above):

1. In the POS restaurant, add a product with a quantity of 1 and an internal note. Confirm the order.
2. Add another order with the same product and the same internal note but with a quantity of 2. Reduce the quantity of the second order line from 2 to 1.
3. Proceed to payment. In the preparation display module, the original display orders are canceled, and new ones are created instead.

opw-4354093

Current behavior before PR:
Actual change in Odoo 18.0 breaks logic for documents without taxable supply date on form.
This cause issues with issuing documents to the past for example bank or cash. If you are trying issue document to past it's overwritten to actual date.


Desired behavior after PR is merged:
I can create bank or cash transaction in the past.

Description of the issue/feature this PR addresses:
According to the Czech VAT Act (Act No. 235/2004 Coll., on VAT), the difference between the date of issuance of an invoice (date) and the date of taxable supply (taxable_supply_date) is regulated as follows:

Taxable Supply Date (taxable_supply_date):

This is the day on which the taxable supply (delivery of goods or provision of services) actually took place, unless specified otherwise.
Date of Issuance of the Invoice (date):

The invoice must be issued no later than 15 calendar days from the taxable_supply_date.
This means that the gap between the taxable_supply_date and the date cannot exceed 15 calendar days.
Example:
Taxable_supply_date: January 1, 2025
Date: Must be no later than January 16, 2025


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