Issue:
----------------------------------------
There is a fiscal regime where the company is actually an individual but is authorized to generate documents.

Steps to reproduce:
----------------------------------------
- Install "l10n_mx_hr_payroll_account_edi"
- Change the current company fiscal regime to '621'
- Add an VAT of length 13 to the current company
- Add a CURP number on the current company
- In Payroll generate a payslip, validate it
- Post the Journal entry
- On the payslip, click "Generate CFDI"
- An error is returned, saying the Emisor:Curp applies to individuals

Cause:
----------------------------------------
An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'.

We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML.

Solution:
----------------------------------------
We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present.

opw-6351558

## Steps to reproduce:

1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
   1. Tax Regime set to individual
   2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
   1. Customer set to the copy created earlier.
   2. Operation Type set to Sale of Goods
   3. Document Type set to 55
   4. Payment Method Brazil set to Money
   5. Presence set to Present
   6. One sales order line with:
      1. Regular Consumable Product
      2. quantity set to 1
      3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.

Explanation:

PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.

However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.

opw-6085964

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

task-6215466

Forward-Port-Of: odoo/enterprise#124400
Forward-Port-Of: odoo/enterprise#122313