missing cardinality check for Value added tax point date (BT-7) and Value added tax point date code (BT-8) in CII

[bdewein]

As defined in the EN16931, Value added tax point date (BT-7) and Value added tax point date code (BT-8) have a cardinality of 0..1. In CII, BT-7 maps to /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString, BT-8 to /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax/ram:DueDateTypeCode. Due to 0..n cardinality of /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax, multiple occurrences of BT-7 and BT-8 are possible (see sample files) and should be prevented by a validation rule.

cii-bt-7-cardinality.txt

cii-bt-8-cardinality.txt

[oriol]

Added rules CII-SR-461 and CII-SR-462 to check for BT-7 and BT-8 as fatal.

[svanteschubert]

@oriol As there are currently invalid validations rules within the validator due to this issue (see #387), as both occurrences of <ram:TaxPointDate> and <ram:DueDateTypeCode> are counted per document and not per parent element, I suggest to reopen the issue (going apply a patch for #387 that will fix this one as well).

@bdewein Both currently validated elements and udt:DateString have in the XSD the cardinality of one:

1. ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString , see cardinality in our CII XSD
2. ram:ApplicableTradeTax/ram:TaxPointDate, see cardinality in our CII XSD
3. ram:ApplicableTradeTax/ram:DueDateTypeCode, see cardinality in our CII XSD

Please note that the non-existence of maxOccurs leads to the default of 1 occurance, see maxOccurs = (nonNegativeInteger | unbounded) : 1 as stated in the W3C specification, see https://www.w3.org/TR/xmlschema11-1/#declare-element

Therefore, I would question the issue in general, as our schematron validation is only meant to be a validation on-top of the XSD validation, right?

[svanteschubert]

@bdewein I am wondering about the last sentence of your initial comment: "Due to 0..n cardinality of /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax, multiple occurrences of BT-7 and BT-8 are possible (see sample files) and should be prevented by a validation rule."

You are referring to BG-23 VAT BREAKDOWN cardinality check here, which has a semantic cardinality of 1 to N in EN16931-1. The validation artefacts can only validate against the semantics given by the spec.

[svanteschubert]

Now I see what you meant, EN16931-1 states:

The code shall distinguish between the following entries of UNTDID 2005 [6]:
- Invoice document issue date
- Delivery date, actual
- Paid to dateThe Value added tax point date code is used if the Value added tax point date is not known when the invoice is issued. The use of BT-8 and BT-7 is mutually exclusive.

This should be validated: "The use of BT-8 and BT-7 is mutually exclusive"

[svanteschubert]

As already stated in 387, mutually exclusive works with BR-CO-03 tested it, and the requirement to have only one value per BT-8 and BT-7 in a document will be fixed in my upcoming patch for #387.

[bdewein]

@svanteschubert what I meant was that the cardinality restrictions to both BT-7 and BT-8, as defined in the semantic model of the EN 16931, were not enforced by schematron rules. See the example files attached in my inital comment, which contain "illegal" multiple BT-7/BT-8 and pass validation of CEN schematron up to version 1.3.11.

[svanteschubert]

@bdewein Thank you for the friendly conversation by phone. I did indeed overlook the fact that in the core semantics BT-7, and BT-8 are not beyond BG-23, but on the top level. Therefore the values of BT-7 & BT-8 have to be unique!

Yesterday's pull request https://github.com/ConnectingEurope/eInvoicing-EN16931/pull/393 is solving the problem by also allowing multiple occurrences - we should be backwards compatible with existing implementations. Still, we might want to add a warning if multiple occurrences do exist.

The only question remains, what business scenarios had the designers of both syntaxes in mind, to allow multiple "value added tax point dates" to be different within an invoice... (but this is rather research and not required for closing this issue).

[MartinForsberg-Ecru]

@svanteschubert re your last comment. Tax Point Date is not repeatable in UBL. My guess is that it is only repeatable in CII as a side effect of its location in the model. As far as I remember from when it was added to the library, there was no business requirement for repeating it (but that was a long time ago and I may remember wrong).

[svanteschubert]

One last comment on the graphic diagram:

Yesterday I misinterpreted that the business group of level-1 (BG-23) in the semantic model contains the same level business terms of level-1 (BT-7 & BT-8) as there is no level-0. I am thinking of BG as an element/class and the BT as an attribute/member and if those are on the same level I had assumed the BTs are certainly contained within the BG. But the creators of the semantic numbering thought differently:

Therefore obviously, the BT-7/8 and BG-32 in the graphic are not all on the same level although they are all on the same semantic level-1 in EN16931-1. This is confusing, isn't it? 🤔 Actually, all level-1 BTs are (or should be) grouped in a higher new virtual BG-0 called by KoSIT "Invoice", as shown in the graphic, and become more precisely a level-0 (the actual root level). This is quite logical, as a BT (one or more) can not be the root of a tree and all BT have to be grouped within a BG, which as a root (being a single BG) can not be on the same level with other BGs.

BTW the wonderful UML-like graphic above is taken from the latest XRechnung specification of KoSIT on that site on page 26. The graphic within the PDF can be extracted as SVG for usage in the browser. Unfortunately, it is not possible to search in the graph, as all text is serialized as "Paths". @bdewein (I know it is a bit off-topic) but can this be fixed to access the text? In addition, another variant/version including the BT/BG numbers would be great! 💯 Would like to use such a version in the CEN specification as well, a picture says more than a thousand words!