|
Question |
Answer |
|---|---|
|
Versioning |
|
|
Will there be a full version management (and a compare function)? |
Yes, version management is available and comparison of applications/projects can be done via export. See Export - Comparison of AF versions through PDF |
|
Will a history of the reprogramming of a project be present in the system with the possibility for the programme to comment on each reprogramming? |
For project modifications, there is a versioning of the application form. The versioning of application form will be applied from creation of an application form onwards. The system will store and allow to compare versions of the application form. Comments can be added to the modification in the text field for “Explanatory notes” and/or via upload of documents, see Modification of the Application form. |
|
Partners |
|
|
Can Jems handle sub partners? |
(Financing) sub partners are not foreseen by HIT. Only associated partners can be added to a partner. |
|
Project Numbering |
|
|
How does the project numbering work?
|
A numbering logic for projects has been implemented. Elements included are programme ID, call ID and a 5-digit running number. Both programme and call ID are optional; the running number is always part of a project ID. For details pls refer to Basic data |
|
Unique partner ID |
|
|
Will a unique identification number be mandatory on the platform when creating the partner on the application form (such as SIRET in France or Taxpayer Identification Number for the EU) or will it be automatically generated by the system? (https://ec.europa.eu/taxation_customs/business/tax-cooperation-control/administrative-cooperation/tax-identification-numbers-tin_en ) In addition, how to make a difference between two departments of the same institution in the system? (the JS needs to check overlapping or multi participation of partners in project proposals) |
There are different mechanisms planned to identify partners. One way is to use the field “VAT” of the HIT application form template. Further fields such as “PIC” (for the EC partner database) and “Other identifier” can also be switched on in the application form configurator. |
|
Budget |
|
|
Could different project partners choose different options for the lump sum, real cost etc? |
Yes, the budget options activated in a call are always available on a partner level and partners can choose them independently from each other |
|
Are the details per staff member compulsory (cause for instance linked to reporting modalities per staff member) or can PP put a global amount? |
This is up to the programme to decide. As a programme you should advise your applicants in your manual, in what detail they should fill in the budget tables |
|
Lump sum payments for small-scale projects based on draft budgets (implementation of milestones in the control module?) |
Draft budget: Jems provides project proposed unit costs for this purpose. Applications are submitted with real cost, and during the assessment, returned to the applicant with the request to replace real cost by partner proposed SCO. (Real costs remain stored in historic version 1 of the application.)
|
|
Co-financing |
|
|
In the co-financing section, will there be a section for other financing and thus for possible revenues? |
No, because indication and monitoring of revenues has been removed from the regulations for the new period. |
|
Partner co-financing – source column: Can it be automatically pre-filled when there is only one source/fund defined at programme level? This would save time and effort for the applicants. |
Such feature is not implemented. |
|
Partner co-financing – percentage column: Could you add an info tooltip (such as for the % of total partner budget from origin of partner co-financing) informing the user that only integer values can be inserted in this column? |
The development policy is rather to guide the user by not allowing the entry of unsuitable values. |
|
Partner co-financing – Origin of partner contribution – Source of contribution: Are the allowed sources of partner contribution established at programme level? Can we have a drop-down list with predefined sources of partner contribution at programme level (maybe also selectable in the call)? |
This feature did not get sufficient priority from the core group to be implemented. |
|
Shall partner specify co-financing of lump sum? |
The co-financing of the lump sum is the same as for any other costs related to this partner. So the partner has to add the co-financing on the total partner budget amount and not on singly cost categories or lump sums. |
|
Input fields, HIT |
|
|
The questions in the application form (project description section) come from the HIT templates. However, will it be possible to add additional questions in a particular call? For example, in 2-step calls, the questions are not the same. |
Jems provides the form according to HIT. A certain flexibility is also given via the translation files. Instead of switching off an optional field, its title can be renamed.
|
|
In section C4 / workpackage / investment tab, at our level, we have no heavy investment, only SSI (small-scale investment). Will we have to manage it in the same way? |
This section is implemented according to HIT. The investment section is optional, all fields can be switched on and off individually according to the requirements of the programme. |
|
Will it be possible to define a type and detailed target values for the deliverables? |
This is not foreseen since it would deviate from the HIT template. |
|
In the delivery period drop-down menu of the deliverable, only one period can be selected. Some deliverables can be delivered over several periods (e.g. Steering and Technical Committee meetings), does this imply that deliverables will have to be duplicated as many times as there are periods? |
Repeated deliverables have to be entered as many times as required. If one and the same deliverable stretches over several periods, the period of finishing the deliverable can be indicated. |
|
In the index of the form, on the left part, the WPs are well displayed as they are created but only with their WP1, WP2,... code. Is it planned to display a part of the WP title in this place so that it is perhaps more explicit? |
We decided not to put the work package title in the side menu for two reasons: Firstly, this title is optional in HIT, thus not all programmes will use it, and secondly, the field has a limit of 200 characters which is too long for a menu entry. |
|
Periods in budget + A.1 Project Identification – project duration (no. of months): Can you add a warning message when project duration is decreased and periods having already amounts allocated in the budget disappear? + highlight (e.g. in different color) of AF sections and sub-sections affected. |
There is no immediate warning, however, (default) pre-submission checks do not succeed if there are missing periods (i.e. due to shortening of project duration). Currently, the system resets such period values to empty, so that the system is not corrupted and the data can still be saved. |
|
Some text input fields seem a bit short, for example the description of the general objective of the project (500 characters). |
In principle, we intend to define limits generously. In individual cases, programmes request longer fields. Depending on the demand, we can either extend certain fields or consider enabling programmes to set character limits. |
|
Can the application form fields be numbered e.g. 1 project ID, 2 project acronym, 3 project title...? |
Theoretically, it is possible to add a number in front of every field header via the translation file. However, we did not see this as a requirement, as the sections in HIT are numbered, but not every separate question. |
|
Subsidy Contract/ Partnership Agreement |
|
|
Can the contractual documents (Subsidy Contract - Subsidy Contract Amendment - Partnership Agreement) be edited and generated by the system, with the possibility of automatic data transfer from the form (e.g. partnership, subsidy amounts)? |
Using the project export feature, contracts can be generated via addon Application form export add-on which can be developed by programmes according individual needs. |
|
Pre-submission checks |
|
|
Will it be possible to establish a consistency check prior to the submission of the application form? For MED, for example, this check refers to the eligibility criteria: minimum number of countries represented, concentration of the budget on one partner, concentration of the budget on one country, the lead partner is a public body (on Synergie CTE, if these criteria are not respected, it is not possible to submit the application form). |
The system includes minimum pre-submission checks which are applicable for all Interreg programmes (e.g. that fields are filled-in, that amounts in different sections are consistent, etc., see Pre-submission checks | Add on approach and predefined pre submission checks). Your programme will be able to define additional pre-submission checks based on specific consistency requirements (via plugins, see Pre-submission check add-on). If the checks do not lead to a positive result, it is not possible to submit the application form. |
|
Is it possible to have an indication when you have completed one of the sections of an application form? Green colour? Checking off? The goal is to indicate if there are still errors/inconsistencies in a section of the application form. Further, it can be indicated, if all required fields have a text input. However, the system cannot identify if a section is completed from a content perspective (if the text is sufficiently complete, if all PPs are created, if all budget lines are planned etc.). |
Pre-submission checks indicate e.g. if every field of a section is filled in. Further, the pre-submission checks will show which sections need further input or where there are inconsistencies. However, as you correctly say, these automatic checks cannot ensure the quality of the inserted text or if all PPs are created etc. |
|
Why is there no pre-submission checklist on 1st step? |
It was discussed in the Core Group and decided that this is a must have for step 2, however, for step 1 this was not considered as a must have. For step 1, there is a dummy presubmission check addon which always succeeds (checks for Acronym only). It can be extended according to the individual needs, see Pre-submission check add-on. |