Versions Compared

Key

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


version1.1
published
 
comment

This page is still the subject of additional validation cycles. Readers are welcome to send questions and/or provide comments by email to mercurius@bosa.fgov.be 

...

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

sequencecomment

1. submitInboxRequest

  • the receiver ID is the only mandatory parameter.
  • you can filter the documents per sender, per document Type, per documentFormat
2. 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 Requestthe 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

...

It is performed in one single step:


sequencecomments


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
CodeValeurRemarqueLégende de la remarque
81:1Credit 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:2Credit Note rejected1
81:3Credit Note ID already exists2
81:4Hard business rule violated2
380:1Invoice 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:2Invoice disputed1
380:3Invoice ID already exists2
380:4Hard business rule violated2

Upcoming changes (update: )

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

See "defined Document formats" for detailed format specifications

Sequence of simpl.ePRIOR operations to apply

This exchange is performed in one single step:

sequencecomments
submitDocumentRequest
  • 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)

Upcoming changes (update: )

...

This exchange is performed in one single step:

sequencecomments
submitDocumentRequest
  • 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)

Upcoming changes (update: )

...

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

Format specifications

Document format
UBL DocumentTypeCode ( * )syntax (XSD)semanticstatus, 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/

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.xsdPEPPOL 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 .  Peppol permits the use of other codes, 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.


PEPPOL Format identifiers

...

MercuriusMail-room from the Belgian Public sector, for e-Procurement related structured electronic documents
PEPPOLPan-European Public Procurement Online, PEPPOL enables businesses across Europe and beyond to communicate electronically with public buyers in various stages of the procurement process
OpenPEPPOL

OpenPEPPOL is a non-profit international association under Belgian law (Association Internationale Sans But Lucratif – AISBL) and consists of both public sector and private members. The association has assumed full responsibility for the development and maintenance of the PEPPOL specifications, building blocks and its services and implementation across Europe.

IntegratorsIntegrators allow service consumers to access the simpl.ePRIOR service exposed by the Mercurius platform. The service on the Mercurius platform is only accessible to integrators : Federal ( FSB ) or regional ( Magda, ... )
PortalAlso known as the Mercurius portal, it allows customers and suppliers to monitor (track and trace) the documents received and sent. It provides business information (sender, receiver, business status, date, ...) and access to technical information (messages exchanged, technical status, ...)
FASFederal Authentication Service authenticates authorises users to access the platform
Supplier

A supplier is an enterprise that contributes goods or services. Generally, a supply chain vendor manufactures inventory/stock items and sells them to the next link in the chain. Today, these terms refer to a supplier of any good or service.

See https://en.wikipedia.org/wiki/Supplier

The Peppol definition is the following :

The supplier is the legal person or organization who provides a product and/or service.
Examples of supplier roles: seller, consignor, creditor, economic operator.

Customer

In sales, commerce and economics, a customer (sometimes known as a client, buyer, or purchaser) is the recipient of a good, service, product or an idea - obtained from a seller, vendor, or supplier via a financial transaction or exchange for money or some other valuable consideration.

See https://en.wikipedia.org/wiki/Customer

The Peppol definition is the following :

The customer is the legal person or organization who is in demand of a product and/or service.
Examples of customer roles: buyer, consignee, debtor, contracting authority.



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.

...