CII mapping: "VAT" or "VA" code?

[sarafacchinetti]

In the mapping CEN vs CII ( 16931-3-3) ram:SpecifiedTaxRegistration/ram:ID shall have the value “VA” and ram:ApplicableTradeTax/ram:TypeCode shall have the value “VAT”

Is that correct or “VAT” is the code to be used for both? (ubl mapping uses always VAT)

[phax]

It is now fixed in CII, but it also occurs in EDIFACT... we need to ask an expert

[sarafacchinetti]

do you know if 16931-3-3 will be changed accordingly?

[phax]

This is fixed for UBL and CII in release 1.1. The fix for the EDIFACT version is missing, that's why this issue is targeted to release 1.2

[alexis-via]

Are you really sure that this change from VA to VAT was valid ?

In the Factur-X specifications profile EN16931 (reminder : Factur-X uses CII), on BT-31, the specs say we should use "VA". So, with the current CII schematron, we get an error. I talked about it with one of the authors of the Factur-X standard and he confirmed that we should use "VA" for CII, but there is some confusion because EN16931 uses "VAT" for UBL. So, AFAIK, "VA" is valid and should be accepted by the CII schematron.

[sarafacchinetti]

Unfortunately there were changes and errors with this mapping in UBL and CII (see also #38) and the syntax binding doesn't clearly indicate which code lists are used for the scheme identifiers (if any) because the semantic core data model doesn't consider scheme ids for these BTs.

As far as the CEN TS 16931-3-3 (CII binding) contains "VA" for BT-31, BT-48, BT-63 and "VAT" for BT-95, BT-102, BT-118, BT-151, I believe the CII schematron and related examples shall consider "VA" is valid for BT-31, BT-48 and BT-63 and "VAT" is valid for BT-95, BT-102, BT-118, BT-151.

For UBL, according to corrigendum of CEN TS 16931-3-2, now the "VAT" is valid for all BT-31, BT-48, BT-63,BT-95, BT-102, BT-118, BT-151 and correctly indicated in the examples.

[csautereau]

I confirm that it is not possible / reasonable to modify the schematron before any new official document has been published. In addition, we need to be careful on ascendant compatibility. Here, CII has already been implemented by many players in France (for Factur-X for instance, but also directly with XML CII D16B alone), with the value "VA" present for BT-31, BT-48 and BT-63.

Consequence is that if an invoice is sent to ChorusPro (French National Platform for public sector) with "VAT", it will be rejected. We need then to organize a change, letting the time for receiver to implement it, and then asking to sender to do the same.

If a change is really necessary and published (and I hope it will remain exceptional), the Schematron must accept at least both values "VA" and "VAT" for a certain period of time (1 or 2 years).

Then, could you update the schematron for CII in that direction rapidly, in order to keep this Schematron as a reference for CII implementation of the EN16931.

Many thanks

[phax]

In CII, the @SchemeID of ../ram:SpecifiedTaxRegistration/ram:ID (BT-31, BT-48 and BT-63) should be “VA”. In UBL, the cac:TaxScheme/cbc:ID of ../cac:Party/cac:PartyTaxScheme/cbc:CompanyID should be “VAT”. However, in the examples in TS16931/3/2 and TS16931/3/3 there are mistakes: in CII “VAT” is used and in UBL “VA” is used in some places. This confused implementers. As these are pure technical codes, no business impact, it would be good to allow both “VA” and “VAT” for both CII and UBL.

[oriol]

We should follow up with the current syntax bindings.

This means using :

VA for BT-31, BT-48, BT-63 and VAT for BT-95, BT-102, BT-118, BT-151 in CII

and

VAT for all BT's in UBL

[phax]

But can't we add "VAT" to CII for BT-31, BT-48, BT-63 as an option and as a proposed fix?
So VA for: BT-31, BT-48, BT-63
and VAT for: BT-31, BT-48, BT-63, BT-95, BT-102, BT-118, BT-151
?

[MartinForsberg-Ecru]

I agree with you Oriol. The schematron should mirror the official normative specification. It will be very very complicated if the maintenance here in github must take all existing implementations/communities compatibility issues into consideration. If a community like PEPPOL or someone else have a compatibility issue after a correction of the schematrons, then that change management must be handled within that community. We are not doing anybody a favour by including tweaks/hacks to allow for non-conformant usage of the standard.

[oriol]

We should stick to the EN Syntax Binding. The problem should be solved issuing a corrigenda on the TS Syntax Binding.

[MartinForsberg-Ecru]

As far as I can see when reading the CII syntax binding, it is correct and there is no need for a corrigenda (for this particular issue at least). The bug/problem is only in the schematrons.