114
GMT PRESENTATION FOR FUTURE DEVELOPERS By Aurélia MELLIN (Cleansky) [email protected]

GMT PRESENTATION FOR FUTURE DEVELOPERS

  • Upload
    lydang

  • View
    219

  • Download
    0

Embed Size (px)

Citation preview

Page 1: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT PRESENTATION

FOR FUTURE DEVELOPERS

By Aurélia MELLIN (Cleansky)

[email protected]

Page 2: GMT PRESENTATION FOR FUTURE DEVELOPERS

SUMMARY

• INTRODUCTION: WHAT IS GMT?

• CONTEXT OF CLEAN SKY

• WHY GMT?

• OVERVIEW OF THE ANNUAL PROCEDURE

• EXISTING FUNCTIONS IN GMT

• GMT DATABASE ARCHITECTURE

2

Page 3: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 4: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 5: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 6: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 7: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 8: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 9: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 10: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 11: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 12: GMT PRESENTATION FOR FUTURE DEVELOPERS

• 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

Page 13: GMT PRESENTATION FOR FUTURE DEVELOPERS

• 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

Page 14: GMT PRESENTATION FOR FUTURE DEVELOPERS

• 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

Page 15: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 16: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 17: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 18: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 19: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 20: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 21: GMT PRESENTATION FOR FUTURE DEVELOPERS

See following step

Overview of the annual procedure: Closing: the FORM C Workflow

21

Page 22: GMT PRESENTATION FOR FUTURE DEVELOPERS

Following step

Overview of the annual procedure: Closing: the FORM C Workflow

22

Page 23: GMT PRESENTATION FOR FUTURE DEVELOPERS

Overview of the annual procedure: Closing: the FORM C Workflow

23

Page 24: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 25: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 26: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 27: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Dashboard

27

Page 28: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 29: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 30: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 31: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

31

To edit the accountant’s role: see next slide

Page 32: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

32

Page 33: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 34: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

34

To edit the page « AdminMenu »=> «ManageUsers »:

see the next slide

Page 35: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

35

Page 36: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 37: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

37

To edit the ITD Coordinator’s information: see the next slide

Page 38: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

38

Page 39: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 40: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

40

Page 41: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

41

Beginning of the list of all the beneficiaries for SFWA

(for each GAM year)

Page 42: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 43: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

43

Page 44: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

44

Page 45: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 46: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 47: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 48: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

48

To edit the information about this company OR its GMT users: see the next

slide

Page 49: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 50: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

50

Page 51: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 52: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

52

Page 53: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

53

To be created by the administrators

Page 54: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 55: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Administrator’s Section

55

Page 56: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 57: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 58: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Manage Grant

58

Page 59: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Manage Grant

• “List GAM Amendments” shows the list of Maximum JU Contribution for each beneficiary:

59

Page 60: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Manage Grant

60

Page 61: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Manage Grant

61

Page 62: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 63: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Manage Grant

63

Page 64: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Manage Grant

64

Page 65: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 66: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 67: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Financial Closing

67

Page 68: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Financial Closing

68

Page 69: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Financial Closing

69

Page 70: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 71: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 72: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Financial Closing

72

Listing the

POPIs

Generating a new POPI

Page 73: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 74: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Financial Closing

Export of a POPI:

74

Page 75: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Financial Closing

Following columns:

75

Page 76: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Financial Closing

Following columns:

76

Page 77: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 78: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 79: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Technical Closing

He/she does so in the “Comment Documents” section by first choosing the year and the ITD:

79

Page 80: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Technical Closing

And then by choosing the beneficiary and the type of technical document his/her comment refers to:

80

Page 81: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 82: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 83: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Technical Closing

83

Page 84: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Technical Closing

84

Page 85: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 86: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Technical Closing

86

Page 87: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 88: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 89: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 90: GMT PRESENTATION FOR FUTURE DEVELOPERS

EXISTING FUNCTIONS IN GMT: Monitor Process

90

Page 91: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE (1/23)

• Entire Diagram

• Half Diagram

• More Detailed Views

91

Page 92: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: ENTIRE DIAGRAM (2/23)

92

Page 93: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: HALF DIAGRAM (3/23)

93

Page 94: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: HALF DIAGRAM (4/23)

94

Page 95: GMT PRESENTATION FOR FUTURE DEVELOPERS

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

Page 96: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (6/23)

96

Page 97: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (7/23)

97

Page 98: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (8/23)

98

Page 99: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (9/23)

99

Page 100: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (10/23)

100

Page 101: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (11/23)

101

Page 102: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (12/23)

102

Page 103: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (13/23)

103

Page 104: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (14/23)

104

Page 105: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (15/23)

105

Page 106: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (16/23)

106

Page 107: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (17/23)

107

Page 108: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (18/23)

108

Page 109: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (19/23)

109

Page 110: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (20/23)

110

Page 111: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (21/23)

111

Page 112: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (22/23)

112

Page 113: GMT PRESENTATION FOR FUTURE DEVELOPERS

GMT DATABASE ARCHITECTURE: MORE DETAILED VIEWS (23/23)

113

Page 114: GMT PRESENTATION FOR FUTURE DEVELOPERS