Versions Compared

Old Version 47

changes.mady.by.user Serge Libert

Saved on

compared with

New Version Current

changes.mady.by.user Guido Doucet

Saved on

Key

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

Welcome
BOSA, the Belgian Peppol Authority, welcomes you to this collaboration area dedicated to the Belgian jurisdiction. It supports the forums that we are used to organize since 2016 to assist the IT sector in widening the eInvoicing and eProcurement solutions in the Belgian market.
→ The structure of this area will grow gradually to best fit with the discussions and opportunities that will arise.

Enjoy your visit and let us know!
the eInvoicing team @BOSA

...

  1. AP sends the 9 invoice and informs BOSA once the set is duly sent.

  2. 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 to 0208 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") at end of the migration , schemeID 9956 removal could not be scheduled. Deprecation of old BIS MLR was not possible until BIS IMR was duly introduced in B2G invoicing. Use of BIS IMR to return B2G invoice responses was introduced in March 2022; use of old BIS MLR to return B2G invoice responses was interrupted in September 2022. -> schemeID 9956 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 took measures to phase out all non-BIS (3.0) traffic reaching it. old BIS (2.0) BILLING receiving capability of Government entities was removed (a) from the test environment on and (b) from production on .

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

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

  2. upon Upon request to BOSA, each tester will get an own test dataset assigned.

  3. test Test data will be recycled daily.

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

...

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

  2. Blacklisting:

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

    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. Schedule and progress: see table 2 below.

Version history

This section will tracks track the publication of updates of the documentation.

  1. Initial draft published for review purpose.

  2. First stable version published along with initiation of development workswork.

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

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

  5. publication of test results and move to acceptance / go-live phase.

Table 1 -

...

Responses

scenario

Scenario

request

Request

response

Response : http response code -

detailled

detailed response

positive

valid and not yet migrated enterprise number

200 - OK - the pair enterprise number & migration token

security 1

certificate missing

401 - HSMP-802: no certificate supplied with the request

security 2

error while parsing certificate

401 - HSMP-803: error while parsing client certificate

security 3

certificate expired or not yet valid

401 - HSMP-804: client certificate expired or not yet valid

security 4

added : not trusted

401 - HSMP-805 :Certificate cannot be trusted by PEPPOL trustStore

security 5

added : Test/Prod mismatch

401 - HSMP-806 : Certificate environment does not match with requested environment (test or prod)

security 6

added : not a

PEPPOL

Peppol AP

401 - HSMP-808: Certificate is not a PEPPOL ACCESS POINT certificate

error 1

the enterprise number does not correspond to an existing enterprise (or is garbage)

404 - HSMP-001: 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 - HSMP-012: inactive enterprise number + id

error 3

the enterprise number that was already migrated to another smp

404 - HSMP-013: already migrated + id

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 - HSMP-812 : Global limit reached. Please contact BOSA

error 6

added : any request of a user that broke an IP-specific limit, and was not yet reactivated

403 - HSMP-813 : Limit reached for IP. Please contact BOSA

error z

internal server error

500 - HSMP-999: The service encountered an internal error

Table 2 -Schedule and progress

phase

Phase

timing

Timing

description

Description

status / comment

design

Design

JUNE

  • AP forum: discuss the interface specifications, practicalities

  • then post a draft proposal to collect comments (2weeks)

  • then publish (initial) documentation package ( swagger + Test plan + read-me ) and schedule on agreed repository

DONE: initiated → open for comments until → review closed → first stable version of specs published

development

Development and Tradeshift test

JULY - AUGUST

includes

Includes update of the documentation package at end of dev phase.

DONE

user

User testing

SEPTEMBER

includes

Includes collection of test results, fixing, updating the documentation package and teh code if needed

sub

  • Sub phase 1: early bird testing with close support by Tradeshift : -

sub

  • Sub phase 2: wide-scale testing with any volunteer with BOSA support (Tradeshift in L2): -

DONE - results summary available in table 3 below

BOSA acceptance

OCTOBER

verify

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
titleCLICK HERE to expand/collapse detailed information

Dataset ID

SP

Feedbacks?

supporting evidence

1

BILLIT

OK 2.10

I did some basic tests and was able to migrate an active participant and register it to Belgium SMP and then register it for the wanted DocumentTypes.
This all went very smooth.
I also tested some of the other paths and everything seems in order with the documentation.
These tests were not very extensive, I was not yet able to test the all the cases and was not yet able to do some load tests.

2

IXOR

OK 23.9

I ran the collection file once per type. At first sight everything seems to be ok.
Please find in attachment the exported results from postman runner.
Mathieu's reaction: I am glad that your first tests were successful.
Did you get a chance to perform a second round of testing? Do you need any help or clarification from us? Don't hesitate to call me if you have any questions.

3

Inaras

via Wim Maerevoet 23.9

No information upon start. No feedback on tests.

4

codabox

Started 6.10 - question raised, ticket open at TS, answer given

We started the testing and noticed there is a connection issue with the Hermes SMP. Could you confirm we can start using the Hermes SMP with our Peppol AP certificates for the test network?
When we try to reach the smp-test.belgium.be with the certificates everything if working as expected, but when trying to reach spm.acc-hermes-belgium.be we receive no response (see attached image).
Could you have a look what happened and how we should connect?
answer from Tradeshift: The root cause of the issue is simply the TLS certificate that is not the final one  for smp.acc-hermes-belgium.be (fyi, was misspell in the support request) .
Is it possible to simply ignore the TLS error for the moment until we have the proper certificate in place?

5

Soluz.io

via Walter Vander Goten(7.10)

No information upon start. No feedback on tests.

6

netropolix

via Jeroen Cuppens (12.10), feedback 12.10

Thanks for the test dataset.
Since we only have a small amount of customers using Peppol, we currently do all registrations with Postman.
So we were able to do all required testing by using the provided Postman collection of the confluence page.
All API calls worked as expected. 

7

B2B Router

via Oriol Bausà Peris (13.10)

No information upon start. No feedback on tests.

...

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

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

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.
Another way to look up this information, that is cleaner from a technical perspective (but may be harder for a lambda user), is to query hsmp directly.

...

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:

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

    2. the integrators agreement,

    3. 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.
The enterprise wishing to use Hermes in his outbound invoicing must accept these conditions

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
(b) Test plan: see test plan section
(c) additional info: see additional info section

(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

429 403 - you have been blacklisted please contact BOSA

error 5

internal server error

500 - internal server error

Visual

...

(hsmp) migration token collection interface - Additional info

Proposed schedule

phase

Phase

time

Time

what

What

design

Design

JUNE

  • AP forum: discuss the interface specifications, practicalities.

then

  • Then post a draft proposal to collect comments (

2weeks

  • 2 weeks).

then

  • Then publish (initial) documentation package ( swagger + Test plan + read-me ) and schedule on agreed repository.

development

Development and

babelway

Babelway test

JULY

includes

  • Includes update of the documentation package at end of dev phase.

user

User testing

AUGUST

includes

  • Includes collection of test results, fixing, updating the documentation package.

BOSA acceptance

SEPTEMBER

verify

  • Verify that the outcomes of the previous phases meet the expectations.

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.