As you may or may not be aware, there is a discrepancy between the specification for SI-UBL 1.2 and the document type registration at Tickstar's GalaxyGateway SMP.
Even though I hope SI-UBL 1.2 is being phased out now that SI-UBL 2.0 is the latest standard, I would like to resolve this issue, and propose a way forward.
Since I think this is considered out of scope for the STPE CAB group, and we do not hold face to face SI CAB meetings anymore, we plan to put this up as an agenda item for the next SI CoP meeting. Please consider the following issue description and proposal, and if you are not the one attending the CoP, pass on your comments to someone that is, or let us know your preference here.
The issue is the following; according to the specification, the Process Identifier (ProcessID in UBL) is urn:www.cenbii.eu:profile:bii04:ver2.0:
However, it would appear that when SI-UBL 1.2 was registered as a document type at GalaxyGateway, this value was submitted wrong, and in their registry it is now urn:www.cenbii.eu:profile:bii04:ver1.0, see document type number 155 on
I suspect this was overlooked at the time, since the most widely used AP software (Oxalis), did not actually check this value for lookups. More recent versions of Oxalis do check it, however, so people have been experiencing issues sending documents that are in fact correct, essentially giving an error message that no recipient could be found for that document type. The general workaround so far has been to set the ProfileID value to urn:www.cenbii.eu:profile:bii04:ver1.0 in the documents that are sent.
As said, we would like to fix this issue, and there are two directions of approach here;
- Add a second document type for SI-UBL 1.2 invoices, and leave the old one as it is.
- Update the registry at GalaxyGateway to now use the correct value for all registered receivers
- Update the specification itself, and make the currently used value the official one.
The first two have direct operational consequences; 1 needs all service providers to add both document types for all their customers that support SI-UBL 1.2, and 2 will break sending for most if not all senders that currently use SI-UBL 1.2.
Should we leave the specification as it is, and update the registry, I would propose to have a transition path, where we first do 1, then update all receivers, then update all senders, and finally remove the old document type. This would probably be a path of 6-12 months or so, in the more optimistic estimates.
I would therefore seriously consider option 3: we'll update the specification for SI-UBL 1.2, and make the process identifier officially urn:www.cenbii.eu:profile:bii04:ver1.0, the current de-facto value. I believe this to be the path with he least operational hurdles. Obviously we'll need to make sure any other SMPs use this value as well, and that it is very clear that we are updating a specification of a an older standard, of which there is a newer version (SI-UBL 2.0, which has a completely different process identifier).
If you have any thoughts, or a preference for one of the options, please let us know here or in the next meeting.
U moet u aanmelden om een opmerking te plaatsen.