Contents

Business context, purpose, scope and target audience

As layed out in the article Mercurius: the electronic mail room for our public entities, the Mercurius platform operates as a main/central mailroom for Belgian government entities, in the context of e-Invocing and e-Procureent. Such entities, and more generally, any Belgian Contracting Authority, can take advantage of teh services offered by the Mercurius platform to ease, improve, and/or boost its transition towards standardized, interoperable e-Procurement. The article Contracting Authorities : how to integrate your accounting software with the Mercurius platform? introduces the technical side of the Mercurius platform for such Belgian contracting authorities, eligible to use the Mercurius platform.

...

The target audience is software developers, analysts and architects charged with the integration of the systems of eligible Belgian Contracting Authorities with Mercurius - at connectivity level and at business logic level.

Prerequisites

To be able to fully understand the concept and technologies used in this document, you need to first get knowledge about the following :

...

Also it doesn't provide any support for particular technology to integrate with the web service. We only provide a sample CXF for reference only.

Introduction

When you send a document to someone through the postal services, you just put it in an envelope, put the address on it, stamp it (if required) ... and that's it. Basically, Peppol is the solution for doing the same, but between computers. This is however quite a different, more complex challenge to solve in the world of computers than in the world of paper, because the ultimate goal - automation of invoice processing -  is much more sophisticated, and due to the inherent nature of computer systems - programs can hardly cope with deviations. Therefore, achieving such a universal, fully inter-operable exchange system, is a challenge. Peppol offers is (a) a framework that enables this universal "new way of posting". 

...

, and (b) a global, open ecosystem into which the interoperability framework is respected by all actors.

...

SRC https://Peppol.eu/about-openPeppol/

...

The simpl.ePRIOR interface is defined by a WSDL as it's a SOAP based service. This service is exposed by the Federal integrators for federal customers and by Regional integrators for regional customers. 

How does it work?

...

- Keyline-principles

The Simpl.ePRIOR webs service defines the following four operations : submitDocument, submitInboxRequest, retrieveDocument, and markDocument. Each operation is  explained later in appropriate details.

...

As explained above, to perform meaningful business exchanges, the operations must (a) be performed using the appropriate document format (BISv3 BIS INVOICE, BISv2 BIS ORDER, BISv2 BIS MLR, ...) and (b) be combined appropriately.

...

...

...

...

...

Sequences of operations

...

Document conformance

Documents flowing through Mercurius and simpl.ePRIOR always comply with (a) syntax and (b) semantic rules:

• the integrators validate the conformance to the syntax, ie the applicable UBL xsd (*), and

• additionally, Mercurius (ie, the backend service), validates the conformance to the semantic standard, hereafter referred to as "document format". (**)

(*) The service only supports (a) the transport of UBL documents. Although the subject has been informally discussed, no requirements any other syntax have been raised to date, such as UN/CEFACT, EDIFACT, ...2.1 documents ( syntax for Peppol BIS documents), and (b) the transport of the UNCEFACT / CII invoice compliant with the EN 16931 specifications

(**) Notice that:

• Outbound documents are validated at runtime: if a non-conformant document is submitted, the submit will fail (the service consumer will get a false ack indicator - and a SOAP fault describing format violations encountered in the document [Cmt 10 May 2019: hasn't yet been checked] ).

• Inbound document validation is performed asynchronously - due to a lack of consensus to exploit the Peppol transport protocol (AS2/AS4), to send non-conformance feedback (it is questionable whether this belongs to the transport layer). Fatal validation errors on inbound documents are handled as breaches against the Peppol agreements. Therefore the documents are intercepted and propped with no further follow up. This aspect :

  • Upon fatal error in the validation process, Mercurius attempts to return an MLR to the document sender, notifying him that the document cannot be processed further due to non conformance. Such MLR can only be return if document sender has published MLR receiving capabilities.

  • This aspect (asynchonous validation and MLR feedback) does not affect the interface with the Public sector.

  Howver, it adds

  • thisinformation is only provided to add context to the end-to-end business exchanges with business correspondents, which the user, our service consumer, must be aware of, to properly drive their end-to-end projects.

How to test the service?

To familiarise yourself with the web service, you can use SOAPUI.

...

You can repeat the same with the WSDL for Simpl.ePRIOR .

Testing your development

When you start development or wish to validate your logic, you can exchange information with "sparring partners" : the fakeCustomer and fakeSupplier. In an upcoming version of this guide, this section will elaborate on this service, that is not completely finalized yet.

...

• develop your own mock or use SOAPUI as a sparring partner, using your favorite integrator's wsdl, and the information in this document.

• when the development is sufficiently advanced, test the service by sending documents to yourself through simpl.ePRIOR. You can also use the Mercurius portal to generate incoming documents - however this does not guarantee that you will see all possible document patterns.

• When this is OK, test the service in combination with other public sector entities

• eventually, organize tests involving private sector entities.

Detailed presentation of the service

Overview

...

The following elements are used in the Simpl.ePRIOR interface. This is part of the required transmission items, on top of that the payload needs to contain a valid xml (UBL in most cases) document ( retrieve and submit document ). The Mercurius platform validates the UBL is correct based on the document type defined : this is a schematic and format validation - against XSD and Schematron. The business content like PO, price, ... is not validated and must be checked by the consumer.

See UBL document definition and UBL document Validation for reference.

To process an offered invoice, you must perform the following steps in this order :

1. Submit Inbox

2. Retrieve Document

3. Mark document

4. Submit Document

...

Submit Inbox

Description

This operation accesses the inbox on Mercurius for a particular receiverID. Note that you need to have a contractual obligation before you can access a receiver's inbox ( to be configured with your integrator ).

Parameters

...

submitInboxRequest

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:head=”http://fsb.belgium.be/header”  xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
   <soapenv:Header>
      <head:fsbHeader>
         <head:messageId>9397cbe5-174f-479f-941d-2371129acb05</head:messageId>
      </head:fsbHeader>
   </soapenv:Header>
   <soapenv:Body>
      <v1:submitInboxRequest>
         <v1:receiverId>?</v1:receiverId>
         <v1:senderId>?</v1:senderId>
      </v1:submitInboxRequest>
   </soapenv:Body>
</soapenv:Envelope>

Response

...

submitInboxRequestResponse

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00>
   <soapenv:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsu:Timestamp wsu:Id="Timestamp-HvumButHp993jGDym7t89Q22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsu:Created>2018-10-03T10:07:55Z</wsu:Created>
            <wsu:Expires>2018-10-03T10:12:55Z</wsu:Expires>
         </wsu:Timestamp>
	<!—More elements on security and signature:-->
      </wsse:Security>    </soapenv:Header>
   <soapenv:Body>
      <v1:submitInboxRequestResponse>
         <v1:documentGroup>
            <!--Zero or more repetitions:-->
            <v1:documentReference>
               <v1:documentId>?</v1:documentId>
               <v1:documentTypeCode>?</v1:documentTypeCode>
               <v1:receiverId>?</v1:receiverId>
               <v1:senderId>?</v1:senderId>
            </v1:documentReference>
         </v1:documentGroup>
      </v1:submitInboxRequestResponse>
   </soapenv:Body>
</soapenv:Envelope>

Retrieve Document

Description

This operation retrieves a document from the inbox of a defined receiver.

Parameters

Request 

...

retrieveDocument

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:head=”http://fsb.belgium.be/header”  xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
   <soapenv:Header>
      <head:fsbHeader>
         <head:messageId>692da97e-e4a0-4ed0-b0bd-6e3f01e1e601</head:messageId>
      </head:fsbHeader>
   </soapenv:Header>
   <soapenv:Body>
      <v1:retrieveDocument>
         <v1:receiverId>?</v1:receiverId>
         <v1:senderId>?</v1:senderId>
         <v1:documentType>?</v1:documentType>
         <v1:documentId>?</v1:documentId>
      </v1:retrieveDocument>
   </soapenv:Body>
</soapenv:Envelope>

Response

...

retrieveDocumentResponse

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/  xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00>
   <soapenv:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsu:Timestamp wsu:Id="Timestamp-HvumButHp993jGDym7t89Q22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsu:Created>2018-10-03T10:07:55Z</wsu:Created>
            <wsu:Expires>2018-10-03T10:12:55Z</wsu:Expires>
         </wsu:Timestamp>
	<!—More elements on security and signature:-->
      </wsse:Security>    </soapenv:Header>
   <soapenv:Body>
      <v1:retrieveDocumentResponse>
         <v1:receivedDate>yyyy-MM-dd</v1:receivedDate>
         <v1:document>
            <!--Valid UBL document returned-->
         </v1:document>
      </v1:retrieveDocumentResponse>
   </soapenv:Body>
</soapenv:Envelope>

Mark document

Description

This operation marks a document when it has been processed at the customer side. Once it has been marked, it isn't accessible anymore from the entity's inbox, via the submit inbox request or the retrieveDocument request.

Parameters

Request

...

markDocument

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:head=”http://fsb.belgium.be/header”  xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
   <soapenv:Header>
      <head:fsbHeader>
         <head:messageId>692da97e-e4a0-4ed0-b0bd-6e3f01e1e601</head:messageId>
      </head:fsbHeader>
   </soapenv:Header>
   <soapenv:Body>
      <v1:markDocument>
         <v1:receiverId>?</v1:receiverId>
         <v1:senderId>?</v1:senderId>
         <v1:documentType>?</v1:documentType>
         <v1:documentId>?</v1:documentId>
      </v1:markDocument>
   </soapenv:Body>
</soapenv:Envelope>

Response

...

MarkDocumentResponse

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” 
xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
         <soapenv:Header>
            <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
               <wsu:Timestamp wsu:Id="Timestamp-HvumButHp993jGDym7t89Q22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
                  <wsu:Created>2018-10-03T10:07:55Z</wsu:Created>
                  <wsu:Expires>2018-10-03T10:12:55Z</wsu:Expires>
               </wsu:Timestamp>
	      <!—More elements on security and signature:-->
            </wsse:Security>          </soapenv:Header>
   <soapenv:Body>
      <v1:markDocumentResponse>
		<!—When successful ackIndicator is true-->
         <v1:ackIndicator>true</v1:ackIndicator>
		<!—When an exception occurred ackIndicator is false-->
		<v1:ackIndicator>false</v1:ackIndicator>
		-->
      </v1:markDocumentResponse>
   </soapenv:Body>
</soapenv:Envelope>

Submit Document

Description

This operation allows to send a document type to a supplier. The format of the document must be supported by Mercurius/simpl.ePRIOR, which involves an intake of the format (see supported document flows). Additionally, the receiver must support that document format, meaning he must have published the receiving capability in a Peppol SMP. NB: to increase interoperability, Mercurius will soon add a default conversion to human readable of the documents whose receivers do not yet support the document format used by the sender. This echoes the already existing conversion for inbound documents, that was implemented to accelerate regularisation of Belgian public sector towards directive 2014/55.

Parameters

...

Input

...

Output

...

Exception

...

valid Document

...

ackIndicator = True

...

• unsupported document format

• document format violation (list of errors found)

...

(*) See SOAP Fault section for more details

Request

...

submitDocument

Submit Document

Description

This operation allows to send a document type to a receiver (in the case of the invoice response, the receiver is the supplier who issued the invoice).

The format of the document must be supported by Mercurius (and, thereby, by simpl.ePRIOR), which involves an onboarding of the format (see supported document flows).

Additionally, the receiver must support that document format, meaning he must have published the receiving capability in a Peppol SMP. To overcome that limitation, Mercurius provides services that convert the structured electronic document into a human-readable equivalent, and transmits it per email to the receiver, provided that the sender commnicates such email address in the original document. This strategy is gradually rolled out accross inbound and outbound flows. The availability of such additionnal service is documented flow per flow, in the next main section.

Parameters

Request

...

submitDocument

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:head=”http://fsb.belgium.be/header”   xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
   <soapenv:Header>
      <head:fsbHeader>
         <head:messageId>692da97e-e4a0-4ed0-b0bd-6e3f01e1e601</head:messageId>
      </head:fsbHeader>
   </soapenv:Header>
   <soapenv:Body>
      <v1:submitDocument>
         <v1:document>
            <!--You may enter ANY valid UBL document at this point-->
         </v1:document>
      </v1:submitDocument>
   </soapenv:Body>
</soapenv:Envelope>

Response

...

submitDocumentResponse

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
         <soapenv:Header>
            <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
               <wsu:Timestamp wsu:Id="Timestamp-HvumButHp993jGDym7t89Q22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
                  <wsu:Created>2018-10-03T10:07:55Z</wsu:Created>
                  <wsu:Expires>2018-10-03T10:12:55Z</wsu:Expires>
               </wsu:Timestamp>
	      <!—More elements on security and signature:-->
            </wsse:Security>          </soapenv:Header>
   <soapenv:Body>
      <v1:submitDocumentResponse>
         <!—When successful ackIndicator is true-->
         <v1:ackIndicator>true</v1:ackIndicator>
		<!—When an exception occurred ackIndicator is false-->
		<v1:ackIndicator>false</v1:ackIndicator>
		-->
      </v1:submitDocumentResponse>
   </soapenv:Body>
</soapenv:Envelope>

SOAP with attachments

In order to keep the size of xml documents small enough for middleware processing, Simpl.ePrior is using SOAP with attachments when exchanging UBL documents.

It is required to remove any embedded attachment present in the UBL tag <EmbeddedDocumentBinaryObject> and to move it to a content part of the SOAP with attachments. The 'Content-ID' of the mime part must correspond to the value of the <ID> element of the parent of the <EmbeddedDocumentBinaryObject> element. Note that this might make the UBL document invalid regarding the specific schematron validation. This must accepted, however, the document must be valid if the base64 are re-inserted in the UBL

Note: in case you submit an outbound document to the relevant schematron validation before sending it, the document must contain the base64 encoded attachment in the UBL tag <EmbeddedDocumentBinaryObject>.

------=_Part_20_1065051393.1568991070704
Content-Type: text/xml; charset=UTF-8
Content-ID: <rootpart@babelway.net>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Header/>
 <soap:Body>
  <v1:retrieveDocumentResponse xmlns:v1="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
   <receivedDate xmlns="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">2019-09-20</receivedDate>
   <document xmlns="http://fsb.belgium.be/einvoicing/simpleprior/v1_00">
    <inv:Invoice xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
    <cbc:UBLVersionID>2.1</cbc:UBLVersionID>
...
    <cac:AdditionalDocumentReference>
     <cbc:ID>file1</cbc:ID>
     <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject filename="file1.txt" mimeCode="application/octet-stream"/>
     </cac:Attachment>
    </cac:AdditionalDocumentReference>
    <cac:AdditionalDocumentReference>
     <cbc:ID>file2</cbc:ID>
     <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject filename="file2.log" mimeCode="application/octet-stream"/>
     </cac:Attachment>
    </cac:AdditionalDocumentReference>
    <cac:AdditionalDocumentReference>
     <cbc:ID>file3</cbc:ID>
     <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject filename="file3.txt" mimeCode="application/octet-stream"/>
     </cac:Attachment>
    </cac:AdditionalDocumentReference>
...
   </inv:Invoice>
  </document>
      </v1:retrieveDocumentResponse>
   </soap:Body>
</soap:Envelope>
------=_Part_20_1065051393.1568991070704
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <file1>
Content-Disposition: attachment; filename=file1.txt

file1
------=_Part_20_1065051393.1568991070704
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <file2>
Content-Disposition: attachment; filename=file2.log

file2
------=_Part_20_1065051393.1568991070704
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <file3>
Content-Disposition: attachment; filename=file3.txt

file3
------=_Part_20_1065051393.1568991070704—

SOAP Fault

Simpl.ePrior uses standard SOAP fault, without defining substructures.

...

Endpoint URL

This remark only applies to users of the Belgian public sector integrators.

The endpoint URLs are defined by the integrator. Once you start your on-boarding process those 'll be communicated by the integration team plus the necessary security/authorization artifacts ( certificate, credentials, ... ).

Detailed explanations of the document exchange patterns supported by Mercurius

...

and simpl.ePRIOR and their composing flows

As explained above, Mercurius supports business transactions consisting in exchange of documents, according to a preliminary defined exchange Profile. The Peppol specifications for the Document types and exchange Profiles are re-used. Only the connectivity is customised to the specificity of the service integrators operating in the Belgian public sector.

The scope of such transactions supported by Mercurius and its simpl.ePRIOR interface, grow according to its users community needs and expectations. This section keeps track of, and provides details over the supported document flows. For the sake of completeness, a section about the ePRIOR legacy documents is provided at the end of this heading.²

Inbound Invoicing

This exchange pattern starts with an inbound flow: the reception of an invoice or a credit note, with 0..n attachments (supporting documents). It can be followed by and outbound flow: the transmission of a business response.

(a) Reception of invoice/creditNote

supported formats

The initial, inbound flow of this pattern currently handles four possible formats:

...

Peppol BISv2 INVOICE (CENBII-conformant) : optional since 18 Apr 2019 .  In practice all current users do support this format and need to maintain it, to preserve business continuity

...

Peppol BISv2 CREDIT NOTE (CENBII-conformant ): optional since 18 Apr 2019 .  In practice all current users do support this format and need to maintain it, to preserve business continuity

...

2 possible formats:

• Peppol BIS INVOICE (EN 16931-conformant) : mandatory since 18 Apr 2019 due to Directive 2014/55.  In practice current users are still finalizing the intake of this format 

• Peppol BIS v3 CREDIT NOTE (EN 16931-conformant): mandatory since 18 Apr 2019 due to Directive 2014/55. In practice current users are still finalizing the intake of this format

See "defined Document formats" for detailed format specifications

Sequence of simpl.ePRIOR operations to apply

Each time a new processing cycle starts, the collection of incoming documents takes three steps:

...

sequence

...

comment

...

1. submitInboxRequest

...

• the receiver ID is the only mandatory parameter.

• you can filter the documents per sender, per document Type, per documentFormat

...

1. For each document listed in the response,

...

    2.a. retrieveRequest

...

Mercurius returns the document in the payload.

attached files are provided using SWA protocol, instead of inline encoding (see applicable section)

...

    2.b. Mark Request

...

the Mark request is the confirmation that the document was duly retrieved, and the command to remove the document from the inboxRequestResponse

(b) Response to an Invoice/CN

supported formats:

Peppol BISV2 MLR (CENBII-conformant)

See "defined Document formats" for detailed format specifications.

Sequence of simpl.ePRIOR operations to apply

The transmission of the Response is optional. Nevertheless its use is recommended because it creates consistency through the community.

It is performed in one single step:

...

sequence

...

comments

submitDocumentRequest

...

the following table provides the explanation of the response codes used by the Belgian public sector to communicate the result of the processing of the invoice/CN/attached document. This results from the original implementation ePRIOR

...

Code

...

Valeur

...

Remarque

...

Légende de la remarque

...

81:1

...

Credit Note approved

...

1: In case of response code 81:2 or 380:2, the response also contains additional textual description of the rejection, provided by the customer

...

81:2

...

Credit Note rejected

...

1

...

81:3

...

Credit Note ID already exists

...

2

...

81:4

...

Hard business rule violated

...

2

...

380:1

...

Invoice approved

...

2: codes 81:3, 81:4, 380:3 and 380:4 relate to business preprocessing, performed by Mercurius. see next paragraph for more info

...

380:2

...

Invoice disputed

...

1

...

380:3

...

Invoice ID already exists

...

2

...

380:4

...

Hard business rule violated

...

2

Upcoming changes (update: 27 Apr 2019 )

• generalization of Peppol BISv3 INVOICE and CREDIT NOTE: support of Peppol BISv3  invoice and credit note is active on Mercurius; however the activation of this format in Production must still happen. This step takes various test and coordnation activities. It is expected to be over in the coming weeks.

• phase out of Peppol BIS v2 MLR , phase-in of Peppol BIS v3 IMR:

  • The MLR is not the most suitable format to exchange business information between business entities. This document format was chosen for historical reasons.

  • Now there is a new document format available, BIS IMR. Mercurius will be configured soon to support the BIS IMR v3. 

  • this configuration has not yet been scheduled. additionally, the proper introduction of IMR requires coordination with suppliers actually using MLR. This is a significant piece of work  that must be duly analyzed and planned together with the configuration

Outbound invoicing

This pattern currently consists only one outbound flow : submission of an invoice /CN.

The inbound flow, collection of the response, is not configured yet. It is foreseen, but not scheduled yet. see "upcoming changes"

For Mercurius staff, see also page 201 - Simpl.ePRIOR: Outbound Invoicing - Implementation (secured page)

sending an Invoice/CN

supported formats:

• Peppol BISv2 INVOICE (CENBII-conformant )

• Peppol BISv2 CREDIT NOTE (CENBII-conformant )

...

• Directive 2014/55. In practice current users are still finalizing the intake of this format

See "defined Document formats" for detailed format specifications

Remark: Directive 2014/55 also imposes European Contracting Authorities to receive and process the European Norm in the UN CEFACT Cross Industry Invoice (CII) syntax. Mercurius converts such documents into their Peppol BIS Invoice (UBL-based) equivalent, before transmitting them to the receiver. Therefore, this format is not listed above.

Sequence of simpl.ePRIOR operations to apply

Each time a new processing cycle starts, the collection of incoming documents takes three steps:

(b) Response to an Invoice/CN

supported formats:

• Peppol BIS (2.0) MLR (CENBII-conformant) - in phase out - deadline: 30/03/2022 - starting a project to send responses to an invoice using the MLR is strongly discouraged, and not supported by BOSA. This part of the documentation is only available for current users.

• Peppol BIS InvoiceResponse (IMR) - not yet supported: in phase in - availability : October 2021

See "defined Document formats" for detailed format specifications.

Remarks:

• The use of old BIS (2.0) MLR by the Belgian Public sector for responding to invoices, originates from the fact that when we adopted Peppol, there was no Invoice Response document type available. The introduction of the Invoice Response took several years to schedule, also due to the many other changes that needed to be performed.

• in phase 1, the IMR will be used only for business scenarios limited to approval and rejection. Other scenarios will be introduced later, depending on the progress of the user community. Mercurius will support the exchange of Invoice Responses beyond this limitation, however the information displayed on the Mercurius Portal may not be fully aligned with the other possible statusses.

Sequence of simpl.ePRIOR operations to apply

This exchange The transmission of the Response is optional. Nevertheless its use is recommended because it creates consistency through the community.

It is performed in one single step:

Upcoming changes (update: 27 Apr 2019 )

• add Peppol BISv3 INVOICE and CREDIT NOTE document formats:

  • This capability will enable G2G exchanges of EN-conformant invoices. It requires configuration on the simpl.ePRIOR flow.

  • It is a high-priority requirement. It is planned, target date 15 May 2019 .

  • For Mercurius staff only: see page 219 - Outbound (G2B) Invoicing - BIS3 support (secured page).

• add a response reception flow: this involves configuring inbound Peppol BIS IMR support, and may also require more configuration and more preparation.

• adding a PDF plan B to the main flow:

  • the current situation generates a lot of burden to the public sector entity that sends the documents: the entity must know in advance for each receiver  if he is capable of receiving the Peppol BIS format, and find other ways to handle the sendings to other receivers

  • to improve this, Mercurius will soon generalize a logic that converts the document and sends it via pdf/email if the receiver does not have suitable receiing capabilities. this way the public sector entities are freed from the cumbersome process described above, and can plan massive use of the outbound flows.

...

Outbound invoicing

This pattern currently consists only one outbound flow : sending an order.

For Mercurius staff, see also page 202 - Simpl.ePRIOR: Outbound E-Ordering - Implementation (secured page)

submission of an invoice /CN.

sending an Invoice/CN

supported formats:

• Peppol

...

• BIS INVOICE (EN-conformant )

• Peppol BIS CREDIT NOTE (EN-conformant )

See "defined Document formats" for detailed format specifications

Sequence of simpl.ePRIOR operations to apply

This exchange is performed in one single step:

Upcoming changes (update: 27 Apr 2019 )

• adding the response reception flow: order response. This is currently not being planned yet.

• adding a PDF plan B to the main flow:

  • the current situation generates a lot of burden to the public sector entity that sends the documents: the entity must know in advance for each receiver  if he is capable of receiving the Peppol BIS format, and find other ways to handle the sendings to other receivers

  • to improve this, Mercurius will soon generalize a logic that converts the document and sends it via pdf/email if the receiver does not have suitable receiing capabilities. this way the public sector entities are freed from the cumbersome process described above, and can plan massive use of the outbound flows.

Outbound e-Ordering

This section will be available soon.

Legacy flows (decommissioned)

This list is maintained for the sake of completeness. ePRIOR is the legacy system that was re-used during the pilot B2G e-invoicing project. After the pilot project the ePRIOR interface with the private sector was phased-out (and replaced by Peppol interface), but the interface with public sector was maintained. Only in 2018 this interface phase-out became necessary, due to introduction of European Norm and new exchange patterns such as eOrdering.

ePRIOR is also a suite of CEN-BII-, UBL2.0-based document formats (invoice, credit note, application response, attached document ...). based on these documents formats, the following series of flows was set up and kept alive until ePRIOR interface is completely stopped. See also Transition from ePRIOR interface to simpl.ePRIOR (temporary section).

These flows are:

• inbound ePRIOR Invoice

• inbound ePRIOR CreditNote

• inbound ePRIOR Attached Document

• outbound ePRIOR Application Response

Document formats specifications

The document in the payload are based on specificatiosn available on : http://Peppol.eu/downloads/post-award/. These specifications provide strong business interoperability by

• defining the detailed semantics of the documents, and

• mapping the semantics into the (UBL) Syntax.

The semantic layer are defined by standardization teams. The new Peppol BIS 3 Invoice format is an implementation of the european standard for electronic invoice, that provides the semantic specification and the syntaxt binding. Peppol teams only add implementation-level specifications.

...

Defined document formats

The following 2 tables summarize the key information about the supported document formats.

Format specifications

...

Document format

...

UBL DocumentTypeCode ( * )

...

syntax (XSD)

...

semantic

...

status, remarks

...

BIS V2 Invoice

...

380

...

UBL-Invoice-2.1.xsd

...

Peppol BIS 5A Billing

...

• in phase out.

• bidirectional support (in-,outbound).

...

BIS V2 Credit Note

...

81

...

UBL-CreditNote-2.1.xsd

...

BIS V3 Invoice

...

http://docs.Peppol.eu/poacc/billing/3.0/codelist/UNCL1001-inv/

...

UBL-Invoice-2.1.xsd

...

http://docs.Peppol.eu/poacc/billing/3.0/

...

• EN-compliant

• list of authorized identification schemes for party identifiers (enpointID): cf Electronic Address Scheme code list (EAS)

...

BIS V3 Credit Note

...

https://docs.Peppol.eu/poacc/billing/3.0/codelist/UNCL1001-cn/

...

UBL-CreditNote-2.1.xsd

...

BIS V2 Message Level Response (MLR)

...

301

...

UBL-ApplicationResponse-2.1.xsd

...

Peppol BIS 36A Message Level Response

...

• in phase out.

• [TO CHECK] bidirectional support (in-,outbound).

...

BISV2 Order

...

////

...

UBL-Order-2.1.xsd

...

Peppol BIS 28A Ordering

...

outbound support

...

Order Response

...

231

...

UBL-OrderResponse-2.1.xsd

...

Not supported, no intake programmed yet

...

Invoice Response

...

23

...

UBL-ApplicationResponse-2.1.xsd

...

Peppol BIS 63A Invoice Response

...

intake programmed, but not yet started

( * ) the codes shown in this table were historicaly used with ePRIOR to qualify the invoice and credit note. They are also reflected in the status codes that were used then (confer the table in section Inbound Invoicing). All invoice and credit notes receivers are supposed to be able to handle the documents with these UBL Document Type Codes. NB: due to the alignment of Mercurius to the Peppol framework, other codes can be used in teh invoices and credit notes. to see the full list, please consult these documents : Invoice type code (UNCL1001 subset) and Credit note type code (UNCL1001 subset). It is up to each document receiver to decide how to handle these patterns.

...

format

...

Document Format Id /Document identifier/ customisationID  

...

Process ID / Profile ID

...

BISV2 Invoice

...

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.Peppol.eu:bis:Peppol4a:ver2.0::2.1

 busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.Peppol.eu:bis:Peppol5a:ver2.0::2.1

cenbii-procid-ubl::urn:www.cenbii.eu:profile:bii04:ver2.0

cenbii-procid-ubl::urn:www.cenbii.eu:profile:bii05:ver2.0

...

BISV2 CN

...

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.Peppol.eu:bis:Peppol5a:ver2.0::2.1

...

cenbii-procid-ubl::urn:www.cenbii.eu:profile:bii05:ver2.0

...

Upcoming changes (update: 09 Apr 2021 )

• add a invoice response reception flow: this is part of the introduction of the Invoice Response (IMR), see section “(b) response to an invoice” above. This is in development. Target availability date: October 2021.

• see above: support of the Hermes error flow is expected to be available in October 2021.

Outbound e-Ordering

Outbound e-Ordering involves (a) issuing an Order, and (b) receiving an OrderResponse

(a) issuing an Order

supported formats:

Peppol BIS ORDER

See "defined Document formats" for detailed format specifications

Sequence of simpl.ePRIOR operations to apply

This exchange is performed in one single step:

(b) receving an OrderResponse

supported formats:

Peppol BIS order Response

See "defined Document formats" for detailed format specifications

Sequence of simpl.ePRIOR operations to apply

Each time a new processing cycle starts, the collection of incoming documents takes three steps:

Upcoming changes (update: 09 Apr 2021 )

• Conversion of Order into human-readable equivalent in case destination entity is not yet able to process structured electronic order: in development - target imeframe: summer 2021

• Conversion or orderResponse into human-readable equivalent in case destination entity is not yet able to process structured electronic order - target imeframe: summer 2021

Legacy flows (decommissioned)

This list is maintained for the sake of completeness.

ePRIOR is the legacy system that was re-used during the pilot B2G e-invoicing project. After the pilot project the ePRIOR interface with the private sector was phased-out (and replaced by Peppol interface), but the interface with public sector was maintained. Only in 2018 this interface phase-out became necessary, due to introduction of European Norm and new exchange patterns such as eOrdering.

ePRIOR is also a suite of CEN-BII-, UBL2.0-based document formats (invoice, credit note, application response, attached document ...). Based on these documents formats, several flows were set up and kept alive until ePRIOR interface is completely stopped.

Additionally, in the context of the BIS BILLING migration, the old BIS (2.0) Invoice and credit note was also phased out, after due migration towards the new Peppol BIS invoice and credit note.

Here is the list of decommissioned flows

• inbound ePRIOR Invoice

• inbound ePRIOR CreditNote

• inbound ePRIOR Attached Document

• outbound ePRIOR Application Response

• inbound Peppol old BIS (2.0) Invoice

• inbound Peppol old BIS (2.0) CreditNote
  

Document formats specifications

The document in the payload are based on specifications available on : http://Peppol.eu/downloads/post-award/. These specifications provide strong business interoperability by

• defining the detailed semantics of the documents, and

• mapping the semantics into the (UBL) Syntax.

The semantic layer are defined by standardization teams. The new Peppol BIS Invoice format is an implementation of the European Norm for electronic invoicing, that provides the semantic specification and the syntax binding. Peppol teams only add implementation-level specifications.

...

Defined document formats

The following 2 tables summarize the key information about the supported document formats.

Format specifications

Peppol Format identifiers

The message type you have to support are the one defined for your organisation in the SMP. See http://smp.belgium.be.

curl -X GET --header 'Accept: application/xml' 'http://smp.belgium.be/{identifierscheme}::{id}

id					Identifier of Peppol participant
identifierscheme	Scheme under which the identifier is registered

Documents Format Validation

You can validate that your message contain documents that respect format specifications with the following tools :

• https://vefa.difi.no/validator/

• https://Peppol.helger.com/public/menuitem-validation-bis2

NB: the tools allowing to use different rules set, it is important to use the correct rules set, ie the latest version of the rules set that contains the exact format denomination (example : BISV2 INVOICE 4A).

Develop your own validation tool via :

• https://github.com/difi/vefa-validator

• https://Peppol.helger.com/public/locale-en_US/menuitem-validation-ws2

BOSA doesn't support those tools, for question please direct them to their respective developers.

Transition from ePRIOR interface to simpl.ePRIOR (temporary section)

Context

Mercurius was setup during a pilot project (2013-2015Q1) to validate the feasibility of B2G eInvoicing. It reused the open-source implementation of the ePRIOR platform, provided by DIGIT, and using formats provided by CENBII workshops.

Mercurius was aligned with the Peppol model in 2016Q1, to enable massive onboarding of suppliers - in fact, get rid of onboarding activites since alle participants adhering to the Peppol model are supposed to inter-operate directly, thereby eliminating the need for preliminary bilateral negociation and tests and associated costs. To  minimize the amount of simultaneous changes, the ePRIOR documents formats and interface to the public sector were preserved: the ePRIOR and the Peppol BIS v2 semantics were both coformant implementation of CENBII works-results, and the syntaxes were close (UBL2.0 and UBL 21 respectively), making this approch straightforward.

In the meantime the new European Norm (EN 16931) is mandated by law to the European Public sector, since april 2019. On the other hand new many public sector entities initiated projects involving new flows, especially outbound invoicing and ordering. Third, experience demonstrated that even simplistic transformations can, by combination (by diverse integrators and other intermediators),  cause significant confusion, thereby generating waste. To acommodate this triple evolution, required a refactoring of the customer interface.

The simpl.ePRIOR interface , the sucessor of ePRIOR, is able to transport an unlimited amount of different kinds of documents, each one in multiple formats. it is also desgnd to enable a systematic planB, when the receiver is unable to receive the sender format - in that case Mercurius converts it into a human readble and sends it by email or to an eBOX.

This paragraph provides users of former ePRIOR with specific information to migrate from ePRIOR to simpl.ePRIOR.

Transition

• Both interfaces are available in parallel.

• The legacy invoices and CNs, sent by (5) suppliers still using the interface implemented during the Pilot-phase (not yet Peppol), are only accessible through the ePRIOR interface.

• All portal invoices (and CN), all BIS2 Invoices (and CN), and all EDIFACT-pilot invoices are accessible through both interfaces.

• Only simpl.ePRIOR gives access to BIS3 and UNCEFACT/CII invoices and CNs.

• Only simpl.ePRIOR enables outbound flows.

The message layer data accessible through the Mercurius Portal, enables the follow up of the pickup of the documents on both interfaces, making it very convenient to follow up.

It is recommended to encourage pilot suppliers to migrate to Peppol. If a few weeks is needed, it is recommended to use following pattern at each invoice collection cycle:

1. pick up invoices through simpl.ePRIOR interface (and mark all collected invoices);

2. pick up remaining invoices on ePRIOR interface.

(*) Support of this format is only mentioned for the sake of completeness: mercurius converts such documents into their UBL equivalent to make them available to the simpl.ePRIOR consumer application.

The message type you have to support are the one defined for your organisation in the SMP. See http://smp.belgium.be.

curl -X GET --header 'Accept: application/xml' 'http://smp.belgium.be/{identifierscheme}::{id}

id					Identifier of Peppol participant
identifierscheme	Scheme under which the identifier is registered

Documents Format Validation

You can validate that your message contain documents that respect format specifications with the following tools :

• https://vefa.difi.no/validator/

• https://Peppol.helger.com/public/menuitem-validation-bis2

NB: the tools allowing to use different rules set, it is important to use the correct rules set, ie the latest version of the rules set that contains the exact format denomination (example : BISV2 INVOICE 4A).

Develop your own validation tool via :

• https://github.com/difi/vefa-validator

• https://Peppol.helger.com/public/locale-en_US/menuitem-validation-ws2

BOSA doesn't support those tools, for question please direct them to their respective developers.

Definitions

References

Sample Code

This example is provided without any guarantee or support. It's only to help you and show you how to generate code based on the WSDL definition.

FAQ

Links

...