This document is an excerpt from the EUR-Lex website
Document 02016R0480-20231025
Commission Implementing Regulation (EU) 2016/480 of 1 April 2016 establishing common rules concerning the interconnection of national electronic registers on road transport undertakings and repealing Regulation (EU) No 1213/2010 (Text with EEA relevance)Text with EEA relevance
Consolidated text: Commission Implementing Regulation (EU) 2016/480 of 1 April 2016 establishing common rules concerning the interconnection of national electronic registers on road transport undertakings and repealing Regulation (EU) No 1213/2010 (Text with EEA relevance)Text with EEA relevance
Commission Implementing Regulation (EU) 2016/480 of 1 April 2016 establishing common rules concerning the interconnection of national electronic registers on road transport undertakings and repealing Regulation (EU) No 1213/2010 (Text with EEA relevance)Text with EEA relevance
02016R0480 — EN — 25.10.2023 — 002.001
This text is meant purely as a documentation tool and has no legal effect. The Union's institutions do not assume any liability for its contents. The authentic versions of the relevant acts, including their preambles, are those published in the Official Journal of the European Union and available in EUR-Lex. Those official texts are directly accessible through the links embedded in this document
COMMISSION IMPLEMENTING REGULATION (EU) 2016/480 of 1 April 2016 establishing common rules concerning the interconnection of national electronic registers on road transport undertakings and repealing Regulation (EU) No 1213/2010 (OJ L 087 2.4.2016, p. 4) |
Amended by:
|
|
Official Journal |
||
No |
page |
date |
||
COMMISSION IMPLEMENTING REGULATION (EU) 2017/1440 of 8 August 2017 |
L 206 |
3 |
9.8.2017 |
|
COMMISSION IMPLEMENTING REGULATION (EU) 2023/2381 of 29 September 2023 |
L |
1 |
5.10.2023 |
COMMISSION IMPLEMENTING REGULATION (EU) 2016/480
of 1 April 2016
establishing common rules concerning the interconnection of national electronic registers on road transport undertakings and repealing Regulation (EU) No 1213/2010
(Text with EEA relevance)
Article 1
Subject matter
This Regulation lays down the requirements regarding the connection of the national electronic registers on road transport undertakings to the ERRU messaging system, as set out in Article 16(5) of Regulation (EC) No 1071/2009.
Article 2
Definitions
For the purpose of this Regulation and in addition to the definitions laid down in Article 2 of Regulation (EC) No 1071/2009, the following definitions shall apply:
‘ERRU (European Registers of Road Transport Undertakings)’ means a system of interconnection of national electronic registers, set up in accordance Article 16(5) of Regulation (EC) No 1071/2009;
‘Asynchronous interface’ means a process whereby a message in response to a request is returned on a new HTTP connection;
‘Broadcast search’ means a request message from a Member State addressed to all other Member States;
‘Central hub’ means the information system enabling the routing of ERRU messages between Member States;
‘CPC’ means certificate of professional competence, as referred to in Article 8(8) of Regulation (EC) No 1071/2009;
‘Member State of infringement’ means the Member State in which a transport undertaking has committed an infringement;
‘Member State of establishment’ means the Member State in which an undertaking is established;
‘National system’ means the information system set up in each Member State for the purpose of emitting, processing and responding to ERRU messages;
‘Synchronous interface’ means a process whereby a message in response to a request is returned on the same HTTP connection as the one used for the request;
‘Requesting Member State’ means the Member State emitting a request or a notification, which is then routed to the responding Member States;
‘Responding Member State’ means the Member State to whom the ERRU request or notification is directed;
‘Clean check’ means a check where no infringements are detected.
Article 3
Obligation to connect to ERRU
Member States shall carry out the interconnection of the national electronic registers referred to in Article 16 of Regulation (EC) No 1071/2009 to ERRU in accordance with the procedures and technical requirements laid down in this Regulation.
The connection to ERRU of a Member State shall be considered to be established after the completion of the connection, integration and performance tests in accordance with the instructions and under the supervision of the Commission. The maximum duration of the tests shall be six months. The Commission shall take measures in case of failure of the above-mentioned tests. If those measures prove insufficient, the Commission may withdraw the testing support until the Member State proves that sufficient progress has been made at national level regarding connection to ERRU.
Article 4
Technical specifications
ERRU shall fulfil the technical specifications laid down in Annexes I to VII to this Regulation.
Article 5
Use of ERRU
Article 6
Repeal
Regulation (EU) No 1213/2010 is hereby repealed as from the date of application of this Regulation. References to the repealed Regulation shall be construed as references to this Regulation.
Article 7
Entry into force
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.
It shall apply from 30 January 2019.
This Regulation shall be binding in its entirety and directly applicable in all Member States.
ANNEX I
GENERAL ASPECTS OF ERRU
1. ARCHITECTURE
ERRU shall be composed of the following parts:
A central hub, which shall be able to receive a request from the requesting Member State, validate it and process it by forwarding it to the responding Member States. The central hub will wait for each responding Member State to answer, consolidate all the answers and forward the consolidated response to the requesting Member State.
A national system per Member State, which shall be fitted with an interface capable of both sending requests to the central hub and receiving the corresponding replies. National systems may use propriety or commercial software to transmit and receive messages from the central hub.
All messages exchanged shall be routed through the central hub.
2. MANAGEMENT
2.1. |
The central hub shall be managed by the Commission, which shall be responsible for the technical operation and maintenance of the central hub. |
2.2. |
The central hub shall not store data for a period exceeding 6 months, other than the logging, statistical and routing data set out in Annex VII. |
2.3. |
The central hub shall not provide access to personal data, except for authorised Commission personnel, when necessary for the purpose of monitoring the technical operation, maintenance and troubleshooting. |
2.4. |
Member States shall be responsible for:
2.4.1.
The setup and management of their national systems, including the interface with the central hub.
2.4.2.
The installation and maintenance of their national system, both hardware and software, whether proprietary or commercial.
2.4.3.
The correct interoperability of their national system with the central hub, including the management of error messages received from the central hub.
2.4.4.
Taking all the measures to ensure the confidentiality, integrity and availability of the information.
2.4.5.
The operation of the national systems in accordance with the service levels set out in Annex VI. |
2.5. |
MOVEHUB web portal The Commission shall provide a web based application with secured access, referred to as ‘MOVEHUB web portal’, providing at least the following services:
(a)
Member State availability statistics
(b)
Notification of maintenance on the central hub and Member State national systems.
(c)
Aggregated reports
(d)
Contact management
(e)
XSD schemas |
2.6. |
Contact management The contact management functionality will provide each Member State with the ability to manage the contact details regarding policy, business, operational and technical categories of that Member State, being each Member State's competent authority responsible for the maintenance of its own contacts. It will be possible to view, but not edit, the contact details of the other Member States. |
ANNEX II
ERRU FUNCTIONALITIES
1. The following functionalities shall be provided through ERRU:
Check Good Repute (CGR): allows the requesting Member State to send a query to one or all responding Member States, to determine the fitness of a transport manager and so the authorisation to operate a transport undertaking.
Notification of Check Result (NCR): allows the Member State where the check was carried out to notify the result of a check to the Member State of establishment. When a serious infringement has been found during the check, the Member State where the infringement was detected notifies the Member State of establishment through NCR that the transport undertaking has committed a serious infringement, and may request penalties to be applied to the transport undertaking in the Member State of establishment. When no infringement has been detected during the check, NCR allows the Member State where the check has been carried out to notify the Member State of establishment the positive result of the check.
Check Transport Undertaking Data (CTUD): allows the requesting Member State to send a query to the responding Member State about the following data that are specific to a transport undertaking:
Notification of Unfitness (NU): allows a Member State to inform all other Member States that a transport manager has been declared unfit and that as a result, its certificate of professional competence is no longer valid in any Member State.
2. Other message types deemed suitable for the efficient functioning of ERRU shall be included, for instance error notifications.
ANNEX III
ERRU MESSAGE PROVISIONS
1. GENERAL TECHNICAL REQUIREMENTS
1.1. |
The central hub will provide both synchronous and asynchronous interfaces for the exchange of messages. Member States may choose the most suitable technology to interface with their own applications. |
1.2. |
All messages exchanged between the central hub and the national systems must be UTF-8 encoded. |
1.3. |
Member States will ensure that their national systems can receive and process messages containing Greek or Cyrillic characters. |
2. XML MESSAGES STRUCTURE AND SCHEMA DEFINITION (XSD)
2.1. |
The general structure of XML messages shall follow the format defined by the XSD schemas installed in the central hub. |
2.2. |
The central hub and the national systems shall transmit and receive messages that conform to the message XSD schema. |
2.3. |
National systems will be capable of sending, receiving and processing all messages corresponding to any of the functionalities set out in Annex II. |
2.4. |
The XML messages shall include at least the minimum requirements laid down in the Appendix to this Annex. |
Appendix
Minimum requirements for the content of the XML messages
Common Header |
Mandatory |
|
Version |
The official version of the XML specifications will be specified through the namespace defined in the message XSD and in the version attribute of the Header element of any XML message. The version number (‘n.m’) will be defined as fixed value in every release of the XML Schema Definition file (xsd). |
Yes |
Test Identifier |
Optional id for testing. The originator of the test will populate the id and all participants in the workflow will forward/return the same id. In production it should be ignored and will not be used if it is supplied. |
No |
Technical Identifier |
A UUID uniquely identifying each individual message. The sender generates a UUID and populates this attribute. This data is not used in any business capacity. |
Yes |
Workflow Identifier |
The workflowId is a UUID and should be generated by the requesting Member State. This id is then used in all messages to correlate the workflow. |
Yes |
Sent At |
The date and time (UTC) that the message was sent. |
Yes |
Timeout |
This is an optional date and time (in UTC format) attribute. This value will be set only by the central hub for forwarded requests and is calculated based on the date/time the initial request has been received by the central hub. This will inform the responding Member State of the time when the request will be timed out. This value is not required in initial requests sent to the central hub and all response messages. |
No |
From |
The ISO 3166-1 Alpha 2 code of the Member State sending the message or ‘EU’. |
Yes |
To |
The ISO 3166-1 Alpha 2 code of the Member State to which the message is being sent or ‘EU’. |
Yes |
Check Good Repute
Check Good Repute Request |
Mandatory |
|
Business Case Identifier |
A serial or reference number identifying each individual request. |
Yes |
Requesting Competent Authority |
The competent authority that has issued the search request. |
Yes |
Transport Manager Details |
Yes, if no CPC details |
|
Family Name |
Transport manager’s family name(s) as indicated on the CPC. |
Yes |
First Name |
Transport manager’s complete given name as indicated on the certificate of professional competence. |
Yes |
Date of Birth |
Transport manager’s birth date in ISO 8601 format (YYYY-MM-DD). |
Yes |
Place of Birth |
Transport manager’s place of birth. |
No |
Address |
The address, city, postcode and country of the transport manager. |
No |
CPC Details |
Yes, if no transport manager details |
|
CPC Number |
Number of certificate of professional competence |
Yes |
CPC Issue Date |
Date of issuance of the CPC, in ISO 8601 format (YYYY-MM-DD). |
Yes |
CPC Issue Country |
Issuing country of the CPC in ISO 3166-1 alpha 2 format. |
Yes |
Check Good Repute Response |
Mandatory |
|
Business Case Identifier |
A serial or reference number matching the business case identifier of the request. |
Yes |
Requesting Competent Authority |
The competent authority that has issued the search request. |
Yes |
Responding Competent Authority |
The competent authority that has responded to the search request. |
Yes |
Status Code |
The status code of the search (e.g. found, not found, error, etc.). |
Yes |
Status Message |
An explanatory status description (if necessary). |
No |
Found Transport Manager Details |
Yes if Status Code is Found |
|
Family Name |
Transport manager’s family name(s) as recorded in the register. |
Yes |
First Name |
Transport manager’s complete given name as recorded in the register. |
Yes |
Date of Birth |
Transport manager’s birth date in ISO 8601 format (YYYY-MM-DD) as recorded in the register. |
Yes |
Place of Birth |
Transport manager’s place of birth as recorded in the register. |
No |
CPC Number |
Number of certificate of professional competence as recorded in the register. |
Yes |
CPC Issue Date |
Date of issuance of the CPC, in ISO 8601 format (YYYY-MM-DD) as recorded in the register. |
Yes |
CPC Issue Country |
Issuing country of the CPC in ISO 3166-1 alpha 2 format as recorded in the register. |
Yes |
CPC Validity |
Declaration of either ‘Valid’ or ‘Invalid’ |
Yes |
Total Managed Undertakings |
The number of transport undertakings with which the transport manager is associated. |
Yes |
Total Managed Vehicles |
The total number of vehicles with which the transport manager is associated. |
Yes |
Fitness |
Declaration of either ‘Fit’ or ‘Unfit’. |
Yes |
Start Date of Unfitness |
Start date of unfitness of the transport manager in ISO 8601 format (YYYY-MM-DD). |
Yes if ‘Fitness’ is ‘Unfit’. |
End Date of Unfitness |
End date of unfitness of the transport manager in ISO 8601 format (YYYY-MM-DD). |
Yes if ‘Fitness’ is ‘Unfit’. |
Search Method |
The method used to find the transport manager: NYSIIS, CPC, Custom. |
Yes |
Transport Undertaking (for each found Transport Manager) |
Yes if Managed Undertakings > 0 |
|
Transport Undertaking Name |
The name of the transport undertaking (name and legal form) as recorded in the register. |
Yes |
Transport Undertaking Address |
The address of the transport undertaking (address, postal code, city, country) as recorded in the register. |
Yes |
Community Licence Number |
The serial number of the Community licence of the transport undertaking (free text alphanumeric field with length 1 to 20). |
Yes |
Community Licence Status |
The status of the community licence of the transport undertaking as recorded in the register. |
Yes |
Managed Vehicles |
The number of vehicles managed as recorded in the register. |
Yes |
Notification of Check Result
Notification of Check Result |
Mandatory |
|
Business Case Identifier |
A serial or reference number identifying each individual notification. |
Yes |
Notifying Competent Authority |
The competent authority that issues the notification. |
Yes |
Transport Undertaking |
Yes |
|
Transport Undertaking Name |
The name of the transport undertaking being object of the check. |
Yes |
Community Licence Number |
The serial number of the community licence or of the certified true copy of the transport undertaking (free text alphanumeric field with length 1 to 20). |
Yes |
Vehicle Registration Number |
The vehicle registration number of the vehicle checked |
Yes |
Vehicle Registration Country |
The country in which the vehicle checked is registered |
Yes |
General information about the check |
|
|
Date of check |
Date of check in ISO 8601 format (YYYY-MM-DD) |
Yes |
Clean check |
Yes/No |
Yes |
Minor infringements |
Yes, if minor infringement(s) detected during the check |
|
Date of minor infringement |
Date of the infringement in ISO 8601 format (YYYY-MM-DD) |
Yes |
Number of minor infringements |
The number of minor infringements detected. |
Yes |
Serious infringement |
Yes, if serious infringement detected during the check |
|
Date of Infringement |
Date of the infringement in ISO 8601 format (YYYY-MM-DD) |
Yes |
Category |
The category of the infringement: — MSI: Most serious infringement — VSI: Very serious infringement — SI: Serious infringement |
Yes |
Infringement Type |
In accordance with the classification provided in Annex IV to Regulation (EC) No 1071/2009 and Annex I to Commission Regulation No (EU) 2016/403 (1) |
Yes |
Appeal Possible |
If an appeal against the infringement is still possible at the time of notification. Yes/No |
Yes |
Penalty Imposed (for each serious infringement) |
Yes, if relevant |
|
Penalty Imposed Identifier |
The serial number of the individual penalty imposed. |
Yes |
Final Decision Date |
The final decision date of the penalty imposed in ISO 8601 format (YYYY-MM-DD). |
Yes |
Penalty Type Imposed |
Declaration of either: — 101: ‘Warning’ — 201: ‘Temporary ban on cabotage operations’ — 202: ‘Fine’ — 203: ‘Prohibition’ — 204: ‘Immobilisation’ — 102: ‘Other’ |
Yes |
Start Date |
The start date of the penalty imposed in ISO 8601 format (YYYY-MM-DD) |
No |
End Date |
The end date of the penalty imposed in ISO 8601 format (YYYY-MM-DD) |
No |
Executed |
Yes/No |
Yes |
Penalty Requested (for each Serious Infringement) |
No |
|
Penalty Requested Identifier |
The serial number of the individual penalty requested. |
Yes |
Penalty Type Requested |
Declaration of either: — 101: ‘Warning’ — 301: ‘Temporary withdrawal of some or all of the certified true copies of the Community licence’ — 302: ‘Permanent withdrawal of some or all of the certified true copies of the Community licence’ — 303: ‘Temporary withdrawal of the Community licence’ — 304: ‘Permanent withdrawal of the Community licence’ — 305: ‘Suspension of the issue of driver attestations’ — 306: ‘Withdrawal of driver attestations’ — 307: ‘Issue of driver attestations subject to additional conditions in order to prevent misuse’ |
Yes |
Duration |
The duration of the requested penalty (calendar days). |
No |
(1)
Commission Regulation (EU) 2016/403 of 18 March 2016 supplementing Regulation (EC) No 1071/2009 of the European Parliament and of the Council with regard to the classification of serious infringements of the Union rules, which may lead to the loss of good repute by the road transport operator, and amending Annex III to Directive 2006/22/EC of the European Parliament and of the Council (OJ L 74, 19.3.2016, p. 8). |
Notification of Check Result Response |
Mandatory, if infringement(s) detected during the check |
|
Business Case Identifier |
A serial or reference number matching the business case identifier of the notification. |
Yes |
Originating Competent Authority |
The competent authority that issued the original infringement notification. |
Yes |
Licensing Competent Authority |
The competent authority responding to the infringement notification. |
Yes |
Status Code |
The status code of the infringement response (e.g. found, not found, error, etc.). |
Yes |
Status Message |
An explanatory status description (if necessary). |
No |
Transport Undertaking |
Yes |
|
Transport Undertaking Name |
The name of the transport undertaking as recorded in the register. |
Yes |
Transport Undertaking Address |
The address of the transport undertaking (address, postal code, city, country) as recorded in the register. |
Yes |
Community Licence Number |
The serial number of the community licence of the transport undertaking as recorded in the register (free text alphanumeric field with length 1 to 20). |
Yes |
Community Licence Status |
The status of the community licence of the transport undertaking as recorded in the register. |
Yes |
Penalty Imposed |
No |
|
Penalty Imposed Identifier |
The serial number of the individual penalty imposed (given in the Penalty Requested Identifier of the Notification of Check Result). |
Yes |
Competent Authority Imposing Penalty |
The name of the competent authority imposing the penalty. |
Yes |
Is Imposed |
Yes/No |
Yes |
Penalty Type Imposed |
Declaration of either: — 101: ‘Warning’ — 301: ‘Temporary withdrawal of some or all of the certified true copies of the Community licence’ — 302: ‘Permanent withdrawal of some or all of the certified true copies of the Community licence’ — 303: ‘Temporary withdrawal of the Community licence’ — 304: ‘Permanent withdrawal of the Community licence’ — 305: ‘Suspension of the issue of driver attestations’ — 306: ‘Withdrawal of driver attestations’ — 307: ‘Issue of driver attestations subject to additional conditions in order to prevent misuse’ — 102: ‘Other’ |
Yes |
Start Date |
The start date of the penalty imposed in ISO 8601 format (YYYY-MM-DD). |
No |
End Date |
The end date of the penalty imposed in ISO 8601 format (YYYY-MM-DD). |
No |
Reason |
Reason if penalty is not imposed. |
No |
Notification of Check Result Acknowledgement |
Mandatory |
|
Business Case Identifier |
A serial or reference number matching the business case identifier of the notification or the response. |
Yes |
Status Code |
Status code of the acknowledgement. |
Yes |
Status Message |
Status Message String |
No |
Originating Competent Authority |
For a NCRN_Ack: in the legislation this field is represented as ‘Destination Competent Authority Identifier’. For a NCRR_Ack: in the legislation this field is represented as ‘Acknowledging Competent Authority Identifier’. |
Yes |
Licensing Competent Authority |
For a NCRN_Ack: in the legislation this field is represented as ‘Acknowledging Competent Authority Identifier’. For a NCRR_Ack: in the legislation this field is represented as ‘Destination Competent Authority Identifier’. |
Yes |
Acknowledgement Type |
Defining Acknowledgement Type Possible Values: — ‘NCRN_Ack’ — ‘NCRR_Ack’ |
Yes |
Check Transport Undertaking Data
Check Transport Undertaking Data Request |
Mandatory |
|
Business Case Identifier |
A serial or reference number identifying each individual request. |
Yes |
Originating Competent Authority |
The competent authority issuing the search request. |
Yes |
Transport Undertaking Identification |
Yes |
|
Transport Undertaking Name |
The name of the transport undertaking. |
At least two of the search fields are required. |
Community Licence Number |
The serial number of the community licence or of the certified true copy (free text alphanumeric field with length 1 to 20). |
|
Vehicle Registration Number |
The registration number of one of the vehicles of the transport undertaking. |
|
Vehicle Registration Country |
The country of registration of the vehicle. |
Yes, if vehicle registration number provided. |
Request All Vehicles |
To request the registration numbers of all vehicles managed by the undertaking. Yes/No |
Yes |
Check Transport Undertaking Data Response |
Mandatory |
|
Business Case Identifier |
A serial or reference number identifying each individual request |
Yes |
Originating Competent Authority |
The competent authority issuing the search request. |
Yes |
Responding Competent Authority |
The competent authority providing the response. |
Yes |
Status Code |
The status code of the response (e.g. found, not found, error, etc.). |
Yes |
Status Message |
An explanatory status description (if necessary). |
No |
General Information about the Transport Undertaking |
Yes, if status code is found |
|
Transport Undertaking Name |
The name of the transport undertaking (name and legal form). |
Yes |
Transport Undertaking Address |
The address of the transport undertaking (address, postal code, city, country) as recorded in the register |
Yes |
Number of Managed Vehicles |
The number of vehicles managed as recorded in the register. |
Yes |
Number of People Employed |
The number of people employed in the undertaking on last 31 December. |
Yes |
Risk Rating |
The risk rating of the undertaking. |
Yes |
Risk Rating Band |
The risk rating band of the undertaking (green, amber, red, grey). |
Yes |
Community Licence Details |
Yes, if status code is found |
|
Licencing Competent Authority |
The competent authority that issued the community licence to the transport undertaking |
Yes |
Community Licence Number |
The serial number of the community licence of the transport undertaking as recorded in the register (free text alphanumeric field with length 1 to 20) |
Yes |
Licence Status |
The status of the community licence of the transport undertaking as recorded in the register |
Yes |
Licence Type |
The type of the community licence as recorded in the register. A declaration of: — ‘Community licence for passenger transport’ — ‘National licence for passenger transport’ — ‘Community licence for goods transport’ — ‘Community licence for goods transport, exclusively ≤ 3,5 t’ — ‘National licence for goods transport’ |
Yes |
Start Date |
The start date of the community licence |
Yes |
Expiry Date |
The expiry date of the community licence |
Yes |
Withdrawal Date |
The withdrawal date of the community licence |
Yes, if found |
Suspension Date |
The suspension date of the community licence |
Yes, if found |
Suspension Expiry Date |
The date on which the community licence suspension expires |
Yes, if found |
Certified True Copy Details |
Yes |
|
Certified True Copy Number |
The serial number of each certified true copy of the community licence of the transport undertaking as recorded in the register (free text alphanumeric field with length 1 to 20) |
Yes |
Start Date |
The start date of each certified true copy of the community licence. |
Yes |
Expiry Date |
The expiry date of each certified true copy of the community licence. |
Yes |
Withdrawal Date |
The withdrawal date of each certified true copy of the community licence. |
Yes, if found |
Suspension Date |
The suspension date of the certified true copy of the community licence. |
Yes, if found |
Suspension Expiry Date |
The date on which each certified true copy of the community licence suspension expires. |
Yes, if found |
Vehicle Details |
Yes, if value of ‘Request All Vehicles’ in CTUD Request is ‘Yes’. |
|
Vehicle Registration Number |
The registration number of each of the vehicles of the transport undertaking |
Yes |
Vehicle registration country |
The registration country of each of the vehicles of the transport undertaking. |
Yes |
Notification of Unfitness
Notification of Unfitness |
Mandatory |
|
Business Case Identifier |
A serial or reference number identifying each individual notification. |
Yes |
Notifying Competent Authority |
The competent authority that issues the notification. |
Yes |
Transport Manager Details |
Yes, if no CPC details |
|
Family Name |
Transport manager’s family name(s) as indicated on the CPC. |
Yes |
First Name |
Transport manager’s complete given name as indicated on the certificate of professional competence. |
Yes |
Date of Birth |
Transport manager’s birth date in ISO 8601 format (YYYY-MM-DD). |
Yes |
Place of Birth |
Transport manager’s place of birth. |
No |
CPC Details |
Yes, if no transport manager details |
|
CPC Number |
Number of certificate of professional competence |
Yes |
CPC Issue Date |
Date of issuance of the CPC, in ISO 8601 format (YYYY-MM-DD). |
Yes |
CPC Issue Country |
Issuing country of the CPC in ISO 3166-1 alpha 2 format. |
Yes |
Declaration of Unfitness |
Yes |
|
Start Date of Unfitness |
Start date of unfitness, in ISO 8601 format (YYYY-MM-DD). |
Yes |
Notification of Unfitness Acknowledgement |
Mandatory |
|
Business Case Identifier |
A serial or reference number matching the business case identifier of the notification. |
Yes |
Originating Competent Authority |
The competent authority issuing the notification. |
Yes |
Responding Competent Authority |
The competent authority providing the acknowledgement. |
Yes |
Status Code |
Status code of the acknowledgement. |
Yes |
Status Message |
Status Message String |
No |
ANNEX IV
TRANSLITERATION AND NYSIIS SERVICES
1. |
The NYSIIS algorithm implemented in the central hub shall be used to encode the names of all the transport managers in the national register. |
2. |
Member States should always use the NYSIIS key as the primary search mechanism when searching the register for a transport manager via the CGR functionality. |
3. |
Additionally, Member States may employ a custom algorithm to return additional results. |
4. |
The search results will indicate via which search mechanism a record was found, either NYSIIS, or CPC or custom. |
ANNEX V
SECURITY REQUIREMENTS
1. |
HTTPS must always be used for the exchange of messages between the central hub and the national systems. |
2. |
National systems will use the PKI certificates provided by the Commission for the purposes of securing the transmission of messages between the national system and the hub. |
3. |
National systems shall implement, as a minimum, certificates using the SHA-2 (SHA-256) signature hash algorithm and a 2 048 bit public key length. |
ANNEX VI
SERVICE LEVELS
1. |
National systems shall fulfil the following minimum level of service:
1.1.
They shall be available 24 hours a day, 7 days a week.
1.2.
Their availability shall be monitored by a heartbeat message issued from the central hub.
1.3.
Their availability rate shall be 98 %, according to the following table (the figures have been rounded to the nearest convenient unit):
Member States are encouraged to respect the daily availability rate, however it is recognised that certain necessary activities, such as system maintenance, will require a down time of more than 30 minutes. However, the monthly and yearly availability rates remain mandatory.
1.4.
They shall respond to a minimum of 98 % of the requests forwarded to them in 1 calendar month.
1.5.
When sending Check Good Repute responses, Notification of Check Result acknowledgements, Check Transport Undertaking Data responses and Declaration of Unfitness acknowledgements in accordance with Annex VIII:
1.5.1.
They shall respond to requests within 10 seconds.
1.5.2.
The global request timeout (time within which the requestor may wait for a response) shall not exceed 20 seconds.
1.5.3.
They shall be able to service a request rate of 6 messages per second.
1.6.
National systems will not send requests to the ERRU hub at a rate exceeding 2 requests per second.
1.7.
Every national system shall be able to cope with potential technical problems of the central hub or national systems in other Member States. These include, but are not limited to:
(a)
Loss of connection to the central hub
(b)
No response to a request
(c)
Receipt of responses after message timeout
(d)
Receipt of unsolicited messages
(e)
Receipt of invalid messages |
2. |
The central hub shall:
2.1.
Feature an availability rate of 98 %.
2.2.
Provide to national systems notification of any errors, either via the response message or via a dedicated error message. The national systems, in turn, shall receive these dedicated error messages and have an escalation workflow in place to take any appropriate action to rectify the notified error. ►M1 The escalation procedure should be detailed to the Commission upon request. ◄ |
3. |
Maintenance Member States shall notify other Member States and the Commission of any routine maintenance activities via the web application, at least 1 week before the beginning of those activities if technically possible. |
ANNEX VII
LOGGING AND STATISTICS
1. |
This annex provides details of logging and statistical data collected at the central hub, not at the Member States. |
2. |
In order to ensure privacy, the data for statistical and routing purposes shall be anonymous. Data identifying a specific transport manager, transport undertaking, community licence or CPC will not be available for statistical purposes. |
3. |
Logging information shall keep track of all transactions for monitoring and debugging purposes, and allow the generation of statistics about these transactions. |
4. |
Personal data shall not be retained in the logs for more than 6 months after a transaction is complete. Statistical and routing information will be retained indefinitely. |
5. |
The statistical data used for reporting may include, among others:
(a)
The requesting Member State.
(b)
The responding Member State.
(c)
The type of message.
(d)
The status code of the response.
(e)
The date and time of the messages.
(f)
The response time. |
ANNEX VIII
USE OF ERRU
1. CHECKING THE GOOD REPUTE OF TRANSPORT MANAGERS
When verifying through ERRU, in accordance with Article 11(4) of Regulation (EC) No 1071/2009, whether a transport manager has been declared in one of the Member States as unfit to manage the transport activities of an undertaking, Member States shall perform a broadcast CGR search by sending a Check Good Repute Request. The responding Member States shall reply to the request by sending a Check Good Repute Response.
2. NOTIFICATION OF CHECK RESULTS
2.1. For the notification of a serious infringement through ERRU, the Member State of infringement shall send a Notification of Check Result to the Member State of establishment with the information about the infringement. Infringements not categorised in Directive 2006/22/EC or in Regulation (EC) No 1071/2009 shall not be notified.
2.2. When no infringement has been detected during the check, a Notification of Check Result shall be sent to the Member State of establishment consisting of the information about the clean check as set out in Annex III.
2.3. A check shall not be considered as a clean check when minor infringements have been detected. Where only minor infringements have been detected during the check, a Notification of Check Result shall be sent to the Member State of establishment consisting of information about the date and number of minor infringements detected.
2.4. The Notification of Check Result shall be sent as soon as possible, and at the latest within 6 weeks of the final decision on the infringements detected, if any, providing the information set out in Annex III.
2.5. The Member State of establishment shall reply to the Notification of Check Result by sending a Notification of Check Result Response, as soon as possible and at the latest within 6 weeks of the final decision on the matter, informing of which, if any, of the penalties requested by the Member State of infringement have been imposed. If such penalties are not imposed, the Notification of Check Result Response shall include the reasons therefor. The Notification of Check Result Response shall not be necessary when the Notification of Check Result refers to a clean check.
2.6. In all cases, a Notification of Check Result and a Notification of Check Result Response shall be acknowledged by means of a Notification of Check Result Acknowledgement.
3. CHECKING THE TRANSPORT UNDERTAKING DATA
3.1. When checking through ERRU any of the transport undertaking data referred to in point 1.3 of Annex II, a Member State shall send a Check Transport Undertaking Data Request to the Member State of establishment.
3.2. The Member State of establishment shall reply by sending a Check Transport Undertaking Data Response.
3.3. Queries sent through the CTUD functionality shall be carried out by entering either the name of the transport undertaking, its Community licence number or the number of any of the certified true copies, or the registration number of any of its vehicles, without being necessary to perform a query by typing more than two of the aforementioned entries.
3.4. Responding Member States, when searching in their registers the result of a CTUD request on the basis of either the Community licence or the registration number of a vehicle, shall take measures to adapt the format of the data in the search request to the format of the data in the national register. In particular, Responding Member States, when searching in their registers the result of a CTUD request on the basis of either the Community licence or the registration number of a vehicle, shall ignore special characters such as hyphens or slashes. Blanks shall also be ignored.
3.5. Responding Member States shall return to the requesting Member States all the information that is available through the XML messages defined in Annex III. If a part of the information requested has not been found, this shall not preclude responding Member States to provide the rest of the information requested that is available in the register, including the registration number of vehicles with no associated certified true copy.
4. NOTIFYING THE UNFITNESS OF A TRANSPORT MANAGER
4.1. When a transport manager has been declared to be unfit in one Member State, that Member State may send a Notification of Unfitness to all other Member States.
4.2. In all cases, a Notification of Unfitness shall be acknowledged by means of a Notification of Unfitness Acknowledgement.