Peppol BIS v3 schemeID has been changed

[PPotappel]

The high gentlemen of Peppol decided to change the sender/recipient schemeId in the BIS V3-version. Till V2 a textual representation was used like NL-VAT, NL-KVK. In the latest and greatest version you should use the numeric representation 0106, 9944, and so on... See: http://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingCustomerParty/cac-Party/cac-PartyLegalEntity/cbc-CompanyID/

This leads to a problem in Oxalis Standalone. It does not support these schemeId's yet to create the SBDH.

[jannewaren]

Hello! There has already been an issue about this and I recently asked for confirmation in the comments of that issue and got it: Oxalis will not support PeppolBis 3.0 out of the box: https://github.com/difi/oxalis/issues/226

You need to do the SBDH creation yourself before calling Oxalis. There might be some common components available for that but I don't know more about those, we're creating our own implementation.

The whole document sniffing feature is being deprecated in Oxalis:

You have enabled support for automatic detection of content. This functionality will be turned of by default in version 4.1 and removed in version 4.2/5.0. Use configuration "oxalis.transformer.detector = noop" to disable it today.

[nathalieDOXA]

Hi,

405 is exactly the error I faced...

Could you explain me more about it... Is it correct that Oxalis doesn't support Peppol 3.0 yet? If I submit the following invoice with SBDH (PEPPOL 3.0): https://www.galaxygw.com/wp-content/uploads/2018/12/test-invoice_bis3billing_sbdh_galaxygw-test.xml, Oxalis will not support at all?

Thank you in advance.

[jannewaren]

Hello @nathalieDOXA

You can send Peppol BIS Billing 3.0 payloads with Oxalis. We are using it on production to send lots of them.

It's not like Oxalis supports them or not. Oxalis supports sending anything if you wrap in in a StandardBusinessDocument. But it used to be so you could just give Oxalis an <Invoice> that is a PEPPOLBIS2 or EHF2 invoice and it will take the recipients and document types from inside the payload. That still works in version 4.0.4 for example but it does not work for PEPPOLBIS3 and afaik it never will.

So, to send a PEPPOLBIS3 payload you need to construct the SBDH and wrap the <Invoice> in a <StandardBusinessDocument> yourself. Just like in your example file https://www.galaxygw.com/wp-content/uploads/2018/12/test-invoice_bis3billing_sbdh_galaxygw-test.xml so yes that should work.

The thing is, Oxalis does not anymore provide a component to construct the SBDH for you. You need to do it yourself or rely on another vendor.

[nathalieDOXA]

Hi @jannewaren , Thank you much, I'm clear about the topic now. I can get peace of mind to go ahead with Oxalis now.

I have another related question: #405 is referred to this topic, but it seems it doesn't solve the problem. When I submit the example https://www.galaxygw.com/wp-content/uploads/2018/12/test-invoice_bis3billing_sbdh_galaxygw-test.xml, it supposes to work but I keep receiving the following error:

Combination of receiver (iso6523-actorid-upis::9908:810418052) and document type identifier (busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1) is not supported.

Do you have any idea?

Thank you in advance.

[jannewaren]

This means the participant 9908:810418052 is not registered in SMP to receive the profile you are trying to send. Not sure if you're talking about testing environment or production environment (this participant is registered in both) but anyway, I think PEPPOLBIS3 profiles are supposed to be registered under the new participant identifier 0192:810418052 and at least in testing environment some bis3 profile is there (looking at http://b-106a59c4cf1dd8344c7dd257c0e2b6bd.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu/iso6523-actorid-upis%3A%3A0192:810418052). Maybe try that one?

Or maybe try registering a participant yourself, making sure it's registered for the profile you are sending, and sending to that one instead.

[nathalieDOXA]

Hi @jannewaren,

Thank you for taking time helping me. I'm talking about the testing environment. You are correct that the provided receiverIdentifier is not registered. I'm now using 9956:0207373429, it no longer get that error.

But I'm facing another error (just share here, I know this error maybe off topic for this thread).

2020-01-07 03:11:50,786 WARN [no.difi.oxalis.as2.util.MdnMimeMessageInspector] MIC mismatch, received MIC was 'DOD7Yhe18g6Z2/3leHNOfnYwUmc=, sha1' while sent MIC was 'rl9T8xFxxoQVgs7us8jyXnUsV1U=, sha1'.

Thanks again.