tldr: The init function should not be used in this case for creating records. Doing so results in errors. The content of this init function can be safely moved to the post-init hook

The problem:
In saas~17.2, creating a company with a country can result in the installation of its accompanying localisation. If it is a European country, this will trigger the installation of base_vat too. If project_timesheet_holdiays is installed this can result in the installation of base_vat failing.

The init method described on res_company in project_timesheet_holidays is triggered when the res_partner model is extended, for instance, in base_vat when adding fields. The registry will contain these fields, but the accompanying fields will not yet have been written to the db.

When the project and task are created, a chain of dependencies result in the company's partner being read. In turn, a query is issued using fields from the registry that aren't yet written to the DB, resulting in an SQL error.

Solution:
Move the content of this method to the post-init hook. This is safe to do and works the same way.

task-id: 4060907

Forward-Port-Of: odoo/odoo#173719

Description of the issue/behavior this commit addresses:

The restrictions on fiscal positions using a foreign VAT are too restricitve,
this commits addresses the issue by allowing new scenarios.

---

Desired behavior after the commit is merged :

This commit allows to use a foreign VAT with only a country group which
will automatically set the corresponding country on the FP. For example, you
can now use a Belgian VAT number on the country group Europe and therefore use
that fiscal positions for all countries in Europe which do not have their own.

On a fiscal position with a foreign VAT, this commit allows the user to set a
country which is not the country linked to the foreign VAT. For example, if you
are belgian, you have a warehouse in France and export goods to Germany, you
can create a fiscal position with a french foreign vat and germany as country.

This commit also allows a lot more "duplicates". You can set multiple FP inside
the same country depending on the states/foreign vat you set it up with.

---

enterprise: https://github.com/odoo/enterprise/pull/61969
task-3088020



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

Forward-Port-Of: odoo/odoo#173976
Forward-Port-Of: odoo/odoo#133749

## Issue:
- When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number.

## Steps To Reproduce:
- Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity.
- In the barcode app, adjust the inventory by adding the created product and then save the changes.
- Click on the small pen icon to modify the product's details.
- Observe that when adding the quantities with decimal values, they get rounded up to the nearest whole number.

## Solution:
- In the `_increment` function, when the initial `value` is not a decimal (it does not contain a '.'), the fraction variable is not set, and the rounding defaults to 0. It's important to note that this issue does not occur when the `value` is a decimal, as the split function operates correctly.
- To resolve this issue, instead of relying on the number of digits after the '.' in the `value`, we set the precision based on what is defined in the 'decimal.precision' model. This approach not only addresses the current issue but also resolves the underlying problem initially discussed in this PR https://github.com/odoo/enterprise/pull/53378

opw-3896929

Forward-Port-Of: odoo/enterprise#65974
Forward-Port-Of: odoo/enterprise#62505