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)

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

2. Initial round
   This test set validates the behavior of hrms when the AP is not yet registered on the whitelist.

3. Main round
   This test set validates the behavior of hrms when the AP is registered on the whitelist and no email address is recorded.

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

5. 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:

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.

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.

Status

• Introduction of schemeID 0208 completed :

  • initiated with Peppol BIS schematron summer 2020 release

  • completed at the initiation of the schemeID 9956 removal

• Removal of schemeID 9956 :

  • Deprecation

    • initiated with the BIS schematron spring 2021 release and

    • completed with the BIS schematron fall 2021 release

  • Removal : scheduled Sep 1, 2023

History

Background

• In an initial phase of the use of Peppol, the Belgian 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, 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

Open

Additional Coordination notes

• Due to the remaining use of the old BIS (2.0) MLR (aka. "MLRv1") at end of the migration May 1, 2021 , 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 Sep 15, 2020 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.

• At Jul 14, 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.

• Since Jun 28, 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 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 Oct 1, 2020 and (b) from production on Mar 31, 2021 .

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.

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 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 tool, BOSA decided to (1) initiate migration for all 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 Jul 3, 2020 . The interface is ready for tests as of Sep 14, 2020 The testing window closed on Oct 16, 2020 . 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

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

2. 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 response codes was gradually elaborated and discussed using the table 1 below. 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

1. 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 request to BOSA, each tester will get an own test dataset assigned.

3. Test data will be recycled daily.

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

Additional information:

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

2. Blacklisting:

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

Version history

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

1. Initial draft published Jun 3, 2020 for review purpose.

2. First stable version published Jul 3, 2020 along with initiation of development work.

3. Sep 11, 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.

4. Sep 22, 2020 (1°) Testing phase schedule adapted. (2°) Test datasets descriptions posted and practical details info updated (in line with our discussions on Sep 15, 2020 and the availability of one dataset per tester).

5. Oct 23, 2020 publication of test results and move to acceptance / go-live phase.

Table 1 - Responses

Table 2-Schedule and progress

Table 3 - Summary of testing phase results

Abstract: All SPs ave been given the opportunity to test hsmp mtci. at Oct 19, 2020 , 6 datasets were distributed. Positive test results were received from 4 testers. No negative feedback was received.