At the end of the year, or when ending collaboration with an employee,
the employer may have to compute (not pay) the gross amount of the 13th
month that the employee is supposed to get, and send it to a Special
Social HORECA Fund.
Then, this fund will take care of the rest of the paperwork to deduct
taxes from the 13th month and send a payslip to the employee.

Since the employer does not pay the 13th month, but the Social Fund, the
employer has to send an equivalent of *12%* of the amount of the gross
salary submitted to the ONSS, each month, to the social fund.
For workers, the percentage is applied on *108%* of the gross salary.

Those values concerning the 13th month do not impact the employee's
payslip, but still have to appear on it. So an "is_informative"
field has been added to tell whether it should be displayed in this
special section of the payslip.

- If you're an employee, then your non-proratized 13th month (i.e.: its
max value) is the wage of your last payslip (i.e.: `employee_id.wage`)
- If you're a worker (*ouvrier*), then the 13th month's max value is
`your hourly wage * average max number of hours per month`

You then need to proratize the result in relation to the number of days
that have really been prestated and assimilated.

**NOTE:**
- **prestated days** are days you have really worked
- **assimilated days** are leaves that still count as a work days (e.g.:
legal leaves)

The sectorial documentation describes multiple proratization methods,
but they are all equivalent to this basic formula:
`(hours you have prested and assimilated / max number of hours you can
prestate or assimilate) * max 13th month you can get`

**These work entries are always assimilable:**
- legal leaves
- extra legal leaves
- public holidays
- small unemployment
- compensatory rest
- civic duties
- public mandates
- union obligations
- strikes
- temporary unemployment
- unemployment force majeure

**These work entries are assimilable with a limit of time per year:**
- maternity leaves: 15 weeks
- union education: 12 days
- military service: 6 months
- compelling reasons: 10 days
- paternity leaves: 10 days
- military reserve calls': 74 days

**The first 12 months of partial incapacities following a total incapacity
can be assimilated.**
But, the partial incapacity must be of at least of 66%, by 66%, they
mean at least 2/3 of the week should be a time off due to the
incapacity.
Since we don't really have a way to define that, as of now, partial
incapacities are not assimilated.

**Long sick leave periods can be assimilated at a rate of _50%_:**
- The period must be uninterrupted and of at least 6 months
- If it's smaller than 6 months, then we can see accross neighboring
years if it continues, and if it is more than 6 months
- If in the end it's more than 6 months, you can assimilate the period
of the current year (max 6 months per year)
- No period can be assimilated twice (e.g.: a period of two years cannot
be assimilated in both years)

**Short sick leave periods can be assimilated:**
- Up to 7 uninterrupted days per year can be counted assimilated. But,
if you have more than a defined threshold of sick leave days, then none
are counted.
- If you have at least a year of seniority, then the threshold becomes 6
months (i.e.: you still have your days if the number of days are below
six months). Otherwise, the threshold is 7 days. In both cases, max 7
days can be assimilated per year.

**Some days after the end of the contract up to the end of the year can be assimilated:**
- All days if the personnel is retired
- All days of early reitrement (aka "Prépension") assimilated at a rate
of 20%
- Max. 6 months for dead personnel

Even though this 13th month is not directly paid by the employer, it
still is a gross wage for the employee, so, the value of the 13th month
should be included in the computation of the CSS (*special social cotisation*)

[PARTENA's sectorial documentation](https://drive.google.com/file/d/1i8bj425ccEW0ZGvNSaQvEV6VIedmLYCS/view):

task-5477296

** For `sale_renting` **

With the introduction of product-less Sale Order Lines in the community version, we noticed that for manually delivered lines, the ordered quantity gets automatically adjusted to match the delivered quantity.

This behavior is unnecessary. The invoicing policy already determines which quantity should be invoiced. By forcing the ordered quantity to match the delivered quantity (especially when delivered > ordered), we end up consistently invoicing the higher value, which is not always correct.

In practice, ordered and delivered quantities commonly differ, so they should remain independent.

** For `sale_commission` **

For commission and achievement reports, productless lines are aggregated under plans having no product restrictions

** For `sale_account_accountant` **

For accural entries non downpayment lines having no display_type are shown instead of restricting only lines having product.

Removed product_invoice_policy field and used the `sale.order.line.invoice_policy` search compute field.

Technical changes

* From now on any SOL should contain name field value as `product.display_name+ "\n" + description` for consistancy with normal SOLs since we show only `line.name` in reports and portal so in case it should contain product name otherwise it could be confusing for customers to see just description.
* Updated renting-specific extensions of `SaleOrderLineProductField` to also patch `SaleLabelTextField`, ensuring consistent behavior when product search is triggered directly from the description field.
* Preserved existing renting configurator and combo behaviors while supporting the new searchable description field flow.
* Removed the automatic synchronization between ordered and delivered quantities for manually delivered rental lines.
* Adapt some tests to company specific Automatic Invoice setting field.

task-6109825

See Also:
- https://github.com/odoo/odoo/pull/259842
- https://github.com/odoo/upgrade/pull/9981