Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The solution setup in Belgium for the business to government exchanges is composed of the following keyline elements:

  1. Mercurius: it is the centralized mailroom for reception and routing of all e-Procurement related electronic and structured documents to and from the public sector. Mercurius thereby serves the public sector in their automation projects, and ensures consistency throughout all public sector entities.

  2. Peppol: it is the "new way of posting", suited to structured electronic documents. Mercurius is fully aligned with the Peppol model. It is exclusively connected through a Peppol accesspoint

  3. Simpl.ePRIOR: interface with the public sector entities, suited to their context, and more specifically aligned with the technology in use on the public sector integrators.

  4. Mercurius portal: provides track and trace function to staff of entities using Mercurius platform. the portal reuses the Network infrastructure (proxy) and the Authentication and Authorization service

...

Context of this document


This document is about the Simpl.ePRIOR interface defined on the right side of the schema : it describes the interaction between the Mercurius platform and the Public sector, the customers. The other flows aren't part of this document.

...

Example: to receive an invoice and return a business response, the following 3-phases sequence applies to the simpl. ePRIOR consumer application:

  1. the consumer collects incoming invoice:

    1. the consumer performs a submitInboxRequest on behalf of the target business entity→ in return he gets the list of new documents available in his inbox.

      1. we assume that an invoice is waiting to be picked up

      2. we also assume that it is a Peppol BIS Invoice

    2. the consumer performs a retrieveRequest to pick up the invoice

    3. the consumer performs a markRequest to notify Mercurius that it successfully retrieved the invoice, and that the invoice can be removed from the business entity's inbox

  2. The consumer performs the appropriate business processing. This phase is out of scope of the current process. It ends up with a possible response to the original document sender

  3. The consumer performs a submitDocument Request to post a response to the original document sender, notifying him of the results of the processing by the business entity. It uses the following document format: Peppol BIS v2 MessageLevelResponse (MLR). Note: the Peppol BIS Invoice Response (IMR) is being introduced. IT will replace the MLR (for more info see later in the Guide).

Sequences of operations

...

Document conformance

...

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

sequence

comment

  1. submitInboxRequest

  • the receiverId 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 markRequest is the confirmation that the document was duly retrieved, and the command to remove the document from the inboxRequestResponse

...

supported formats:
  • Peppol BIS InvoiceResponse (IMR) - In production as of March 2022

  • Peppol BIS (2.0) MLR (CENBII-conformant) - in phase out - deadline: Decommissioned as of 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: phase in starting : March 2022 .

See "defined Document formats" for detailed format specifications.

...

sequence

comments

submitDocumentRequest

1/ for a functional explanation of the Invoice response, please refer to the applicable documentation (see table below)

2/ Use of old BIS (2.0) MLR involves meeting the following additionnal specification, for the sake of meeting the ePRIOR response codes specifications: the UBL Data Element DocumentResponse/Response/Description must contain:

  • the following codes:

    • invoice approved: 380:1

    • invoice Rejected: 380:2

    • credit note approved: 81:1

    • credit note rejected: 81:2

  • in case of a rejection, the code must be followed by the explanation of rejection reason.

Outbound invoicing

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

...

Outbound invoicing

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

(a) Sending an Invoice/CN

supported formats:
  • Peppol BIS INVOICE (EN-conformant )

  • Peppol BIS CREDIT NOTE (EN-conformant )

...

sequence

comments

submitDocumentRequest

  • if the receiver does not support the document format , then Mercurius posts an MLR (2.0) in the inbox of the sender to notify the failure of the transmissionand if the UBL does not contain the email address of the receiver the sender will not be notified.
    NB: (a) it is not supposed to happen, as senders are supposed to use that flow only if they know that it will work; (b) see below information

  • documents may contain attachments. in this case attachment must be transmitted using SOAP with Attachment (SWA) protocol (cf appropriate section of this document)

Info

Since december 2020, in the context of the Hermes project, any company registered in the Belgian Crossroad Bank of Enterprises can receive a Peppol BIS invoice. This enables invoice senders on Peppol to reach all their Belgian Customers, under the condition that such senders agree with the Hermes terms and conditions. All Public sector entities using the services of Mercurius can also agree with the Hermes terms and conditions, and thereby also benefit of the bigger reach enabled by Hermes.

In the happy flow (when the sending meets all Hermes terms and conditions), the use of Hermes is already supported.

Both Hermes and Mercurius need to be adjusted to cope with the error flow (if the sending does not meet the terms and condition). The adjustment works are ongoing. Support of the error flow is expected to be available in March 2022.

...

(b) Receiving Response

  • add an 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: March 2022.

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

Outbound e-Ordering

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

...

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 stepEach time a new processing cycle starts, the collection of incoming documents takes three steps:

sequence

comments

comment

submitDocumentRequest
  1. submitInboxRequest

  • if the receiver does not support the document format, then Mercurius posts an MLR in the inbox of the sender to notify the failure of the transmission.
    NB: (a) it is not supposed to happen, as senders are supposed to use that flow only if they know that it will work; (b) see "upcoming changes"

  • documents may contain attachments. in this case attachment must be transmitted using SWA protocol (cf appropriate section of this document)

...

  • the receiverId 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 markRequest is the confirmation that the document was duly retrieved, and the command to remove the document from the inboxRequestResponse

Outbound Ordering

Outbound 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:

sequence

comments

submitDocumentRequest

  • Documents may contain attachments. Such attachments must be transmitted using SWA protocol (cf appropriate section of this document)

  • Many suppliers do not yet support Peppol BIS ORDER. To cope with this temporary constraint, Mercurius also supports the following “plan B”:
    (a) Mercurius converts the Order into a human-readable equivalent (PDF) (or extract an embedded human-readable equivalent from the attachments of the Order )
    (b) Mercurius sends the PDF version of the Order via email to an email address specified by the sender.
    This “plan B” requires that the sent order meets additional requirements. Such requirements are available here, together with additionnal detailled specifications of this process.

(b) Receiving an Order Response

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:

sequence

comment

  1. submitInboxRequest

  • the receiverId 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 markRequest is the confirmation that the document was duly retrieved, and the command to remove the document from the inboxRequestResponse

Upcoming changes (update:

...

Conversion of Order into human-readable equivalent in case destination entity is not yet able to process structured electronic order: in development.

...

)

  • None

Legacy flows (decommissioned)

...

Document format

UBL DocumentTypeCode

syntax (XSD)

semantic

status, remarks

BIS Invoice

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

UBL-Invoice-2.1.xsd

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

BIS Credit Note

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

UBL-CreditNote-2.1.xsd

old BIS 2.0 Message Level Response (MLR)

301

UBL-ApplicationResponse-2.1.xsd

Peppol BIS 36A Message Level Response

  • in phase out - Deadline Decommissioned as of 30/0309/2022

  • only supported for outbound traffic

BIS Order

220 (supported variant: 227)

UBL-Order-2.1.xsd

https://docs.peppol.eu/poacc/upgrade-3/profiles/28-ordering/

Order Response

231

UBL-OrderResponse-2.1.xsd

Invoice Response

23

UBL-ApplicationResponse-2.1.xsd

https://docs.peppol.eu/poacc/upgrade-3/profiles/63-invoiceresponse/

bidirectional support - in development - target date: March 2022


Peppol Format identifiers

format

Document Format Id /Document identifier/ customisationID  

Process ID / Profile ID

BIS INVOICE

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

urn:fdc:Peppol.eu:2017:poacc:billing:01:1.0

BIS CN

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:Peppol.eu:2017:poacc:billing:3.0::2.1

urn:fdc:Peppol.eu:2017:poacc:billing:01:1.0

CII EN-compliant INVOICE (*)

busdox-docid-qns::urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100::CrossIndustryInvoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::D16B

cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0

old BIS 2.0 MLR

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:www.cenbii.eu:transaction:biitrns071:ver2.0:extended:urn:www.Peppol.eu:bis:Peppol36a:ver1.0::2.1

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

BIS order

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Order-2::Order##urn:fdc:peppol.eu:poacc:trns:order:3::2.1

cenbii-procid-ubl::urn:fdc:peppol.eu:poacc:bis:ordering:3

BIS orderResponse

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2::OrderResponse##urn:fdc:peppol.eu:poacc:trns:order_response:3::2.1

cenbii-procid-ubl::urn:fdc:peppol.eu:poacc:bis:ordering:3

PEPPOL Peppol Invoice Response transaction 3.0

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:fdc:peppol.eu:poacc:trns:invoice_response:3::2.1

cenbii-procid-ubl::urn:fdc:peppol.eu:poacc:bis:invoice_response:3

...

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).

...

...