In order to get a Type ID in ERATV you need to:
1. Submit to the authorising entity (NSA or Agency) a request for the creation of a draft type in ERATV before applying for the authorisation. When the Agency is the authorising entity concerned, please use this template (TEM_VEA_092) and send it by email to email@example.com with subject:
2. You will be informed by email when you have access to the draft type as an auxiliary user. At this moment, you can provide the technical details (steps 2 and 3) directly in ERATV. The draft type contains the TYPE ID to use in the authorisation application. More information about ERATV can be found here.
3. When your draft type is ready in ERATV print it into a PDF file (or export it to Excel), fill-in this template (TEM_VEA_060) and upload both files into the documentation of your application in the OSS (folder “Information required for ERATV (18.13) of the library).
4. In case of requests for publication of versions following changes categorised pursuant to Article 15(1)(c) of Regulation (EU) 2018/545, please inform the Agency about the completion of the draft entry for steps 2 and 3; the Agency will fill in step 4 and publish the entry in ERATV.
Please contact the NSA directly to get the details of the national procedure to request for the creation of an entry in ERATV when:
In order to request a modification of a record in ERATV in case of changes to an already authorised vehicle type that are classified by the entity managing the change pursuant to Article 15(1)(b) of Regulation (EU) 2018/545, the holder of the vehicle type authorisation needs to submit a request for modification. When the Agency is the authorising entity, please use this template (TEM_VEA_095) and follow the instructions within.
Please note that:
When submitting an application for a vehicle type authorisation through the OSS, applicants have the legal obligation to indicate the identified conditions for use of the vehicle and other restrictions (point 14 of Annex I of Regulation (EU) 2018/545), in terms of coded and non-coded restrictions. However, the current version of OSS does not provide a structured way (e.g., webform) to include them.
Until the OSS allows this, applicants can fill-in this template (TEM_VEA_062) and upload it to the library of the concerned OSS application (folder “Other documents”).
When submitting an application through the OSS, the applicant must provide the concerned EC certificates and EC declarations through the OSS, taking into account the scope of the application (e.g. in case of new authorisation, only the EC certificates and EC declarations of Interoperability Constituents impacted by the change need to be submitted). Before submitting the application, the applicant must ensure that all the EC certificates and EC declarations are uploaded in ERADIS.
During the assessment of an application for authorisation, the authorising entity shall perform several checks on the EC certificates and EC declarations, such as consistency between the application and ERADIS/ERATV, consistency between the EC certificates mentioned in the EC declarations and the actual EC certificates submitted in the application etc.
In order to reduce streamline the assessment process, applicants are kindly requested to fill-in this template (TEM_VEA_061) and include it in the application for authorisation before submitting it.
Upon request and under the sole responsibility of the holder of the vehicle type authorisation, the Agency can publish new versions in ERATV compiling existing versions of a vehicle type or of a variant of a vehicle type, when these versions were published by the Agency.
This is necessary for applying for the authorisation of vehicles in conformity to an already authorized type when the target area of use (in case of versions authorized following an extension of the area of use) or the design (in case of versions published in ERATV following changes classified pursuant to Article 15(1)(c) of Regulation (EU) 2018/545 or addition of ESCs), while covered by several ERATV entries, is not matching any entry in ERATV for the existing versions.
The result of the compilation will be a new entry in ERATV. The type ID will be assigned as if it was a new version of the parent type/variant. This new version will compile the values for the different parameters (including coded and non-coded restrictions) of the existing entries in ERATV corresponding to the versions that will be compiled. In the comments section, it will describe both the parent type/variant and the different versions compiled (including their type IDs).
The compilation of versions is not an authorisation, but a service output that consolidates into a new ERATV record the information from existing records in ERATV.
Further details can be found in the clarification note ERA1209/132, available at the website of the Agency.
In order to request the creation of a compiled version, the holder of the vehicle type authorisations of all versions to be compiled needs to submit to the Agency a request for the creation of a draft type in ERATV using this template (TEM_VEA_092) and send it by email to firstname.lastname@example.org with subject “Request for the compilation of existing versions”.
When the draft type for the compiled version is ready in ERATV and you have been granted access to it as an auxiliary user, you will be informed by email. You can then provide the technical details (steps 2 and 3) for the compiled version directly in ERATV, and inform the Agency, that will review the data, fill-in step 4 and publish the entry for the compiled version in ERATV.
More information about ERATV can be found here.
Please note that:
Templates and checklists can be used to support the work of the actors during the assessment. These templates and checklists are documents to fill in with usual office suite tools and to upload in the OSS as attachments to the various reports (mainly completeness check, detailed assessment, conclusion, decision and authorisation). The templates and checklists are made available to the users through the templates folder in the library.
Applicant are free to organize their documentation according to their needs. The folder structure proposed for the documentation is a guidance. However respecting it renders the elaboration of the mapping tables easier and it is therefore encouraged. If the structure is not followed it is highly probable that it will take more time to create the mapping table. In some cases the applicant may want to provide sub-folders; in such case a zip file (of the sub-folders) should be uploaded in the documentation and the reference(s) in the mapping table(s) shall contain the location and the filename in the zip file.
Various documents are required for the authorisation. Such documents shall be provided in the documentation supporting the application. In case of positive decision related to the application the issuing authority has the obligation to check that the concerned documents are present in ERADIS. In case they are not, the decision will be positive but the authorisation will not be delivered to the applicant (pending the documents are uploaded).
The list of documents to upload in ERADIS are listed in the ERADIS homepage.
It is not necessary to use the issues log for all the questions occurring during the assessment of an application.
The purpose of the issues log is:
In practice all communications do not have to go through the issues log and other communication channels can still be used (e.g. phone or email). However, a user is expected to create an issue in the issues log in the following cases:
Note that nothing prevents the user to create an issue later on if this appears to be relevant.
Another aspect relates to the formulation of the issue. An issue may contain several questions but in that case, all questions need to be of the same type, have the same due date, etc. and the issue can only be closed when all questions are answered. It is left at the discretion of the user (and ultimately the project manager) to organise this in the most appropriate manner depending on the needs of the project.
Issues shall be created by users as soon as they evaluate that one of the purpose is met.