[FIX] account_invoice_triple_discount: allow discounts over 100%

[dcatarino]

Problem

triple.discount.mixin redefines the core discount field of account.move.line, and write() redirects any write of discount into discount1. Core discount has no upper bound (account/models/account_move_line.py#L371-L375), so CHECK (discountN <= 100.0) rejects values that Odoo itself produces and stores.

account_edi_ubl_cii infers the discount percentage from the imported amounts, uncapped:

• account_edi_ubl_cii/models/account_edi_common.py#L842-L847

  inferred_discount = 100 * (1 - (price_subtotal - charge_amount) / currency.round(delivered_qty * price_unit))

• account_edi_ubl_cii/models/account_edi_ubl.py#L3061-L3067
• account_edi_ubl_cii/models/account_edi_ubl.py#L3543-L3547

and it does so with rounding deliberately disabled, so the raw value is stored as-is: _disable_discount_precision forces the Discount precision to 13 digits (account/models/decimal_precision.py#L6-L13).

A vendor credit note whose price_subtotal has the opposite sign of quantity * price_unit therefore yields exactly 200%:

quantity = -2, price_unit = 15.47, discount = 200.00000000000017, price_subtotal = 30.94

Installing this module on a database that already holds such a line aborts the whole upgrade, because post_init_hook copies discount into discount1 after the constraints have been created:

new row for relation "account_move_line" violates check constraint
"account_move_line_discount1_limit"

The constraints cannot prevent the situation either — they are created while discount1 is still NULL, so they always apply successfully and only fail later, on data that was already valid under core Odoo.

Reproduce

1. On a database with account_edi_ubl_cii installed, import a Peppol vendor bill or credit note whose line amounts imply a discount above 100% (or simply UPDATE account_move_line SET discount = 200 WHERE id = <any line>).
2. Install account_invoice_triple_discount.
3. The install aborts with the constraint violation above.

Fix

Remove the three CHECK (discountN <= 100.0) constraints.

This is safe:

• The computation already handles values above 100%: discount1 = 200 gives a factor of -1 and an aggregated discount of 200.
• The bound was one-sided — negative discounts (surcharges) remain allowed and are exercised by test_01_discounts, which sets discount1 = -5.
• The message "must be lower than 100%" did not match the SQL, which allowed exactly 100.

No migration script is needed: the constraints are reflected as ir.model.constraint xml_ids, so ir.model.data._process_end() drops them on upgrade.

Added test_08_discount_over_100 as a regression test.

Note

19.0 carries the identical constraints (ported to models.Constraint) and needs the same fix. Happy to open the forward-port once this is agreed.

[StefanRijnhart]

Maybe replace them with ORM constraints? This will allow us to keep the feature, as well as an easy override option if not desired. Such a change would also be compatible with the installation on existing databases that have one or more existing lines with a discount > 100.