Errors := TLandrixEInvoice.Check(Invoice, Target, [], Diagnostics);Check runs the checks of SaveTo* without writing and returns the number of errors
SaveTo* would refuse on. Overloads exist for the three syntax models.
- The business rules of the target: EN 16931 (BR-...), the calculation rules (BR-CO-10 to
BR-CO-17), the VAT category rules (BR-S-..., BR-Z-..., BR-E-..., BR-AE-..., BR-IC-...,
BR-G-..., BR-O-..., BR-AF-..., BR-AG-..., BR-B-01, BR-B-02, BR-CO-03, BR-CO-04, BR-CO-09,
BR-CO-18), the other BR-CO rules (reasons, seller identifier, payment terms), XRechnung
(BR-DE-...), Peppol (PEPPOL-EN16931-...), the code list rules of XRechnung and Peppol (BR-CL-...)
and the rules of Factur-X EXTENDED (BR-FXEXT-...). Each violation is an entry of kind
edk_RuleViolationwith its rule identifier inRuleID. - For Factur-X, the code checks of the Factur-X Schematron (FX-SCH-A-...) on the CII syntax
model as it is written, also for a CII model you pass to
CheckorSaveTo*directly. - Everything the mapping reports: content the target or its Factur-X profile cannot hold
(
edk_NotAllowed), required content that is missing (edk_MissingElement), values that cannot be converted.
The rule check predicts what the KoSIT validator would report for the written document. It does not replace the validator: schema and Schematron checks of the official configuration remain the reference, and the library runs them too, without Java (Validating). Not checked yet, among others: the other FX-SCH-A rules of the Factur-X Schematron (cardinality, required attributes). The format rules BR-DE-17, BR-DE-19, BR-DE-20 (IBAN check sum), BR-DE-27, BR-DE-28 and BR-51 are checked; all of them are warnings except BR-51 in CII.
The PEPPOL-EN16931 rules that the XRechnung Schematron contains as well apply to XRechnung and Peppol: R003 (Peppol only), R005, R010, R020, R040 to R042, R046, R053 to R055, R061, R110, R111, R120, R121 and R130. They compare amounts, prices and quantities exactly as they are written, with the tolerance of the Schematron (0.02; XRechnung 0.5 for the invoice currency HUF) and its division of the price by the base quantity (18 decimals, rounded half down, as the Saxon processor of the validator computes it). R120 (line net amount) is a warning in XRechnung and an error in Peppol. Not every rule can fail on what the library writes: a percentage, base amount, gross price or base quantity of 0 is not written, and the model holds one VAT total per currency.
For Peppol, the rules that only the Peppol Schematron 3.0.21 contains are checked as well: the
other PEPPOL-EN16931 rules (notes, profile, type codes, exemption reason codes, the Peppol code
lists), PEPPOL-COMMON-R040 to R057 (formats and check digits of identifiers by scheme, e.g. GLN,
Norwegian, Danish, Belgian, Italian, Swedish and Australian numbers) and the national rules of
Germany (DE-R-...), Denmark, Greece, Iceland, Italy, the Netherlands, Norway and Sweden. A national
rule applies when the Schematron's country condition holds for the written document (the VAT
identifier prefix or the postal country of seller and buyer). Rules the UBL writer always meets
(for example the date format or the specification identifier) need no check. The OpenPEPPOL unit
tests of the release are the reference (tools/rulecheck/peppol-oracle.py).
The code list rules BR-CL-01 to BR-CL-26 use the lists of the validators (XRechnung 3.0.2,
Peppol BIS 3.0.21). They are slightly older than the code lists of the library: the currency
STD is accepted and STN is not, CII accepts the country AN and not SS, the VAT category B is
accepted, the EAS codes 0219 and 0220 are accepted, and in UBL the 18 newest note subject codes
are not. Codes are compared case sensitively after removing blanks around them, the VAT
exemption reason code (BR-CL-22) after upper-casing it and the MIME code (BR-CL-24) exactly as
written. XRechnung reports BR-CL-21 and BR-CL-23 as warnings, and when the invoice is written
with the XRechnung extension it does not report BR-CL-10, 11, 21, 24, 25 and 26. UBL writes the invoice type code 381 as
ubl:CreditNote and every other code as ubl:Invoice, so a code of the credit note list such as
261 violates BR-CL-01 in UBL.
The Factur-X code checks have one identifier per profile (for the invoice type code
FX-SCH-A-000555 in EN 16931, FX-SCH-A-000635 in EXTENDED). Each compares the value as written,
unchanged and case sensitively, with the code list of its profile; a blank element is not
written and not checked. As in the Schematron, some apply only in a context: the reason code
of an allowance or a charge (charge indicator false or true), the scheme, MIME code, type
code or date format of a referenced document with type code 130, 50 or 916, the currency of a
VAT total that equals the invoice or VAT accounting currency (a currency that is both counts for
the invoice currency only, because the Schematron fires the first matching rule).
(The internal unit LandrixEInvoiceCIICodeRules holds the table; its
LandrixEInvoiceCheckCIICodeRule checks a single identifier.)
The rules judge the invoice as it would be written. A VAT rate the invoice does not set is 0 and is written as 0; lines, allowances and charges of category O are written without rate.
Every entry has a Severity: eds_Error, eds_Warning or eds_Info. Errors are what
SaveTo* refuses on. With eio_Strict, content the target does not allow and discouraged
content count as errors too.
for I := 0 to Integer(D.Count) - 1 do
if D[I].Severity = eds_Error then
WriteLn(string(D[I].RuleID), ' ', string(D[I].Message));D.ToText returns all entries, one per line.
eio_CheckOnRead checks the business rules of the detected specification while reading; the
violations go to Doc.Diagnostics. Or call Check with Doc.Info.Spec.Target, as
examples/CheckInvoice does. The rules judge the
invoice as this library writes it for that specification: sub lines it does not nest (e.g.
cac:SubInvoiceLine in a Peppol file) are checked flat, see Writing.
Rule identifiers are stable. Rules of this library that the standards do not have start with
LX- (e.g. LX-CC-04).