Belgian Service Providers / Access Point Forum (confluence)

Contents

9956>0208 migration

Background

The enterprise number has been assigned a PEPPOL schemeID in 2016 (9956). The introduction of the EN 16931 caused the need to replace schemeID 9956 by an ICD-compliant new schemeID. FPS Economy, owner of the enterprise number, recently proceeded with the due registration of the enterprise number. ICD 0208 was assigned in april 2020, and recorded in EAS in june 2020. The introduction of schemeID 0208 in the Peppol framework can take place. consequently the removal of 9956 must be organised in synch with 0208 introduction. this is the subject of this topic.

Timeline

status

At forum 14 Jul 2020 forum there was no clear preference for any migration support discipline. Consequently the only official migration scenario is the minimal one, where each SP is solely responsible of meeting the schedule and the possible negative impact of missing milestone B.

BE PA will nevertheless reassess options and at least gather and share periodic progression data.

smp.belgium.be BIS migration enforcement

since 28 Jun 2020 smp.belgium.be throws a BELMA-306 error code upon attempt to register a non-BIS (3.0) document type prior to registering the equivalent BIS

The belgian Governement takes measurs to phase out all non-BIS (3.0) traffic reaching it. old BIS receiving capability will be removed (a) from the test environment on 01 Oct 2020 and from production on 31 Dec 2020

a change is planned to also reject old BIS (2.0) registration. this is a new step towards BIS and BIS BILLING migration completion/cleanup.

stay tuned!

Hsmp migration token collection interface

Abstract

In order to speed up the migration of Belgian enterprises out of Hermes towards a suitable e-invoicing tools, BOSA decided to

1. initiate migration for all Hermes participants and

2. let HermeSMP expose a (secure) migration Token collection interface.

The interface specifications were submitted to a review round to the Belgian SP/AP forum members in June 2020. The first stable version of the specs were posted below on 03 Jul 2020 . The interface is ready for tests as of 14 Sep 2020 The specs are maintained below.

Specifications

1. Swagger: hsmp_migration_key.yaml

2. Test Plan: HSMP_migration_key.postman_collection.json (Postman)

3. Additional information:

   1. https://documenter.getpostman.com/view/11381713/T17FCUqp?version=latest

   2. pay attention:

      1. this service allows a maximum of 1000 collections per day. the system will blacklist any user exceeding this level. The affected user will have to contact BOSA (service owner) to request reactivation.

      2. As an alternative, the user planning to exceed 1000 collections a day, can contact BOSA to schedule the operation. He will then be temporarily authorized to exceed the limit mentioned above.

   3. list of responses codes: see table 1 below

   4. Schedule: see table 2 below

   5. Tast enterprises dataset:

      1. here is a list of IDs to support the test: HSMP-test-data.csv

      2. NB: In order to recycle the enterprises please de register them at the end of the test (as discussed on ap forum 15 Sep 2020 )

4. Version history
   This section will tracks the publication of updates of the documentation

   1. Initial draft published 03 Jun 2020 for review purpose

   2. First stable version published 03 Jul 2020 along with initiation of development works

   3. 11 Sep 2020 ready for acceptance testing. resources HSMP_migration_key.postman_collection.json, hsmp_migration_key.yaml and https://documenter.getpostman.com/view/11381713/T17FCUqp?version=latest updated. overview error codes added. planning updated.

table 1 - responses

table 2 -Schedule and progress

ATTENTION: Schedule update 11 Sep 2020 : original schedule is revised as follows: user testing is split in two.

Hermes agreements framework

Abstract

The Hermes use case requires specific agreements between the sender and the Belgian government (represented by BOSA). Additionally, Service providers are invited to boost Hermes uptake and integrate use case in their service offering, free of charge. BOSA designed agreements that fulfill these purposes. the Belgian SP/AP forum members reviewed the proposed agreements in June 2020. This section stores the agreements resulting from such works.

Agreements

Answers to questions posted by SPs during 8th edition of the forum (23/06/2020)

Hermes – possible confusion with some Peppol principles – clarification (published 15/06/2020)

Context

With Hermes, BOSA DT implements the mandate formulated by the Minister of Digital Agenda in his policy note 2018, in respect of the solution described in the tender “BOSA 2018/M1087”, also approved by the Minister.

The policy goal is to help the suppliers to get a faster payback for their initial efforts to comply with Government requirement to use Peppol. The proposed solution is to (a) publish Peppol BIS Billing receiving capabilities for all Belgian enterprises (except the ones already publishing such capabilities), and (b) build a system that converts Peppol BIS invoices into equivalent PDF and forwards these by email to the receiver. This brings all Belgian enterprises within the reach of the Peppol senders - and their service providers.

In addition to the pay-back effect for the senders, the use of Hermes offers 4 strategic advantages:

1. It reduces the friction between the senders and the receivers. By converting Peppol BIS into PDF, Hermes gives more freedom to each party in the management of his e-invoicing transformation. For senders, it removes the need to maintain multiple channels (at least for domestic traffic).

2. It provides a communication channel to Belgian enterprises: in addition to the invoice, the email sent by Hermes also provides information to the enterprises about the available solutions on the market, thereby speeding up the adoption. Moreover, the enterprises receive the information along with the invoices. This is the moment where they are supposed to be most sensibilized.

3. It generates a significant growth of the volume of invoices that can be processed automatically. This will turn into a better/broader sharing of the costs of technology and boost the development of new tools. Consequently, it will help the IT sector to grow, and the Belgian enterprises to find suitable solutions at affordable prices.

4. It will also benefit to B2G adoption:

   • Directive 2014/55 obliges the public sector to receive e-Invoices, but it doesn’t oblige the private sector to send them.

   • This creates a risk that the public sector does not receive sufficient invoices to compensate the investments made to meet the obligation.

   • Hermes provides an additional motivation to the senders, and thus reduces the risk described above.

Hermes is only a temporary solution. In the Peppol terminology, all Hermes receivers are ready to migrate from day one. As soon as such receiver finds a suitable and affordable tool to automate the inbound invoice processing, he/she migrates onto it. Once a sufficient adoption of interoperable e-invoicing is achieved, Hermes will retire. The sooner the better.

Purpose of this paper

To use Hermes, Peppol senders must meet three conditions: (1°) be a Belgian enterprise, (2°) accept the conditions of use of Hermes and (3°) communicate the email address of their client. The degree of alignment of some of these conditions with the Peppol principles, seems to cause confusion to some stakeholders. The purpose of the present paper is to clarify how these conditions relate to the Peppol specifications.

Be a Belgian enterprise

BOSA DT is a Belgian Federal public service. It can only provide service to Belgian enterprises. Consequently Hermes can only handle invoices sent by Belgian enterprises. If Hermes would also handle invoices sent by foreign enterprises, it would clearly fall outside the scope of action of BOSA. BOSA cannot afford to take this risk.

This condition does not seem to be the subject of a discussion, hence it does not require any additional clarification.

Accept conditions of use

Description

Hermes is an intermediate component between the sender and the receiver. It cannot operate without a clear mandate from one of the two parties. Obviously it is not feasible to receive such a mandate from every Belgian enterprise. Therefore it must be mandated by the sender.

Clarification

In the first place, this formality is not related to Peppol. No entity, private nor public, can act as an intermediate without having an agreement with at least one of the parties. It is also needed to clearly delineate the boundaries of the service, such as the domestic coverage (previous condition). Therefore, in the current design of Hermes, this aspect is handled outside of any Peppol-related consideration, before even considering Peppol. Peppol comes into play in many other aspects of Hermes, but not in this one.

More specifically, Hermes must not be confused with a receiving Access Point (C3). It is situated in the business layer (C1 – C4). In C1, Hermes offers a solution to the sender to capitalize on their existing interoperable outbound invoicing systems. In C4, it is a gateway that takes care of the last mile, after the Peppol transmission. It is based on a non-ambiguous identification of the suppliers and customers coming from the authoritative source of Belgian enterprises. Such a construction indeed is difficult to map in the Peppol model. The Hermes reasoning supersedes the Peppol reasoning, it does not contradict it.

Email address

Description

By design, all invoices sent to Hermes must be converted to human readable format and forwarded by email to the final destination. Therefore the correct email address of the receiver is required. As this email address can depend on many factors (even for the same receiver), the supplier (sender of the invoice) must provide the correct address. The only other way to handle this need would be to store a suitable email address for every Belgian company in the Hermes configuration data. During design, this option was judged excessively complex and disproportionate.

Clarification

Requiring extra information on top of the BIS is not uncommon. Most if not all invoices exchanged over Peppol contain information that is not mandatory but nevertheless indispensable in the specific business scenario of the invoice. For instance, the Flemish government requires a Purchase Order number. The need for an email address is considered to be proportional to the scenario addressed by Hermes.

Conclusion

On the basis of the political mandate, the legal checks and the clarifications above, BOSA is confident that the Hermes construction cannot reasonably be judged to be in contradiction with the Peppol principles. On the contrary, deep down the fundamental principles of Peppol we can find the core principle of inclusiveness. Hermes increases alignment of Peppol with this core principle.

Additionally, BOSA explores possibilities to improve the alignment between Peppol and Hermes. The most likely option would be to define a national use case. This is the subject of an upcoming effort and is driven by additional factors and constraints.

Hermes documents review round 202006 - closed

Abstract

• This section shares information with the Belgian Service providers about Hermes in the context of a draft review round.

• Timewise, this round

  • started with a presentation during the 7th Belgian AP forum on 26 May 2020 .

  • closes on 18 Jun 2020 .

• Review participants are invited to provide their comments by email to peppol@bosa.fgov.be.

• Following documents are in the scope of this review round:

  1. the conditions of use for senders and its technico-functional annex,

  2. the integrators agreement,

  3. the migration toke collection interface specification.

Documents

(hsmp) migration token collection interface - Test Plan

Introduction

Currently only the Table of Contents of the text plan is available. However ,once it is reviewed, the Test plan will be elaborated and packaged as a Postman Project that suits for the testing of the interface. The graphical representation of the high-level description is also provided. notice however that an inconsistency was found when comparing the TOC and the viusal - the error 3 seems to overlap hsmp801. This is under investigation

High-Level Description / “table of contents”

Visual

(hsmp) migration token collection interface - Additional info

Proposed schedule

Currently, no need for such an additional piece of documentation is identified. During the specifications review round, review participants are invited to describe the additional documentation they would need, if any.