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:

• Only the holder of the vehicle type authorisation can request modifications in the concerned ERATV record.
• The Agency cannot modify ERATV records created by NSAs following type authorisations issued by NSAs. The Agency can only modify ERATV records related to vehicle type authorisations issued by the Agency.
• The modifications in an ERATV record for this category of changes should be limited to the references to the EC certificates (parameters 2.2 and/or 3.1.3.1.4 / 3.1.3.X.5). As a consequence:
  • Modifications in the values for the technical parameters in section 4 of the concerned ERATV record are not allowed.
  • Modifications in the conditions for use of the vehicle and other restrictions as a result of a 15(1)(b) change should be analysed pursuant to Article 15(1) of Regulation (EU) 2018/545, independently of the change itself.
  • Modification of the reference to the written declaration covering the requirements capture process (parameter 3.1.3.1.7 / 3.1.3.X.8) is only allowed in case of editorial changes in the declaration. If the declaration is changed due to a new assessment report issued by the AsBo, it is not allowed to update the ERATV record.

See also:

• How to provide the information about the type for ERATV? Where can I get the TYPE ID?
• What should someone do if they have an existing vehicle which is not registered in ERATV but is authorised and for which new modifications are being proposed?
• What happens if there is no current Type Authorisation and you want to extend the area of use?
• Explanations of Art. 50 (registration in ERATV) [of the Implementing Regulation (EU) 2018/545] in the Guidelines

If you don't find the answer to your question, please contact us directly:

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

See also:

• Explanations of Articles 20 [of the Implementing Regulation (EU) 2018/545] in the Guidelines, section 3.3.6
• Technical document ERA/TD/2011-09/INT List of harmonised and national restriction codes
• ERATV application guide

If you don't find the answer to your question, please contact us directly:

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.

See also:

• Which documents shall be stored in ERADIS
• Explanations of Art. 50 [of the Implementing Regulation (EU) 2018/545] inthe Guidelines
• Clarification note ERA1209/001 about content of the application file concerning points 18.5 and 18.5 of Annex I of Regulation (EU) 2018/545
• Clarification note ERA1209/003 about responsibilities for populating ERADIS
• Clarification note ERA1209/006 about transitionary measures for uploading EC certificates and ISV information to ERADIS

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/RSCs), 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 servicedesk@era.europa.eu 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:

• The request shall be submitted by the holder of the vehicle type authorisation of the different versions to be compiled
• The Agency can only perform the compilation for versions created and submitted for publication by the Agency
• Compilation of versions with transitions between neighbouring MSs which were not covered by the existing authorisations is not possible; the cross-border operations in terms of transitions between neighbouring MSs shall be limited to those already covered by the existing authorisations;

See also:

• How to provide the information about the type for ERATV? Where can I get the TYPE ID? How can I request the publication of a version following a 15(1)(c) change? 
  
   

If you don't find the answer to your question, please contact us directly:

1. The authorisation case once saved can hardly be changed. To select correctly the authorisation case please read carefully the application guide on vehicle authorisation (article 14). If you select a wrong authorisation case, you will probably need to recreate your application from scratch. Alternatively you can delete the uploaded documents from the documentation and empty the content of the mapping tables. The selection of the authorisation case triggers the creation of the folder structure for the documentation as well as the definition of the authorization details to provide.




2. The documentation to provide depends on the real case. The implementing regulation (EU) 2018/545 details in annex 1 the content expected per authorisation case. The application guide details further this annex 1 (especially the technical file and the requirements capture). Depending on your real case some folder may be left empty. OSS does not constrain on providing file in each folder. It is the responsibility of the applicant to provide the appropriate documentation.




3. OSS allows you to define the language of the user interface in your profile. The language in which you want the authorising entity to deliver the authorisation is a separate field in each application form. The two may be differentiated depending on your need. The language to use during the processing of the application is described in the implementing act and in the application guide (article 10).




4. The type / variant(s) / vehicle(s) in the authorisation details shall be carefully created: once the application is submitted it is not possible to add type / variant(s) / vehicle(s).




5. The definition of the area of use consists in selecting the Member State(s) where the vehicle will be authorized and the network(s) in these Member State(s). There is also the possibility to select the border stations in the neighbouring Member State(s). The allowed values for the networks and the border stations are defined by each Member State. Each concerned NSA shall provide the exact possible values. Please refer to the NSA website or contact the NSA to get the list of possible values for each information. The value “Whole EU” should be selected only for vehicles where no national technical rule are applicable.




6. The selection of the authorising entity is essential for the processing of your application. If the area of use of your vehicle authorisation concerns more than one Member state, the authorising entity shall be the Agency; if the area of use is limited to one Member State you can choose between the NSA and the Agency. The OSS does not allow the choice of the NSA as authorizing entity in one application when the area of use covers more than one Member State. In case of wrong selection of the authorising entity, the application will be rejected and a new application will be required.




7. The mapping tables provide guidance to the assessors about where the aspects to assess are documented. The references shall be detailed and precise enough to allow the assessor to be efficient in its assessment. Vague or insufficient mapping tables will trigger issues and may be a cause for incompleteness.

If you don't find the answer to your question, please contact us directly:

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.

If you don't find the answer to your question, please contact us directly:

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.

See also:

• “Guidance for annex I” (Content of the application) [of the Implementing Regulation (EU) 2018/545] in the Guidelines
• ERA1209-001 Clarification about points 18.4 and 18.5 of Annex I of Regulation 2018-545 detailing the (18.4) declaration of conformity to type and the associated documentation and (18.5) technical file accompanying the EC Declaration of Verification

If you don't find the answer to your question, please contact us directly:

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.

See also:

• ERA1209-003 Clarification about responsibilities for populating ERADIS
• Information about ERADIS in the Registers
• Explanations of Art. 50 (registration in ERADIS) [of the Implementing Regulation (EU) 2018/545] in the Guidelines

If you don't find the answer to your question, please contact us directly:

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:

• to facilitate the tracking of the resolution of issues (ensuring that all issues are resolved before delivering the decision),
• to alert the various actors on a specific problem that may affect their work,
• to keep the traceability of the resolution of an issue (how it was resolved?), and
• to facilitate the creation of the completeness check and the assessment report by attaching in these reports the main issues discovered.

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:

• the issue needs tracking,
• evidence is to be added to the application file, or
• there is an impact other parties (e.g. the applicant, another authority) or on the application file.

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.

See also:

• Explanations of Art. 41 (categorisation of issues) and 42 (justified doubt) of the Implementing Regulation (EU) 2018/545 in the Guidelines

If you don't find the answer to your question, please contact us directly: