GMT PRESENTATION FOR FUTURE DEVELOPERS
Transcript of GMT PRESENTATION FOR FUTURE DEVELOPERS
GMT PRESENTATION
FOR FUTURE DEVELOPERS
By Aurélia MELLIN (Cleansky)
SUMMARY
• INTRODUCTION: WHAT IS GMT?
• CONTEXT OF CLEAN SKY
• WHY GMT?
• OVERVIEW OF THE ANNUAL PROCEDURE
• EXISTING FUNCTIONS IN GMT
• GMT DATABASE ARCHITECTURE
2
INTRODUCTION: WHAT IS GMT?
• The Grants Management Tool is a database serving as an interface between Clean Sky and the beneficiaries of the EU funding (Members of the research programme from the aeronautical industry) for the management of diverse financial documents relative to the Grant Agreements for Members (GAMs), especially the submission and the treatment of forms C.
3
INTRODUCTION: WHAT IS GMT?
• GMT is currently hosted on a server under the responsibility of Clean Sky. In the future, it should be migrated on an external server administrated by the future contractor.
4
CONTEXT OF CLEAN SKY
• The Seventh Framework Programme (FP7)
• What does the overall Clean Sky project consists of?
• Budget of the Clean Sky project
• The Integrated Technology Demonstrators (ITDs)
5
CONTEXT OF CLEAN SKY: the FP7
• In order to rebuild Europe’s competitiveness, especially in regard to the knowledge-based economy (goals of the European Union’s Lisbon strategy), the 7th Framework Programme (FP7) has been launched in 2007.
• It supports many specific programs, including the Clean Sky Joint Technology Initiative (JTI), managed by the Clean Sky Joint Undertaking (CSJU).
6
CONTEXT OF CLEAN SKY: the Clean Sky Project
• The Clean Sky JTI programme consists of a very unique and ambitious research work at the European level for which the European Commission (EC), as well as specifically chosen members of the aeronautical industry, combine their efforts to design technological breakthrough developments with a reduced time to market for a greener air transport.
7
CONTEXT OF CLEAN SKY: Budget
• The total budget of the entire programme over the period 2008-2013 is 1.6 billion €, for which the aeronautical industry participates for 50% (800 millions in kind) and the European Commission contributes for the other half (800 millions in cash). The potential next part of the programme will be under the horizon 2020 (Clean Sky 2).
8
CONTEXT OF CLEAN SKY: the ITDs
• The project is actually divided in 7 Integrated Technology Demonstrators: 1) Smart Fixed Wing Aircraft: concerns planes such as Airbus A320
(SFWA)
2) Green Regional Aircraft: concerns regional, smaller planes (GRA)
3) Green Rotorcraft: concerns helicopters (GRC)
4) Sustainable And Green Engines: concerns engines for the different aircrafts (SAGE)
5) System for Green Operations: concerns on-board systems for the different aircrafts (SGO)
6) Eco-Design: concerns sustainable equipments (ED)
7) Technology Evaluator: simulation network to assess other ITDs’ performance (TE)
(Each ITD is administrated by an ITD Coordinator from the industry.)
9
WHY GMT?
• As you will see in this presentation, the administrative workload to manage this process is rather heavy. In this context and according to the EU needs in terms of transparency, traceability of the closing activities, and of course dependability, GMT has been designed.
• GMT offers these qualities and also dramatically reduces the administrative burden linked to the project for all actors concerned. 10
Annual Process supported by GMT
• The Annual Implementation Plan (AIP): • Document supporting the annual budget setting per ITD/beneficiary
> Lightly supported today by GMT
• The Grant Agreement for Members (GAM): • Contract setting detailed activities and detailed budget
> Partially supported today by GMT
• Execution Follow Up: • various report to the CSJU during contract execution > Partially supported today by GMT
• Closing: Annual Reports & associated Form Cs • Annual reports submitted with Form Cs (equivalent to invoices)
> Fully supported by GMT 11
• As the budget is not spent in a linear fashion over the years, the Executive Director of the CSJU consults the European Commission through the Annual Implementation Plan (AIP) to have authorization for a specific annual budget:
February of year n-1: Drafting of the AIP with maximization of the budget of year n;
June of year n-1: EC answer, according to which the final version of the AIP, with budget adjustment, is prepared for November of year n-1.
Once the AIP is concluded at a global level between the JU and the EC, the technical annexes 1A/1B of the GAM amendments are used to specifically describe the activities associated to the requested budget, with the adequate level of details.
12
Annual Process supported by GMT: the AIP
• The GAM is made up of different parts: The main contract, mentioning the maximum JU annual contribution to the ITD and the list of
beneficiaries (the GAM, signed at program launch, is amended every year to set the detailed work plan, the annual budget & the annual Maximum JU Contribution per beneficiary);
Administrative annexes: Annex II: General conditions;
Annex III: Form A (accession of beneficiaries to the grant agreement);
Annex IV: Form B (request for accession of a new beneficiary to the grant agreement).
Technical annexes: The Annex IA, which is a strategic vision of the program over the remaining years;
The Annex IB, which is a much more detailed technical description with:
Several Work Packages Description: the Work Packages contain deliverables and milestones:
- Delivrables: concrete result of the work done. If this result is not satisfactory, the Project Officer assigned to the concerned ITD, puts on hold either part or the entire amount claimed by this beneficiary in the form C.
- Milestones: ponctual meetings assessing results and progress.
Beneficiary Work Plan (BWP) per beneficiary: financial and calendar planning for beneficiary’s activities (cross WPs);
Beneficiaries Annual Budget per ITD which sets the maximum JU contribution per beneficiary and at ITD level.
Annex V: Form C template to be used to state the costs incurred by a beneficiary (financial statement equivalent to an invoice). It is submitted in GMT and after validation by the CSJU, 50% of the validated costs are refunded;
Annex VI: Form D (terms of reference for the certificate of financial statements (CFS): see dedicated slide);
Annex VII: Form E (terms of reference for the certificate on the methodology: not addressed by GMT).
13
Annual Process supported by GMT: the GAM amendment
• The execution follow up include:
The Quarterly Reports, which take place at the end of March (Q1), May (Q2 + Mid-Year Assessment (MYA)), September (Q3) and December (Q4). They aim to examine for each ITD and each subproject the actual Man Month or K€ consumed, the actual date of deliveries of deliverables, the milestones conducted and/or achieved, and compare these results to what was planned in Annex IA and IB. The quaterly report also focuses on the residual risks status for a subproject. GMT does not support the setting of these documents, which are simply uploaded in GMT.
The Request for Change: the ITD Coordinator submits a Request for Change to the CSJU through GMT when the technical activities or the budget planned per beneficiary in GAM Amendments have to be modified. The CSJU can validate or reject them in the tool.
The ITD Coordination meetings, held 3 to 4 times a year, monitor progress and issues (not supported by GMT).
The Annual review enables an assessment of the progress of the ITD by external reviewers (not supported by GMT).
14
Annual Process supported by GMT: the Execution Follow Up
Overview of the Annual Procedure: Closing: Annual Reports & Form Cs
Annual reports are uploaded by the ITD Coordinator in GMT: they explain what is achieved compared to the Annex 1B baseline (simply uploaded in GMT).
Beneficiaries also submit Form Cs in GMT (and on paper version today) to state their incurred costs and claim the subsidies (50% of the costs).
15
Overview of the Annual Procedure: Closing: the Form C
The initial form C
should be submitted every year (before March 1 of the year n+1).
It has to be accepted by the ITD Coordinator and by the JU (Financial Officer and Project Officer) in order to be payable.
The JU part of the acceptation is called “Financial closing” and “Technical closing”.
Only one initial form C is submitted by year.
16
Overview of the Annual Procedure: Closing: the Form C
In order for the form C to be payable to the beneficiary, the Financial Officer has to accept the 3 following fields in the “FO Validation Form” part of the form C in GMT:
- “Form C validated by FO”;
- “Validation use of resources”;
- “Original form C received”.
Similarly, the Project Officer has to accept the 2 following fields in the part “PO Validation Form”:
- “Progress of work validated by PO”;
- “Validate use of resources”.
17
Overview of the annual procedure: Closing: the FORM C
Forms C adjustments (as many as necessary) can be submitted the same year as the initial form C or any of the following years.
They are created in case of: - Availability of various accounting elements leading to a correction of the
initial form C:
- Closing of the accounts making available actual indirect ratios and personnel costs;
- Error detected by the beneficiary (beneficiary initiative in GMT);
- CFS: ex ante audit that should be submitted by the beneficiary when the sum of all the cost claims refund to it over the previous years exceeds 200,000 €;
- Ex post audit (ponctual or systematic).
18
Overview of the Annual Procedure: Closing: the Form C
In order for the form C adjustment to be payable to the beneficiary, only the FO’s acceptation part counts (“Form C validated by FO” and “Original Form C received”).
19
Overview of the annual procedure: Closing: the FORM C Workflow
• For clarity purposes, here is included an overview of the form C workflow (which can also be found in the GMT Training Session annexed):
20
See following step
Overview of the annual procedure: Closing: the FORM C Workflow
21
Following step
Overview of the annual procedure: Closing: the FORM C Workflow
22
Overview of the annual procedure: Closing: the FORM C Workflow
23
EXISTING FUNCTIONS IN GMT
The GMT Training Session annexed had been
previously prepared for the external users and
it complements the following slides, which are
exclusively about the GMT functions
concerning the CSJU interface.
The present document refers to the functions
already explained in the training by “*”.
24
EXISTING FUNCTIONS IN GMT
• Dashboard*
• Administrator’s Section
• Manage Grant
• Financial Closing
• Technical Closing
• Monitor Process
*(see the GMT Training Session in the annex)
25
EXISTING FUNCTIONS IN GMT: Dashboard
• After logging in, the dashboard is the welcome screen. It does not contain really important functions. For more information, please refer to the GMT training session in the annex.
26
EXISTING FUNCTIONS IN GMT: Dashboard
27
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• Administrator’s section:
- Manage users
- Manage Companies
- Manage Beneficiaries
- Manage ITDs
- Manage ITD Coordinators
- Manage Page Access
- Manage Role Access
- Manage Grant
28
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• The Administrator functions are indeed restricted to administrators profiles.
• Several user profiles exist in GMT and the details of each role’s rights can be found (and modified) in the subsection “Manage Role Access”. It is also where a new role can be created.
29
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• Here are these roles: For Clean Sky: Accountant (ACC), Administrator (ADM),
Coordinating Project Officer (CPO), Ex post Audit (EPA), Executive Director (EXE Director), Financial Officer (FO), Head of Administration and Finance (HAF), Internal Audit (IA), Legal Officer (LO), Project Officer (PO);
From outside of Clean Sky: Beneficiary, Beneficiary and ITD Coordinator, ITD Coordinator, Auditor (external);
Roles that are not used anymore: HAC, PC, POC.
30
EXISTING FUNCTIONS IN GMT: Administrator’s Section
31
To edit the accountant’s role: see next slide
EXISTING FUNCTIONS IN GMT: Administrator’s Section
32
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• The “Manage Page Access” function plays a very similar role. It specifies for each page which role can view, create, edit or delete this page (while the “Manage Role Access” indicated for each role which page could be viewed, created, edited or deleted). Here again, the rights can be modified with the “Edit” button:
33
EXISTING FUNCTIONS IN GMT: Administrator’s Section
34
To edit the page « AdminMenu »=> «ManageUsers »:
see the next slide
EXISTING FUNCTIONS IN GMT: Administrator’s Section
35
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• The next function “Manage ITD Coordinators” lists all the ITD Coordinators and their information (with the possibility to edit or delete their information, as well as create a new ITD Coordinator):
36
EXISTING FUNCTIONS IN GMT: Administrator’s Section
37
To edit the ITD Coordinator’s information: see the next slide
EXISTING FUNCTIONS IN GMT: Administrator’s Section
38
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• Then the “Manage ITDs” function lists all the 7 ITDs and enables to view and edit an ITD or create a new one. This function is obviously not used since this list is not likely to change. But the mode “View” (the second of the following slides) shows all the members per ITD:
39
EXISTING FUNCTIONS IN GMT: Administrator’s Section
40
EXISTING FUNCTIONS IN GMT: Administrator’s Section
41
Beginning of the list of all the beneficiaries for SFWA
(for each GAM year)
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• Going to “Manage Beneficiaries” allows to see the list of beneficiaries with their information, especially their PIC number (which can be modified with the “Edit” button).
• The mode “View” (the second of the following slides) is a way to visualize the list of forms C submitted by a particular beneficiary and to consult or edit these documents. However, the list of forms C in “Monitor Process” will be much more convenient (easier to refresh the page) and offers the advantage of being accessible from any role.
42
EXISTING FUNCTIONS IN GMT: Administrator’s Section
43
EXISTING FUNCTIONS IN GMT: Administrator’s Section
44
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• The function “Manage Companies” shows a list of all beneficiaries, with some additional information (available through the “Edit” button: see the second of the next “printscreens”), such as their address, the company size, the type of beneficiary, and especially the list of GMT users within this particular company.
45
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• It is used very often because it allows the administrators to rearrange the subrole(s) of the industry GMT users within a particular company, usually at the request of the ITD Coordinator (see second and third of the next “printscreens”). These changes are done on the basis of A2 forms (which are part of the GAM, Annex III, form A).
46
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• There are several subroles:
Subroles receiving emails from GMT: - Person in charge of financial, administrative and/or legal
aspects (Primary);
- Person in charge of scientific and technical aspects (Primary);
Subroles that do not receive emails from GMT: - Person in charge of financial, administrative and/or legal
aspects (Others);
- Person in charge of scientific and technical aspects (Others);
- Authorized representative to sign the form C;
- Authorized representative to sign the GA.
47
EXISTING FUNCTIONS IN GMT: Administrator’s Section
48
To edit the information about this company OR its GMT users: see the next
slide
EXISTING FUNCTIONS IN GMT: Administrator’s Section
49
As an example, let’s say we want to authorize M. Ibanez to sign the form C: see the next slide
EXISTING FUNCTIONS IN GMT: Administrator’s Section
50
EXISTING FUNCTIONS IN GMT: Administrator’s Section
• The function “Manage Users” shows a list of users and enables to create a new user, or to edit, lock or delete an existing one:
51
EXISTING FUNCTIONS IN GMT: Administrator’s Section
52
EXISTING FUNCTIONS IN GMT: Administrator’s Section
53
To be created by the administrators
EXISTING FUNCTIONS IN GMT: Administrator’s Section
54
To be edited by the administrators
Can be edited by the administrators but also accessible in the profile
section for any user: see the next slide
EXISTING FUNCTIONS IN GMT: Administrator’s Section
55
EXISTING FUNCTIONS IN GMT:
Manage Grant
• Manage Grant:
- Register GAM Amendment
- List GAM Amendment
- Initiate RFC*
- Follow RFC
*(see the GMT Training Session in the annex)
56
EXISTING FUNCTIONS IN GMT: Manage Grant
• “Register GAM Amendment” is a function based on the Maximum JU Contribution defined in the GAM. This amount is registered there, in order to consequently appear in the form C, between the total claimed amount and the Requested JU Contribution. For now, amounts are registered until 2013.
57
EXISTING FUNCTIONS IN GMT: Manage Grant
58
EXISTING FUNCTIONS IN GMT: Manage Grant
• “List GAM Amendments” shows the list of Maximum JU Contribution for each beneficiary:
59
EXISTING FUNCTIONS IN GMT: Manage Grant
60
EXISTING FUNCTIONS IN GMT: Manage Grant
61
EXISTING FUNCTIONS IN GMT: Manage Grant
• The function “Follow RFC” simply shows the details and status of the Request for Change. This is also the place to validate it. Here all the RFCs are already validated, so only the “View” mode is available:
62
EXISTING FUNCTIONS IN GMT: Manage Grant
63
EXISTING FUNCTIONS IN GMT: Manage Grant
64
EXISTING FUNCTIONS IN GMT: Financial Closing
• Financial Closing:
- Create Initial Form C*
- Create Form C Adjustment*
- Validate Form C*
- Validate Form C Adjustment*
- SFRs for Closing
- Payment Orders
*(see the GMT Training Session in the annex)
65
EXISTING FUNCTIONS IN GMT: Financial Closing
• The “SFR for Closing” is a function enabling to export in Excel files all the forms C for one given year and one given ITD, with all the relevant details:
66
EXISTING FUNCTIONS IN GMT: Financial Closing
67
EXISTING FUNCTIONS IN GMT: Financial Closing
68
EXISTING FUNCTIONS IN GMT: Financial Closing
69
EXISTING FUNCTIONS IN GMT: Financial Closing
• The function “Payment Order” allows to generate POPIs and greatly differs from the “SFRs for Closing”. The POPI takes all the forms C of any year that are ready to be paid for a given ITD and gathers them in an Excel file that can be exported, with totals and subtotals by type of form C and by year. So the 2 main features in the main page of “Payment Order” are:
70
EXISTING FUNCTIONS IN GMT: Financial Closing
- Listing the POPIs already generated (visible with different filters according to their status, the ITD they belong to, or the type of form C);
- Generating a new POPI, given that only one POPI can be generated at a time. It is not possible to “add” a new claim to an existing (i.e. “pending”) POPI, unless the existing one becomes “paid” (deems to have been paid), or cancelled.
71
EXISTING FUNCTIONS IN GMT: Financial Closing
72
Listing the
POPIs
Generating a new POPI
EXISTING FUNCTIONS IN GMT: Financial Closing
In the “View” mode of a POPI, there is access to all the forms C listed in the concerned POPI:
73
EXISTING FUNCTIONS IN GMT: Financial Closing
Export of a POPI:
74
EXISTING FUNCTIONS IN GMT: Financial Closing
Following columns:
75
EXISTING FUNCTIONS IN GMT: Financial Closing
Following columns:
76
EXISTING FUNCTIONS IN GMT: Technical Closing
• Technical Closing:
- Upload Documents*
- Comment Documents
- Manage Documents
- Follow Comments
- Validate Forms C
- Validate Form C Adjustments
*(see the GMT Training Session in the annex)
77
EXISTING FUNCTIONS IN GMT: Technical Closing
• The part “Comment Documents” is meant for the Project Officer (PO) who has to accept the technical part of the work done by the beneficiary (as it has been explained in the slide devoted to the GAM). So the PO usually needs to ask for clarification/request for action to the beneficiary through these comments.
78
EXISTING FUNCTIONS IN GMT: Technical Closing
He/she does so in the “Comment Documents” section by first choosing the year and the ITD:
79
EXISTING FUNCTIONS IN GMT: Technical Closing
And then by choosing the beneficiary and the type of technical document his/her comment refers to:
80
EXISTING FUNCTIONS IN GMT: Technical Closing
• Once a comment has been done, an email is sent to the ITD Coordinator and the beneficiary. See an example below:
“Dear ITD Coordinator, Following the submission of the document "SAGE_pdf_SAGE Periodic Report 2012_v1.pdf", which is a "QR Q4+ ANNUAL REPORT" type of document, please find attached my comment to the attention of the beneficiary "AIRBUS OPERATIONS SAS France" "Please find attached a more detailed analysis of the Annual Report, in particular related to the Explanation of Resources, based on the most recent data provided by Laura Maroto. Overspending , around 19% of what was planned in the last amendment (15000 euro in JU contribution). Personal costs are mostly in line with what planned. This is in line with the person-month execution. As no overheads were indicated.in the original table, I compare it to the sum of personal costs and overheads in the form C. No other direct costs executed. Subcontracting is much higher than planned (99200 euro instead of 50000). Explanation of resources is complete, except that more details about subcontracting in particular who are the suppliers and why the subcontracting costs have been increased is requested. Need further details in the Explanation of resources to validate the costs. Can you ask the concerned beneficiary to update the document accordingly or to clarify requested points to me? Thank you in advance The CSJU Project Officer”
81
EXISTING FUNCTIONS IN GMT: Technical Closing
• From this stage, the beneficiary and the ITD Coordinator can also view the comments addressed to them in the “Follow Comments” section. The latter is also useful for the PO who can view, edit, and close his/her comments, according to the beneficiary’s offline response:
82
EXISTING FUNCTIONS IN GMT: Technical Closing
83
EXISTING FUNCTIONS IN GMT: Technical Closing
84
EXISTING FUNCTIONS IN GMT: Technical Closing
• The “Manage Documents” function is a repository for all the documents uploaded, where every GMT user can see them but not necessarily download them.
• The deliverables are downloadable only and exclusively by the concerned beneficiary and PO.
• All the other documents uploaded by the ITD Coordinator are downloadable by the beneficiary.
85
EXISTING FUNCTIONS IN GMT: Technical Closing
86
EXISTING FUNCTIONS IN GMT: Monitor Process
• Monitor Process:
- RFCs
- Forms C
- Form C Adjustments
- Export Comments for ITDs
- Mail**
- SFRs for Closing
- Payment Order
- PO Comments
** (no longer used) 87
EXISTING FUNCTIONS IN GMT: Monitor Process
• Several functions in “Monitor Process” are identical and have already been covered earlier in this presentation:
The “RFC” function in “Monitor Process” is strictly equivalent to the “Follow RFC” in “Manage Grant”;
The “Forms C” and “Form C Adjustments” are respectively equivalent to the “Validate Form C” and “Validate Form C Adjustment” in “Financial Closing” (and similar to the “Administrator”’s function “Manage Beneficiaries”, “View” mode, except that this one is only available to administrators and that there is no filter, so much less handy to use on a regular basis);
“SFRs for Closing” and “Payment Order” are exactly the same as in “Financial Closing”;
“PO Comments” function in the present section is identical to “Follow Comments” in the “Technical Closing” section.
88
EXISTING FUNCTIONS IN GMT: Monitor Process
• “Export Comments for ITDs” is a function similar to “SFRs for Closing” but the status of validation is more detailed for each form C. It includes the PO’s acceptation:
89
EXISTING FUNCTIONS IN GMT: Monitor Process
90
GMT DATABASE ARCHITECTURE (1/23)
• Entire Diagram
• Half Diagram
• More Detailed Views
91
GMT DATABASE ARCHITECTURE: ENTIRE DIAGRAM (2/23)
92
GMT DATABASE ARCHITECTURE: HALF DIAGRAM (3/23)
93
GMT DATABASE ARCHITECTURE: HALF DIAGRAM (4/23)
94
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (5/23)
• In the 18 next slides, you will find more detailed views of the different parts of the same diagram.
• The screenshots are first from left to right (3), and then from top to bottom (6).
95
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (6/23)
96
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (7/23)
97
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (8/23)
98
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (9/23)
99
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (10/23)
100
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (11/23)
101
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (12/23)
102
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (13/23)
103
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (14/23)
104
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (15/23)
105
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (16/23)
106
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (17/23)
107
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (18/23)
108
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (19/23)
109
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (20/23)
110
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (21/23)
111
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (22/23)
112
GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (23/23)
113