1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#105405
Forward-Port-Of: odoo/enterprise#100749

### Issue:
When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date.

### Steps to reproduce:
- Install 'sale_subscription'
- Create a new Subscription with two lines and a tart data several months in the past
- One with a quantity of 1 and a higher price
- The other with a quantity of -1
- It can be the same service product with invoicing based on ordered quantity
- Confirm the Subscription
- Click "Create Invoice" and confirm the invoice
- Back to the Subscription, the next invoice date was not updated.

### Cause:
In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131

So the method will return not return the date in `invoice_dates`.

Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67

### Solution:
The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds.

To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund.

opw-5360930

Forward-Port-Of: odoo/enterprise#103705

l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended

**STEP TO REPRODUCE**
1. Create a invoice with:
    - product price = 72.89
    - discount = 10%
    - tax = 16%
2. Duplicate the invoice until you have 5 of them.
3. Create a global invoice with the 5 invoices, and send it.
4. The invoice will be refused by the EDI due to rounding issue.

This PR is a backport of multiples fixes done in 18.3 in which all rounding errors are fixed.
Each of them iterate upon the previous one, so they are all needed. The most important changes in thoses fixes are:
    - for global invoices, deduce the discount on the base line instead of creating a 'descuento' (to avoid any problem with rounding when combining multiples invoices).
    - changes in how the negative lines are dispatched.
    - using raw values for 'conceptos' and 'impuestos' (5 digit precision) and changing how we compute things to solve rounding issue.

Tests files are modified accordingly, you can launch the tests with the external flag (need to be set in tests/common.py).

Backported PR (non-exhaustive):
https://github.com/odoo/enterprise/pull/92727
https://github.com/odoo/enterprise/pull/99395
https://github.com/odoo/enterprise/pull/90434

opw-5382423

Forward-Port-Of: odoo/enterprise#105615