Info |
---|
Welcome Enjoy your visit and let us know! |
...
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.
...
In an initial phase of the use of Peppol, the Belgian enterprise number has been assigned a PEPPOL 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, proceeded with the due registration of the enterprise number. ICD 0208 was assigned in april 2020, and recorded in EAS in june 2020.Consequently the migration of
9956
to0208
introduction was necessary. It was coordinated in the present section.
Timeline
...
Additional Coordination notes
Due to the remaining use of the
old BIS (2.0) MLR
(aka. “MLRv1”"MLRv1") at end of the migration , schemeID9956
removal could not be completely removedAt forum it was decided that the minimal scenario will be complemented with regular scheduled. Deprecation ofold BIS MLR
was not possible untilBIS IMR
was duly introduced in B2G invoicing. Use ofBIS IMR
to return B2G invoice responses was introduced in March 2022; use ofold BIS MLR
to return B2G invoice responses was interrupted in September 2022. -> schemeID9956
removal discussions are reprogrammed on the SP forum.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 Stage 1 : Stop registering new participants under scheme ID 9956.
stage Stage 2 : Finish migrating 100% of portfolio from scheme ID 9956 to scheme ID 0208.
stage Stage 3 : Exclusive use of Scheme ID 0208 for all existing and new participants.
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.
...
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 took measures to phase out all non-BIS (3.0) traffic reaching it. old BIS receiving capability will be (2.0) BILLING receiving capability of Government entities was removed (a) from the test environment on and (b) from production on Dec 2020A change is planned to also reject .
NB: Although this is not supposed to happen, technically speaking, smp.belgium.be does not reject new registration based on old BIS (2.0), provided that BIS (3.0)
...
stay tuned!
equivalent receiving capability is already registered, no explicit cleanup of old BIS-based receiving capabilities has been executed yet on smp.belgium.be . Until the removal of the related identifier is decided, it is the responsibility of each service provider to duly assist their end users in properly de-registering deprecated receiving capabilities.
...
Hsmp migration token collection interface
Abstract
as 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 Belgian 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 toolstool, BOSA decided to (1) initiate migration for all hrmsparticipants hrms participants 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.
...
NB: above specifications include all possible cases/scenarios, including exceptions/errors. Additionally, during the API development cycle the list of responses response codes was gradually elaborated and discussed using the table 1below. This information is still available for tracking purposes only.
...
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 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 Upon request to BOSA, each tester will get an own test dataset assigned.
test Test data will be recycled daily.
below Below you find a matching of the test data with the scenarios to be tested.
...
(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)
...
https://documenter.getpostman.com/view/11381713/T17FCUqp?version=latest
Blacklisting:
this This service allows a maximum of 1000 collections per day. the 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 track the publication of updates of the documentation.
Initial draft published for review purpose.
First stable version published along with initiation of development workswork.
ready for acceptance testing. resources Resources HSMP_migration_key.postman_collection.json, hsmp_migration_key.yaml and https://documenter.getpostman.com/view/11381713/T17FCUqp?version=latest updated. overview 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 - |
---|
detailed 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
abstractAbstract: All SPs ave been given the opportunity to test hsmp mtci. at , 6 datasets were distributed. positive Positive test results was were received from 4 testers. no No negative feedback was received.
Expand | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||
|
...
Hermes
...
agreement framework
Hermes helps leveraging B2G e-invoicing adoption on B2B e-invoicing adoption in Belgium. It makes it possible to Belgian Peppol invoice senders, to reach all their Belgian customers on Peppol. For juridical reasons, its use requires a specific agreement between the sender and the Belgian government (represented by BOSA), in addition to the Peppol agreements. Service providers are invited to support this and integrate Hermes in their service offering. Access to Hermes is free of charge for the Service Provider. BOSA designed agreements that fulfill these purposes. The Belgian SP/AP forum members reviewed the initial agreements (minimal viable product) in June 2020, and the updated agreement (improved version) in Q3 2022. In this latest version, the agreement as such provides the terms and conditions that specifically apply to the integrator, while other terms and conditions are listed in annexes listed at the end of the agreement. It is the case of (a) generic terms and conditions, (b) terms and conditions that apply to the sender, in his quality of user of Hermes, and the receiver in his quality of end-user (ultimate beneficiary) of Hermes, and (c) technical, functional and security guidelines.
The Hermes integrator agreement template can be found at the following address:
...
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 SD 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.
...
Be a Belgian enterprise
BOSA DT SD 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 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 token 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
...
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.