Skip to content

CII Schematron - BT-8 - [CII-SR-462] - Only one DueDateTypeCode shall be present - Not well implemented - URGENT #387

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
csautereau opened this issue Jul 18, 2024 · 19 comments
Closed

CII Schematron - BT-8 - [CII-SR-462] - Only one DueDateTypeCode shall be present - Not well implemented - URGENT #387

csautereau opened this issue Jul 18, 2024 · 19 comments
Assignees
@oriol
Labels
Format CII
Milestone
1.3.13 (Nov-24)

Comments

@csautereau
Copy link

The attached CII invoices do not pass the last CII shematron.

They have many VAT breakdown lines, all with BT-8 = 72, but the schematron says

[CII-SR-462] - Only one DueDateTypeCode shall be present (which is the case : only 72)

The schematron counts the occurrence of DueDateTypeCode, where in CII this value is present in each occurrence of VAT Breakdown.

Then, any invoice with MORE than 1 VAT breakdown line is REJECTED !!

URGENT CORRECTION NEEDED

          <ram:ApplicableTradeTax>
                <ram:CalculatedAmount>390.00</ram:CalculatedAmount>
                <ram:TypeCode>VAT</ram:TypeCode>
                <ram:BasisAmount>1950.00</ram:BasisAmount>
                <ram:CategoryCode>S</ram:CategoryCode>
                <ram:DueDateTypeCode>5</ram:DueDateTypeCode>
                <ram:RateApplicablePercent>20.00</ram:RateApplicablePercent>
           </ram:ApplicableTradeTax>
           <ram:ApplicableTradeTax>
                <ram:CalculatedAmount>199.50</ram:CalculatedAmount>
                <ram:TypeCode>VAT</ram:TypeCode>
                <ram:BasisAmount>1995.00</ram:BasisAmount>
                <ram:CategoryCode>S</ram:CategoryCode>
                <ram:DueDateTypeCode>5</ram:DueDateTypeCode>
                <ram:RateApplicablePercent>10.00</ram:RateApplicablePercent>
           </ram:ApplicableTradeTax>

--
factur-x_F2023000152.xml.zip

facture_F20220023.xml.zip
@csautereau
Copy link
Author

correction : BT-8 is only 5 in F2023000152 and only 72 in F20230023

@oriol
Copy link
Collaborator

oriol commented Jul 18, 2024

DueDateTypeCode is an optional value, the solution is to inform only once this element.

@csautereau
Copy link
Author

csautereau commented Jul 18, 2024 via email

@oriol
Copy link
Collaborator

oriol commented Jul 18, 2024

This was added because of #365.

@csautereau
Copy link
Author

csautereau commented Jul 18, 2024 via email

@oriol
Copy link
Collaborator

oriol commented Jul 19, 2024

The EN16931 is a semantic model, and the semantic model is what drives the European Norm. The fact that a specific syntax handles the data in a specific way does not mean that the semantic model has to be modified to support that particular syntax specification, but the other way around. The syntax shall stick to the semantic model. And in this case the semantic model states that there is only one Due Date Code, and this is what has been implemented in the syntax bindings.

The issue could be in this particular case that we could end up with different Due Date Codes in a single invoice, and then an automated system would not know which one to apply.

If you want to to modify the semantics, I think that the best way is to do it through the CEN TC 434. I'd suggest to a request a change of the cardinality to the CEN TC and when approved it will be applied in the syntax bindings.

@csautereau
Copy link
Author

Again, the subject is not to change the EN16931, but how it is implemented in CII or UBL

We have already the same subject for Item base Quantity (BT-150) which is unique in the EN16931. But in CII, this data is present in the Gros Price Group AND in the Net Price Group. Then, there is a rule which says that the 2 values MUST be equal.

This is just the same for BT-8 and BT-7. In CII, the place for those values is in a group which is repeatable. Then, in case it is repeated, the value MUST BE the same. That's all.

It is not written in the syntax binding that only the first or one occurrence of VAT Breakdown must contain the value of BT-8 or BT-7.

And it does not seem that implementing a rule controlling that only ONE VALUE of BT-8 (or BT-7) is present is undoable.

It is required to use the last version of EN16931 Schematron. The consequence is a minimum concern about changes which are not backward compatible and makes compliant invoices suddenly not compliant, with NO INFORMATION and clear notice in advance.
CII with multiple VAT Breakdown including the same value for BT-8 is fully compliant semantically.

And more generally, any change which will add new control should be done carefully. There are many thousands of solutions which are issuing EN16931 compliant invoices based on documentation and current Schematron. If schematrons are changed against documentation and with no time to organize a correction, it is just not professional.

@oriol oriol added this to the 1.3.13 (Nov-24) milestone Sep 4, 2024
@midran midran modified the milestone: 1.3.13 (Nov-24) Sep 4, 2024
@svanteschubert
Copy link
Contributor

As just mentioned in our TAG meeting and as indicated by Cyrille's given test files.
The current test is counting the number of ram:DueDateTypeCode within the complete document by using
count(ram:DueDateTypeCode[parent::ram:ApplicableTradeTax]) &lt;= 1
instead of testing the number of ram:DueDateTypeCode children within a ram:ApplicableTradeTax therefore the test should be
count(ram:ApplicableTradeTax/ram:DueDateTypeCode[2]) &lt; 1!
As Cyrille indicated there are many solutions, but this is new one is working one according to EN16931!

Going to provide a pull request.

@svanteschubert
Copy link
Contributor

@oriol Please remove the label "CEN/TC 434 Discussion needed" as it had been an XPATH problem as I do not have the editing rights for labels.

@csautereau
Copy link
Author

For svante : The correction should allow a single value for BT-8, in case it is present more than 1 time (for instance where there are more than 1 VAT breakdown line).
The current implantation is only counting the number of BT-8.

Do your modification correct this ?

@svanteschubert
Copy link
Contributor

Your test documents validate fine, and I modified one example and duplicated the ram:DueDateTypeCode to test that the new rule works in finding invalid documents with multiple ram:DueDateTypeCode children.

@svanteschubert svanteschubert mentioned this issue Sep 5, 2024
Closed
svanteschubert added a commit to svanteschubert/eInvoicing-EN16931-validation that referenced this issue Sep 5, 2024
@svanteschubert
Fixes ConnectingEurope#365 and ConnectingEurope#387 as counting the e…
d233528 
…lements by parent and not any longer by document
@svanteschubert svanteschubert mentioned this issue Sep 5, 2024
Closed
@csautereau
Copy link
Author

2xml_CII_files.zip

I am not sure the correction works. Attached 2 xml CII files
factur-x_F2024000223.xml has 4 value of BT-8 (4 VAT breakdown : ram:ApplicableTradeTax/ram:DueDateTypeCode) all equal to 72 => your modification approve it

factur-x_F2024000224.xml has 4 value of BT-8 (4 VAT breakdown : ram:ApplicableTradeTax/ram:DueDateTypeCode) the first 3 equal to 72 and the 4th = 5 => your modification approve it also where it should reject.

The rule should count the number of different value of ram:ApplicableTradeTax/ram:DueDateTypeCode, which must be 1
on factur-x_F2024000223.xml : there is only 1 value (as the 4 value are equal to 72)
on factur-x_F2024000224.xml : there are 2 values : 72 (repeated 3 times) and 5

KR

@csautereau
Copy link
Author

Mayube a way to do it, as we know that ram:ApplicableTradeTax/ram:DueDateTypeCode can only be equal ro 5, 29 or 72 (code list check BR-CL-06), maybe should we:
Count the # of value = 5, then 29 and 72 and count that there are at least 2 values of these 3 which are equal to 0

@svanteschubert
Copy link
Contributor

svanteschubert commented Sep 5, 2024 •
edited
Loading

I was indeed only fixing the problem that more than one VAT BREAKDOWN (BG-23) with a BT-7 or BT-8 was no longer possible - which must be possible as it is allowed in the EN16931 norm (see my comment in #365).

But the EN16931-1 states on BT-8 also the following:

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.

Therefore, I might add a validation of the mutually exclusive use of BT-8 and BT-7.

Is there more that needs to be validated, Cyrille?
It seems to me - from your new example - that you like to ensure to have only the same BT-8 code for all occurrences in the document.
If this is the case, is your demand also demanded by the law?
And if it is in the law, we still have to update it in EN16931-1, as I can not find this rule in the current norm or its current internal draft.

@csautereau
Copy link
Author

csautereau commented Sep 5, 2024 via email

@svanteschubert
Copy link
Contributor

Yes, I found and tested BR-CO-03 meanwhile and tested it, and it works.

  1.  We both agree that the norm obliges 1 occurrence of BT-8 (Value added tax point date code) in a BT-32 (VAT BREAKDOWN) and that there are multiple BT-32 allowed in the norm.
  2. The Syntax Binding of UBL states a 1..n cardinality, which is different from what you are stating to the 1:1 cardinality on the document, level, but UBL does not concern this issue, so let's drop this.
  3. I asked about the law that all element values must be equal - I find it of course natural what you demand, but theoretically why not split the choice of BT-8 for each VAT BREAKDOWN using a different value for <ram:DueDateTypeCode>?
    Unless it is not forbidden, it is possible by the given grammar.
    In any case, the rules, we are testing here, must be found as well in EN16931, right?

@svanteschubert
Copy link
Contributor

The solution for your request would be:

	<param name="CII-SR-463" value="count(ram:ApplicableTradeTax/ram:DueDateTypeCode) = count(ram:ApplicableTradeTax/ram:DueDateTypeCode[text() = '5']) or 
									count(ram:ApplicableTradeTax/ram:DueDateTypeCode) = count(ram:ApplicableTradeTax/ram:DueDateTypeCode[text() = '29']) or 
									count(ram:ApplicableTradeTax/ram:DueDateTypeCode) = count(ram:ApplicableTradeTax/ram:DueDateTypeCode[text() = '72'])"/>

I should assume if we require this criteria for BT-8, we should require this for BT-7 as well, right?
Guess that is what the KoSIT asked for in #365

Thinking it over, I believe the core should have this requirement and an extension might do differently (if the law is not forbidding it). Will address this to CEN TC 434 WG1.
@oriol / @phax Please re-add the CEN/TC 434 Discussion needed :-)

@svanteschubert
Copy link
Contributor

Going to drop my prior commits testing for uniqueness as this is already tested by the XSD.
Instead, I will test for the same value of BT-7 and BT-8 like the following:

For BT-8:

<param name="CII-SR-461" value="count(ram:ApplicableTradeTax/ram:DueDateTypeCode) = count(ram:ApplicableTradeTax/ram:DueDateTypeCode[text() = '5']) or
count(ram:ApplicableTradeTax/ram:DueDateTypeCode) = count(ram:ApplicableTradeTax/ram:DueDateTypeCode[text() = '29']) or
count(ram:ApplicableTradeTax/ram:DueDateTypeCode) = count(ram:ApplicableTradeTax/ram:DueDateTypeCode[text() = '72'])"/>

For BT-7:

<param name="CII-SR-462" value="count(ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString) = 0 or ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString[text() = preceding::ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString/text()]"/>

Different approaches because the solution for BT-8 is likely faster than the one of BT-7 using the preceding:: axis.

@svanteschubert
Copy link
Contributor

The previous solution for BT-7 to check for a unique value within the document, would not work for 3 or more occurrences of BG-23, when the last two are the same, the following would do:

<param name="CII-SR-462" value="count(ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString) = count(ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString[text() = (//ram:ApplicableTradeTax/ram:TaxPointDate/udt:DateString)[1]/text()])"/>

oriol added a commit that referenced this issue Sep 11, 2024
@oriol
resolves #387
5117f6b
@oriol oriol closed this as completed Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@oriol oriol

Labels
Format CII
Projects
None yet
Milestone
1.3.13 (Nov-24)
Development

No branches or pull requests
5 participants
@phax @oriol @svanteschubert @midran @csautereau