Skip to content
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.

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

[BR-63] fails if multiple URIUniversalCommunication are present #369

Closed
JannickWeisshaupt opened this issue Feb 14, 2024 · 5 comments
Closed

Comments

@JannickWeisshaupt
Copy link

The rule [BR-63] fails with the following error
Error processing schematron validation Schematron rules for EN16931 (CII). Error is A sequence of more than one item is not allowed as the first argument of fn:normalize-space() ("EM", "EM")
when multiple URIUniversalCommunication are present as follows:

                <ram:URIUniversalCommunication>
                    <ram:URIID schemeID="EM">seller@email.de</ram:URIID>
                </ram:URIUniversalCommunication>
                                <ram:URIUniversalCommunication>
                    <ram:URIID schemeID="EM">seller2@email.de</ram:URIID>
                </ram:URIUniversalCommunication>

The problematic line seems to be
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:URIUniversalCommunication/ram:URIID/@schemeID) != ''

Here is an example invoice
en16931_bug.zip

@oriol oriol added this to the 1.3.12 (May-24) milestone Feb 27, 2024
@csautereau
Copy link

I do not see this as an error.
Buyer electronic address is 0..1 in EN16931
This is the address to which the invoice has to be sent.

You may have confused with Contact email address (which is also 0..1 in fact)
No modification has to be done.

@JannickWeisshaupt
Copy link
Author

I do not see this as an error. Buyer electronic address is 0..1 in EN16931 This is the address to which the invoice has to be sent.

You may have confused with Contact email address (which is also 0..1 in fact) No modification has to be done.

@csautereau Thanks for your opinion. However please try out the example invoice or read my post carefully.
Hint: Failed validation != Working validation with rejection

@csautereau
Copy link

I have tried your example.

The schematron gives an error with an invoice with more than one
ram:URIUniversalCommunication
<ram:URIID schemeID="EM">seller@email.de</ram:URIID>
</ram:URIUniversalCommunication>

On BUYER (and any Party).

If I delete the secund email on your invoice example, validation passes fine.
Then the error is to provide 2 ram:URIUniversalCommunication, which is not allowed for EN16931.

Now the rule is "
The Buyer electronic  address  (BT-49) shall have a Scheme identifier.

If I delete the shemeID="EM" in your example corrected (only 1 ram:URIUniversalCommunication), then schematron rejects with the comment :

[BR-62]-The Seller electronic address (BT-34) shall have a Scheme identifier.

Which is normal as your example in fact plays with ram:URIUniversalCommunication of the Seller (and not the buyer)

To finish, If if delete the shemeID="EM" for the Buyer (BT-49, the result is also a mistake with comment

[BR-63]-The Buyer electronic address (BT-49) shall have a Scheme identifier.

Conclusion for me : Schematron is correct on the control of SchemeID presence for Party's Electronic Address (BT-49, BT-34) and also on cardinalities which must be 0..1 (and not multiple)

KR

@JannickWeisshaupt
Copy link
Author

JannickWeisshaupt commented Mar 1, 2024

@csautereau There is a difference between a crashing schematron and a schematron that found errors in the invoice.
I don't care whether the invoice should be rejected or accepted, but the bug is that, because of the buggy rule, the schematron crashes and is unable to generate a correct report.

Try for yourself and add other schematron errors into the invoice, e.g. BR-CO-10. Those should now be reported as well.
Also look at the output for my example invoice. Is the rule stated, which was wrong, i.e. ?

@oriol
Copy link
Collaborator

oriol commented Apr 6, 2024

The rule is improved with a [1] to check for the first occurrence of the URIUniversalCommunication avoiding crashes. This will not raise any error in case there are more than one URIUniversalCommunication in the document instance. In order to check for this two new rules have been added in the EN16931-CII-Syntax. CII-SR-459 and CII-SR-460 to warn in case more than one URIUniversalCommunication exist.

oriol added a commit that referenced this issue Apr 6, 2024
oriol added a commit that referenced this issue Apr 6, 2024
@oriol oriol closed this as completed Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants