Description of the issue/feature this PR addresses:
The current contact UI is partly inconsistent regarding the child/parent behavior and also it is not flexible extensible regarding new contact types like "Home office Contact", which is a "Contact" but has a different Address, and also an "Delivery Address" is in my opinion not an individual, but neigther a company. 

Therefore I suggest to de-couple the different topics and add new variables. These variables can be customized by overwriting the 
"_compute_contact_type" method according to the users needs.

e.g. you could add a new individual type "home office contact" which is an individual, but also has an editable address.
By changing can_be_child to True on Company contacts, you could create multi-level company structures.

In this patch, the current behavior is not changed, but gives better possibilities for customizations.

Current behavior before PR:
The forms are hardly customizable regarding new contact types.

Desired behavior after PR is merged:

The UI can be more customizable and using is_address_readonly, is_individual, can_be_parent and can_be_child instead of linking the type directly.


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

The problem:
With the introduction candidate/applicant models in 18.0 a subtle bug got introduced. The core of the bug is that most of the field on an application are related/inherited from the candidate of that application except company_id. This means that both models have a company_id and those are not synced. This can become an issue in a multi company issue where a candidate is assigned to company A while their application is in company B. The recruiter in company B will then get constant access errors because they don't have write permission on a record(candidate) in a different company.

The fix:
This PR aims to fix this by doing 2 things.
1. Every time the company on a application gets changed the company of the candidate is also updated. This still means that if the company of the candidate is manually changed we will have this issue again but there's no way around that (that can be implemented in stable).
2. Makes sure that candidates created through the website are assigned to the company of the job posting or no company, preventing a mismatch from happening.

There was also trace-back happening on the job application form on odoo.com as a warning message div is missing there for some reason so I added a simple condition to check if that div exists to prevent the trace-back.

task-4350838

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

The problem:
With the introduction candidate/applicant models in 18.0 a subtle bug got introduced. The core of the bug is that most of the field on an application are related/inherited from the candidate of that application except company_id. This means that both models have a company_id and those are not synced. This can become an issue in a multi company issue where a candidate is assigned to company A while their application is in company B. The recruiter in company B will then get constant access errors because they don't have write permission on a record(candidate) in a different company.

The fix:
This PR aims to fix this by doing 2 things.
1. Every time the company on a application gets changed the company of the candidate is also updated. This still means that if the company of the candidate is manually changed we will have this issue again but there's no way around that (that can be implemented in stable).
2. Makes sure that candidates created through the website are assigned to the company of the job posting or no company, preventing a mismatch from happening.

There was also trace-back happening on the job application form on odoo.com as a warning message div is missing there for some reason so I added a simple condition to check if that div exists to prevent the trace-back.

task-4350838

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

**Issue**
When generating the XML for a credit note, the <Imposta> field (tax amount) appears as a positive value, whereas it should be negative in compliance with Italian EDI standards.

**Steps to Reproduce**
1. Install the Accounting module and Italian localization.
2. Create and confirm a vendor bill using a service-type product.
3. Reverse the bill into a credit note.
4. On the credit note, go to the Journal Items tab.
5. Assign tax 22% S RC and confirm.
6. Click Send Tax Integration.
7. Inspect the generated XML: <Imposta> appears as positive.

**Root Cause**
The XML generation logic for tax lines does not consider the type of the accounting move. As a result, for credit notes (in_refund or out_refund), the tax amount (<Imposta>) remains positive, even though it should be negative to reflect the refund nature of the document.

**Fix**
The tax amount is inverted for credit notes to ensure the XML reflects the correct financial direction. This distinction prevents misreporting, as positive values in a refund context would contradict e-invoicing standards.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4831091)
opw-4831091

### Issue:
The structure of the bis3 XML for a credit note with an early discount is invalid.

### Steps to reproduce:
- On a partner set the E-Invoicing format to "BIS Billing 3.0"
- Create an invoice for this partner, confirm, send
- Create a credit note from this invoice
- Add a payment term with early discount to the credit note
- Confirm and send to BIS Billing
- The generated XML has a bad structure: https://peppol-tools.ademico-software.com/ui/document-validator

### Cause:
The field `AllowanceCharge` should be after `Delivery`, `PaymentMeans` and `PaymentTerms` ([doc](https://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/maindoc/UBL-CreditNote-2.1.xsd)).

UBL_20 template adds `AllowanceCharge` before `TaxTotal` ([code](https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/account_edi_ubl_cii/data/ubl_20_templates.xml#L570)). UBL_21 template adds `Delivery`, `PaymentMeans` and `PaymentTerms` before `TaxTotal` again ([code](https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/account_edi_ubl_cii/data/ubl_21_templates.xml#L67))

As the UBL_21 template inherits frome the UBL_20 template it gets triggered after so `AllowanceCharge` ends up before `Delivery`, `PaymentMeans` and `PaymentTerms`.

### Solution:
UBL_21 template now adds `Delivery`, `PaymentMeans` and `PaymentTerms` before `AllowanceCharge`.

opw-4812408

Forward-Port-Of: odoo/odoo#218316

When you have product with dynamic variants using extra price, the price
added to the cart is not correctly computed.

Steps to reproduce:
-------------------
* Create a product with a dynamic variant (2 values), price 1
* Add an extra price for each value, ex 10, 20, 100
* Make a sale order with the first two variant value
* Open shop
* Add the product to the order 3 times, 1 for each value
> Observation: Prices are respectively: 21, 41, 111

Why the fix:
------------
In the shop only `product.product` are shown. When selecting the product with variant, the product has a `lst_price` of 11 which corresponds to the price of the `product_template` plus the extra price. This value is normal but cannot be used in the computation of `get_price` as we also provide the value for `extra_price`.

We can use `list_price` instead of `lst_price` as it does not include the information related to variants.

Why do we see 2 different behaviors before this fix? When selecting a variant option, if the product with this variant already exist, the lst_price already contains the information about the selected variant. Which explains why, in the end, the price has twice the extra price of the variant selected.

When the product with the variant does not exist, the price has one time the price of the selected variant plus one time the price of the first product with variant the is created.

Configurable products were also having issues when mixing multiple variants, especially when one of them had creation mode set to "always". When exiting the configuration popup the payload does not include the extra price coming from "always" attributes. depending on what the other choices were we would have an extra price, meaning we would compute the price with `list_price` but the extra price did not include the information about the "always" variant if it had one.

Using `list_price` is enough for the initial problem but only when the selected DYNAMIC variant has an extra price otherwise the code does not pass through the condition asking for extra price. In such case there is no extra price from the payload and it's still computing the price with `lst_price`, which includes information about the extra price of the variant that was already sold previously. Thus we make sure that we compute with `list_price` whenever a configurable product is added.

opw-4815555