Invoice test, fixed namespace prefixes, market shares, new Mustang versions
Jochen Stärk
Hi,
Invoice test
Fumbling around with vertical addition (correct) vs Horizontal
Addition TEsts (HATE tests ;-)), by sheer luck I came up with some
numbers:
1x123,45 @19% VAT
+1x123,45 19%
Net 246,90
VAT-Amount ?
Amount payable ?
By adding the net amounts grouped by VAT rate to 246,90-> one
would get *0,19=46,911 Eur vat, rounded 46,91 USt -> 293,81 to
be paid
1x123,45 19%
1x123,45 19%
Netto 246,90
VAT-Amount ~46,91
Amount payable 293,81
If one adds rounded VAT by line (123,45 netto *0,19 =
23,4555->23,46 VAT per line) the rounding errors ad up to a
even amount payable
1x123,45 19% (incl VAT
~146,91)
1x123,45 19% (incl VAT ~146,91)
Net 246,90 (incl VAT ~293,82)
VAT-Amount (amount incl VAT minus net) 46,92
(wrong) Amount payable 293,82
There is another sample in the free part of EN16931-1 https://www.beuth.de/en/standard/din-en-16931-1/314992770 in the german version on page 119, at 25% VAT:17,84 71,37
14,96 59,85
10,56 42,25
4,84 19,37
4,84 19,37
ist not
Sorry for playing the math teacher here but this can be a quick
test (2 lines a 123,45 with 19% VAT should become an uneven
293,81) which should not fail. In e-Invoicing that is, in
e-Billing that might be different but in Germany that would
anyway only be eligible for amounts <150 Eur.
As you know the namespace prefixes (ram, rsm, qdt...) are, unusual for an XML format, somehow fixed in UN/CEFACT CII. While UBL only has recommended namespace prefixes they are apparently at least technically binding in UN/CEFACT, Andreas Pelekies (thank you!) found it in https://unece.org/DAM/cefact/xml/UNCEFACT+XML+NDR+V3p0.pdf and wrote
There is a chapter about conformance. [R B998] Category 2 states that an organisation can choose to change the prefix, but with a weaker conformance to UN/CEFACT. This leads to usergroup-specific rules.
On the other hand, [R 9224] states that XML Schema (not instance) MUST use the defined structure.
At CEN level this discussion about mandatory prefixes was done as well and guys from the UN/CEFACT library team confirmed the mandatory usage "in practice". This is why EN16931 syntax bindings, XRechnung and all EN16931 based implementations use the fixed namespaces in a mandatory way. In a way, it is mandatory by fact, as UN/CEFACT themselves only use the fixed namespaces in all of their artefacts as well as their Schematron. The latter makes them technically mandatory. The NDR chapter "5.6.2 Namespace Tokens" indeed states that the namespace tokens "will be created using three character representations for each unique namespace". As this NDR is a binding guide for UN/CEFACT and the published schemas and examples are binding, the prefix names are fixed as they are published. For example, [R 9FD1] says that for code lists "clm" MUST be used. In chapter 8.6.3.2 it is referenced again for a different constellation. So the rule from 5.6.2 does not allow prefixes with more or less than 3 characters.
Chapter 8.7.2.1 makes, in general, the prefix mandatorily to be equal to the three letter identifierscheme of common identifier schemes. See also [R 9CCF] with conformance category 1.
Chapter 8.7.3.2 states "uses the namespace token for the data package in which it is defined". As the data package abbreviations are mandatory (RSM, RAM, QDT, UDT, ...) This implicitly makes the prefixes mandatory again.
So in summary, we have explicitly declared a fixed NS clm. Although it is not stated explicitly, the overall figure drawn by the NDR together with the current and all historical publications as well as the CEN/TS 16931-3-3, CEF, XRechnung etc it is mandatory, if full conformance with the NDRs is to be achieved.
If someone wants to change this, the respective organisation should make a change request at UN/CEFACT level.
Market shares
In the meantime the zugferd
community validator is not sure which Factur-X library/SDK
software is used for almost 90% of the submitted samples, here are
some stats for 2020 and 2021:
| 2020 Share in % | 2021 Share % | ||
| By Version | |||
| ZFv1 | 10,36 | 10,81 | |
| ZFv2/FXv1 | 73,26 | 63,68 | |
| XRechnung | 16,38 | 25,51 | |
| By Software | |||
| Unknown | 86,66 | 89,09 | |
| Mustang | 7,33 | 5,44 | |
| Konik | 0,57 | 0,67 | |
| Symtrax | 1,99 | 1,23 | |
| Ghostscript | 0,2 | 1,62 | |
| Intarsys | 2,5 | 1,5 | |
| pdfMachine | 0,3 | 0 | |
| Factur-X Python | 0,4 | 0,5 |
The samples files are of course not kept due to data protection.
So please let me know if there is a way to find out if it was any
other e-invoicing library or tool which created them, or maybe we
also need to start looking in compressed PDF nodes (please feel
free to let me know if any library allows to turn on compression).
The recognition is currently still
very simple. Please also let me know if you run a validator
and would be willing to share statistics.
New Mustang versions
Despite the log4j detector did not find anything and we're not
using Log4j directly in Mustang (we're using SLF4j and Logback)
there was a Log4j-related Logback update which prompted me to
quickly release Mustang
2.3.3, even before having checked the two merge requests
after 2.3.2 properly: they will come in a future version, maybe
still this year. Mustang 2.3.2 brought some XRechnung improvements
and the capability to persist invoice classes and their
dependencies e.g. with Jackson.
-- mit freundlichen Grüßen Jochen Stärk www.usegroup.de Huswertstraße 14 60435 Frankfurt Tel: (069)569940-20 Fax: (069)569940-19 Mobil: (0177)4512645