Invalid documentid

[emilbokenstrand]

After upgrading to 7.1.1 from 6.0.7 we are no longer able to receive some documents. I have looked into the code and I can see that the cause of this is probably that we receive some documents with empty Customization ID (example: busdox-docid-qns::urn:beastsupplymaterial:order:3.0.1::Order##::3.0.1). An exception is thrown PeppolDocumentTypeIdentifierParts.extractFromString line 207 because of the first part of the customization id being empty. I believe that the difference from 6.0.7 is that PeppolDocumentTypeIdentifierParts.extractFromString now is run from PeppolIdentifierFactory.isDocumentTypeIdentifierValueValid.

I have reverted to 6.0.7 so we can receive these documents again

So my questions are:
-Is it correct that the (first part of) customization must not be empty? I have not been able to find a specification for it
-If it is correct, is there some kind of workaround to get the SMP to allow this? Or must it be changed on our side and the sending sides to be able to upgrade to 7.1.1?

[phax]

Hi @emilbokenstrand,
Finally - I was waiting for that kind of issue for a long time ;-)

So yes, I made the identifier processing more strict to comply to the Peppol rules.
This is defined in POLICY 20 in Peppol Policy for use of Identifiers - https://docs.peppol.eu/edelivery/policies/PEPPOL-EDN-Policy-for-use-of-identifiers-4.2.0-2023-06-19.pdf line 552ff

The "Customization ID" is mandatory, and Peppol only allows to send documents of types that are contained in the Code List.

To my understanding, that was replaced with the "Advanced Ordering" process as described in https://docs.peppol.eu/poacc/upgrade-3/profiles/65-advanced-ordering/

Currently there is no workaround for this.

[emilbokenstrand]

Hi @phax ! And thanks for answering.
Ok, I don't doubt that you are correct in that Customization ID should be mandatory but when I read POLICY 20 I actually don't see where it says it is. And also, what is allowed and what is not regarding what you may send through the Peppol network is somewhat of a jungle and regarding the Code List I believe that the Swedish Peppol Authority (DIGG) has been involved regarding the possibility to send these messages. Nevertheless, we will try to convince the sending side to change to Peppol order and hope that they are OK with that.

However it seems somewhat strange to me that these rules are enforced by SMP implementations - I mean, if it's not allowed it should be stopped by the SML right? My point is that up til this version these messages where sent just fine (rightly or wrongly so) and I am still able to add such documents to the SML using an older version of the SMP. So what happens is that peppol users are allowed to setup stuff that maybe they shouldn't be able to and then suddenly, upon SMP upgrade, it stops working. I hope you understand my point of view :)

[phax]

The SML only deals with the participant registrations and has nothing to do with the document types - so there is no central control over the document types there. That's why the SMPs should be in charge.

You could of course change the smp.identifiertype to simple but that will cause issues with the case insensitivity of the identifiers, so I don't recommend it. I could do a peppol-lax as a new identifier type but I am not sure this is the smartest solutiuon....

[klaus-lue]

I vote for introducing an additional smp.identifiertype called peppol-lax for a relaxed enforcement of Peppol-rules. Just for the reason of backwards compatibility.

[ri4a]

Does Peppol allow its network to be used for non-standard document type ids?

[phax]

@ri4a Officially not. That's why we have the mandatory code lists

[emilbokenstrand]

The SML only deals with the participant registrations and has nothing to do with the document types - so there is no central control over the document types there. That's why the SMPs should be in charge.

You could of course change the smp.identifiertype to simple but that will cause issues with the case insensitivity of the identifiers, so I don't recommend it. I could do a peppol-lax as a new identifier type but I am not sure this is the smartest solutiuon....

Ah true. The documents are not registered in the SML at all. I did not think of that. What I noticed was that

1. I am no longer able to register these types with empty customization ID.
2. Previous registrations with empty customization id are no longer accessible after upgrading the SMP.

If they indeed should be prohibited 1) is fine but 2) breaks flows that previously worked. Also I am still able to register document types not in the Code List (if customization id is not left empty that is) as far as I can tell using the latest version. I don't know what should be ok and what should not in the Peppol network but suddenly breaking backwards compatibility causes problems :)

[phax]

Version 7.1.2 will ship with a new identifier type peppol-lax. That should resolve the issue.

[emilbokenstrand]

That's great! However I am not able to get it to work :D
I have set
smp.identifiertype=peppol-lax in application.properties but still the endpoint is flagged as Invalid and I get
Bad request: Failed to parse Document Type ID
when trying to do SMP Query

Am I doing something wrong?

[phax]

Well, the identifier type is for the identifiers on the server,
Maybe your SMP client also needs to be a bit relaxed?
How do you do SMP queries exactly?

[emilbokenstrand]

From the SMP gui, the button at the end of each line in Endpoint List. And in the same list it's flagged as Invalid still

[phax]

Yes you are right - my bad. I will fix it for 7.1.3

[emilbokenstrand]

Sounds great! Will this be released prior to June 1:th as I believe that the demand for SMP 1.3.0 starts at that point?

[phax]

I hope I am able to finnish it until then!

[phax]

This is fixed by updating to peppol-commons 9.4.0 and will be part of the upcoming 7.1.3 release

[phax]

@emilbokenstrand Release 7.1.3 is out - please crosscheck

[emilbokenstrand]

Seems to be working, thank you!