| Info |
|---|
Welcome Enjoy your visit and let us know! |
Contents
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Hermes Access Point Whitelisting - Testplan
Preamble
Hermes (hrms) offers the possibility to Service Providers operating a Peppol Access Point (AP), to integrate hrms into their outbound invoicing services. This testplan lets the AP check the behavior of hrms in the different scenarios. APs can familiarize themselves with hrms, including instances when sent invoices fail hrms validations .
This testplan is designed to require minimal input, effort and time from the AP. The complete execution takes less than 1 hour. BOSA advises to agree on a joint schedule, but this is up to the AP to decide.
1. Description of the test session
The test consists of the following steps. (More details below in section 2)
Kick-off
BOSA and AP meet and greet, agree on the setup and exchange the information required to execute the set of round and launch the tests.Initial round
This test set validates the behavior of hrms when the AP is not yet registered on the whitelist.Main round
This test set validates the behavior of hrms when theAP is registered on the whitelist and no email address is recorded.Final round (optional)
This test set validates the behavior of hrms when the AP is registered on the whitelist and a central email address is recorded.Wrap up
BOSA and AP share their findings, observations and conclusions. They sign off the results. This closes the session.
2. More details
There are only 2 details worth noting: (a) what information must be exchanged at kick-off and (b) what is the sequence of each test round.
(a) what information must be exhanged at kick-off?
The AP must provide the following information to BOSA:
enterprise number of a sender for which the AP registered MLR Receiving Capabilities
email address (4.. Final round) : if the AP wishes to test the scenario where hrms returns negtive feedback by email to a centralized email address :
BOSA will hand over the set of (9) invoices (xml’s) to be used through the different runs - tuned to the AP’s context. These 9 xmls cover the different cases that need to be checked. For info, please find here a zip file containing the 9 sample reference xml invoices.
[NB: if, exceptionally, the enterprise communicated by the AP is registered in the hrms senders list, BOSA will remove it for the sake of the test]
(b) what is the sequence of each test round?
Each round only takes 2 simple steps:
AP sends the 9 invoice and informs BOSA once the set is duly sent
BOSA (a) tracks the outcome of each invoice sent (based on the ID of each invoice), (b) modifies the hrms configuration for the next round, and (c) gives the GO to the AP to move to next round
Conclusion
The testplan is designed to require minimal input, effort and time from the AP.
This is the opportunity for the AP to get first hand, in only a few minutes, a glimpse of the workings of hrms.
BOSA invites all APs to take this opportunity.
CBE Identification scheme ID migration (9956>0208)
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
Current
At forum it was decided that the minimal scenario will be complemented with regular monitoring by BOSA (see below : share periodic progression data). Progress on the 3 stages will be monitored on the basis of a questionnaire that will be sent out on a monthly basis. The 3 identified stages are :
stage 1 : Stop registering new participants under scheme ID 9956
stage 2 : Finish migrating 100% of portfolio from scheme ID 9956 to scheme ID 0208
stage 3 : Exclusive use of Scheme ID 0208 for all existing and new participants
history track
At forum 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.
Decommissioning old BIS Billing (2.0) - incl. old BIS decommissioning enforcement on smp.belgium.be
Since 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 Government takes measures to phase out all non-BIS (3.0) traffic reaching it. old BIS receiving capability will be removed (a) from the test environment on and from production on
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
as a result of the Hermes initiative, all active Belgian enterprises are registered on Peppol. 98% of them are registered on HermeSMP and ready for migration onto another solution ( + smp). No Blegian enterprise can be registered “from scratch” anymore. In order to speed up the migration of Belgian enterprises out of Hermes (hrms) towards a suitable e-invoicing tools, BOSA decided to (1) initiate migration for all hrmsparticipants and (2) let HermeSMP (hsmp) expose a (secure) Migration Token Collection Interface (mtci).
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 . The interface is ready for tests as of The testing window closed on . No specific bug were reported during the testing window. Consequently, BOSA has initiated the acceptance and go-live phase of hsmp mtci.
The specs and other useful documentation are maintained below.
Specifications
Swagger: compliant with the applicable standards, this API is subject to one single and comprehensive, machine- and human-readable specification file: hsmp_migration_key.yaml
NB: human-readable rendering can be made more convenient by using specific editors, such as https://editor.swagger.io/Test Plan: compliant with applicable standards, the following resource is made available to enable any (future or current) API-user to perform local tests during its development cyccle: HSMP_migration_key.postman_collection.json (Postman)
NB: above specifications include all possible cases/scenarios, including exceptions/errors. Additionally, during the API development cycle the list of responses codes was gradually elaborated and discussed using the table 1below. This information is still available for tracking purposes only.
Online User-Testing data - practical aspects
The API is available in a test environment to support online user-tests at the end of the user development cycle. This section explains how online tests are organized.
how does it work
we prepared 20 datasets. Each tester gets his own dataset so he can perform his own test without risk of clash with any other tester.
upon request to BOSA, each tester will get an own test dataset assigned.
test data will be recycled daily
below you find a matching of the test data with the scenarios to be tested.
matching test data - test scenario:
(a) Preamble:
- each dataset is subdivided in types of participants,
- each participant of a given type is suitable for a given test scenario.
- bullet (b) below lists the types , and bullet (c) below lists the matching of the types with the datasets
(b) Types of participants:
Type 1: Participants registered in HSMP but not registered in SMK. These are not valid KBO enterprises and therefore cannot be used to migrate to Belgium SMP. (Can be used for load testing, black listing...)
Type 2: Participants flagged as migrated in HSMP but not registered in SMK.
Type 3: Participants flagged as deleted in HSMP but not registered in SMK.
Type 4: Invalid participants
Type 5: Participants registered in HSMP and in SMK. These are valid KBO enterprises and therefore can be used to migrate to Belgium SMP.
(c) Matching with test cases (cf Postman documentation)
| Expand | ||
|---|---|---|
| ||
Case 2.1 : Type 1, Type 5 Case 3.1 : Type 1, Type 5 Case 4.1 : Type 5 Blacklisting : Type 1 |
Additional information:
https://documenter.getpostman.com/view/11381713/T17FCUqp?version=latest
Blacklisting:
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.
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.
Schedule and progress: see table 2 below
Version history
This section will tracks the publication of updates of the documentation
Initial draft published for review purpose
First stable version published along with initiation of development works
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.
(1°) Testing phase schedule adapted. (2°) Test datasets descriptions posted and practical details info updated (in line with our discussions on and the availability of one dataset per tester.)
publication of test results and move to acceptance / go-live phase
Table 1 - responses
scenario | request | response : http response code - detailled response |
|---|---|---|
positive | valid and not yet migrated enterprise number | 200 - OK - the pair enterprise number & migration token |
security 1 | certificate missing | 401 - |
security 2 | error while parsing certificate | 401 - |
security 3 | certificate expired or not yet valid | 401 - |
security 4 | added : not trusted | 401 - |
security 5 | added : Test/Prod mismatch | 401 - |
security 6 | added : not a PEPPOL AP | 401 - |
error 1 | the enterprise number does not correspond to an existing enterprise (or is garbage) | 404 - |
error 2 | the enterprise number was deleted (in the context of the monthly processing of the CBE dump or the admin removal function) | 404 - |
error 3 | the enterprise number that was already migrated to another smp | 404 - |
error 4 | any request of a user that exceeded the blacklisting limit and was not yet reactivated | 403 - you have been blacklisted please contact BOSA |
error 5 | added : any request of a user that broke a network global limit, and was not yet reactivated | 403 - |
error 6 | added : any request of a user that broke an IP-specific limit, and was not yet reactivated | 403 - |
error z | internal server error | 500 - |
Table 2 -Schedule and progress
phase | timing | description | status / comment |
|---|---|---|---|
design | JUNE |
| DONE: initiated → open for comments until → review closed → first stable version of specs published |
development and Tradeshift test | JULY - AUGUST | includes update of the documentation package at end of dev phase | DONE |
user testing | SEPTEMBER | includes collection of test results, fixing, updating the documentation package and teh code if needed
| DONE - results summary available in table 3 below |
BOSA acceptance | OCTOBER | verify that the outcomes of the previous phases meet the expectations | DONE - validation based on user testing results |
Table 3 summary of testing phase results
abstract: All SPs ave been given the opportunity to test hsmp mtci. at , 6 datasets were distributed. positive test results was received from 4 testers. no negative feedback was received
| Expand | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||
|
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 (under revision - please do contact hermes@bosa.fgov.be)
title | abstract | link |
|---|---|---|
1.a. Hermes conditions of use | Contractual description of the Hermes service features and boundaries. | |
1.b. annex to Hermes conditions of use | The conditions of use incorporate a technico-functional appendix that lays out in more detail all the scenarios handled by Hermes and their technical details |
|
2. Hermes Integrators agreement | In addition to the convention of use, DT offers the possibility to integrators to incorporate Hermes in their service offering, and the collection of the senders' agreement with the conditions of use in their own service subscription process. For this the integrator must sign a convention of integration, that describes the responsibilities that the integrator is expected to take to insure smooth operations |
Answers to questions posted by SPs during 8th edition of the forum (23/06/2020)
Question | Answer |
|---|---|
Will we be informed when Babelway is ready and when we can start testing ? Will we get an update on the interface spec? | Yes. BOSA will keep using the BE AP forum page to publish updates in the documentation and project progress, and members will be informed by email. An update will be published soon. This update closes the design phase: the specifications are considered stable enough to move to development. |
Do sender and AP need to sign agreement or is one enough? | The SP needs to sign the integrator’s agreement. The sender needs to sign the sender’s agreement. However, to accommodate the SP’s processes, the formalism is up to the AP, as long as it can be audited that the sender has indeed formally agreed the convention. It does not necessarily need to be a “good old written signature on paper”, but it must be opposable and auditable. |
The agreement should be signed with all the Service Providers in Peppol, not only with Belgian ones, isn't it? | The Belgian restriction applies to senders and receivers, not to SPs. At this stage the convention is only available in the official Belgian languages but foreign APs operating in Belgium can sign it. |
Was the Hermes proposed process submitted to approval of OpenPEPPOL ? | Of course OpenPeppol is informed in detail about the Hermes project. |
The receivers are then in Peppol, and reachable from Peppol everywhere. Michel's point on mixing the reliable Peppol delivery with the mail is really relevant. | It is not only about what is relevant, but also about what is the most relevant. Indeed emails are less reliable but today the sender has no choice anyway. By reconciling both models (as much as possible), we expect to boost the uptake of end-to-end e-invoicing, opening a boulevard for the industry. The risk of losing a few invoices in the process, a risk which exists today anyway, is really minor compared to the benefits. |
Why does the HermeSmp not register all the Belgian entities with a customized version of the bis3 invoice that has a mandatory email address? This would resolve the issue of enforcing it no? | As answered by another forum participant, BIS is mandatory. Hence, even if you register the Hermes receiver with this customized format they still have to receive the BIS V3. See also Hermes - ...- clarification, point “email address” |
If there is a change in the behaviour of PEPPOL, my understanding is that it should be approved by the impacted parties. As an AP, I request this to be put to a formal approval | There is no such change
|
I support Michel that having a standard and efficient way to differentiate receivers in Peppol lookup/directory that are reachable via BIS3 via Peppol to pdf via email delivery from the standard einvoice receivers in Peppol. This maybe achieved by a national process/profile etc. | It is very easy to differentiate a Hermes receiver from others: the Hermes receivers are not published on Peppol Directory. In other words, any Belgian enterprise (identified by his enterprise number) that is not on the Peppol Directory, is a Hermes receiver. |
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:
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).
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.
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.
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 .
closes on .
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:
the conditions of use for senders and its technico-functional annex,
the integrators agreement,
the migration toke collection interface specification.
Documents
title | abstract | link |
|---|---|---|
1.a. Hermes conditions of use | Contractual description of the Hermes service features and boundaries. | |
1.b. annex to Hermes conditions of use | The conditions of use incorporate a technico-functional appendix that lays out in more detail all the scenarios handled by Hermes and their technical details | |
2. Hermes Integrators agreement | In addition to the convention of use, DT offers the possibility to integrators to incorporate Hermes in their service offering, and the collection of the senders' agreement with the conditions of use in their own service subscription process. For this the integrator must sign a convention of integration, that describes the responsibilities that the integrator is expected to take to insure smooth operations | |
3. HermeSMP (hsmp) migration token collection interface | offers the Peppol APs the possibility to automate the collection of the Hermes participants migration tokens. It is a REST service with the same security as smp.belgium.be. This interface specification consists in (a) a swagger; (b) a Test Plan , and (c) additional info if needed | (a) swagger: hsmp_migration_key.yaml |
(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”
scenario | request | response :: http - detail |
|---|---|---|
positive | valid and not yet migrated enterprise number | 200 - the pair enterprise number & migration token |
security 1 | certificate missing | 401 - no certificate provided with the request |
security 2 | error while parsing certificate | 401 - error while parsing client certificate |
security 3 | certificate expired or not yet valid | 401 - client certificate expired or not yet valid |
error 1 | the enterprise number does not correspond to an existing enterprise (or is garbage) | 404 - invalid or non-existing enterprise number + id |
error 2 | the enterprise number was deleted (in the context of the monthly processing of the CBE dump or the admin removal function) | 404 - inactive enterprise number + id |
error 3 | the enterprise number that was already migrated to another smp | 404 - already migrated + id |
error 4 | any request of a used that exceeded the blacklisting limit and was not yet reactivated |
|
error 5 | internal server error | 500 - internal server error |
Visual
(hsmp) migration token collection interface - Additional info
Proposed schedule
phase | time | what |
|---|---|---|
design | JUNE |
|
development and babelway test | JULY |
|
user testing | AUGUST |
|
BOSA acceptance | SEPTEMBER |
|
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.