Baseline Document for Grantor Management Release 1

Transcription

1 Baseline Document for Grantor Management Release 1 Issued By: Grantor Management Team Release Date: Topic: Base Line Guidance - Release 1 Document Identifier: GRT_G_RL1

2 The following signatures indicate approval of this document and its contents. Name Signature Date Chandramouli Ramanathan Project Director Umoja Vera Rajic Finance Team Lead Umoja Shaun Rubin Project Manager Umoja Internal Revision History Version Date Revised By Comments v Binod Lamsal Initial Draft v Elsa Bonecillo-Deniega Review v Nina Tillens Review v Grantor Management Team Final Release 1.0

3 Table of Contents TABLE OF CONTENTS... 3 GRANTOR MANAGEMENT BASELINE RELEASE OBJECTIVES GRANTOR MANAGEMENT BUSINESS PROCESS LOGGING IN TO SAP CRM GRANTOR MANAGEMENT PROCESS GRT_L301 GRANTOR PROGRAM CREATION AND APPROVAL Create Grantor Program Step Submit the Grantor Program Approve Grantor Program L1 - Program Officer Programmatic Review Approve Grantor Program by Certifying Officer Financial Review Errors & Notes GRT_302 IDENTIFY AND ENGAGE POTENTIAL GRANTEES GRT_303 SCREENING AND REGISTRATION GRT_304 APPLICATION Creation of Application Printing the Application Selection Review of the Application Errors and Notes GRT_L305 POST-APPLICATION APPROVAL GRT_L306 NEGOTIATIONS ON GRANTOR AGREEMENT Enter Account Assignment in the Application: Generate Proforma Contract for Negotiations Enter and change editable fields Enter Bank Details Add non-standard clauses Change the amount of the Proforma Contract Change the dates of the Proforma Contract Attach additional submitted documents Generate Finalized Proforma Contract Generating the Annexes Program Review and Approval in Workflow Agreement Review (based on UNMAS Example) Legal Review of non-standard clauses Programmatic Review Financial Review Financial Review by Senior Finance Officer Final Approval Application Errors and Notes GRT_L307 SIGNING OF GRANTOR AGREEMENT Generate Grantor Agreement GRT_L308 BUDGET CONSUMPTION OF GRANTOR AGREEMENT GRT_L309 FUND CERTIFICATION OF GRANTOR AGREEMENT Create Funds Certification Document Workflow and Approval for Fund Certification GRT_L310/GRT_L311 LIFE CYCLE EXECUTION OF GRANTOR AGREEMENT Payment Request Payment Request Creation... 78

4 Payment through UNDP Financial Authorization Payment Request Approval-L1-PO Payment Request Approval-L2-CO Payment Request Approval-L3-AO Payment Request Notes Expense Report Creation of the Expense Report Expense Report Approval Procedure for Claims where Reported Expense is More than the Advance Amount Expense Report Errors and Notes Amendment Creation of Amendment for change the Agreement Amount Approval of the Amendment Creating Funds Certification for Amendment Time Extension - Changing the Dates Amendment Errors and Notes: GRT_312 CLOSURE OF GRANTOR AGREEMENT Closure of the Grantor Agreement Errors and Notes GRT_313 CLOSURE OF GRANTOR PROGRAM Closure of Grantor Program Errors and Notes ANNEXES ANNEX 2.1: GUIDANCE IN TESTING THE AGREEMENT WITH EXTERNAL PARTIES ANNEX 2.2: PAYMENT METHOD QUICK GUIDE (USD-EUR-GBP-XOF-XAF) ANNEX 2.3: WORKFLOW OVERVIEW ANNEX 2.4: SECURITY OVERVIEW ANNEX 2.5: GRANTOR PROCESS FLOW OVERVIEW

5 Changes Introduced in the subsequent soft releases 1. Changes Introduced in Release Defaulting of Expense Types in the Grantor Program 1.2 Automatic Calculation of Indirect Costs for Funds Certification and Payment Request Documents 2. Coming soon: 2.1 Defaulting of Process Assignment (Object Type, Transaction Type & Web Form) in the Grantor Program 2.2 Disabling and defaulting of the Program Management Area in the Grantor Program to UN Sales Org (O ) Page 5 of 114

6 GRANTOR MANAGEMENT BASELINE RELEASE 1 1. Objectives The overall objective of the Based Line Document for Grantor Management is to capture the designed, configured and tested Grantor Management Process developed under UE2 Implementing Partner Project for each release of the solution. All UE2 Projects, including Implementing Partner Projects, are based on agile method, where functionality is rolled out in phases. It is important to realize that at each point of time the solution that exists in the system, represents work in progress rather than the delivered end product. The new functionality will be rolled out by means of soft releases (e.g. Release 1.1, 1.2, etc.) and hard releases (e.g. Release 1, Release 2). The document is intended to be updated for each release. The current version of the document represents scope of design, configuration and testing for Grantor Management Process for Release 1. For Release 1, the Grantor Management Process have undergone three major testing cycles, i.e. PIT1 (mostly concentrated on the process), PIT2 (mainly concentrated on the security) and UVT (validating the process and security), which were done concurrently with the users in UNMAS, UN HABITAT and UNEP. Each Level 4 process steps were translated in the detailed scripts for performing certain tasks/actions in the system by certain roles. Therefore, this document is intended to focus on the additional variances and nuances to the standard Grantor Management Process steps rather than steps themselves. It is also intended to be entity agnostic to cover different scenarios in UN from different entities which are within the framework of the standard Grantor Management Process. The document can be used as a term of reference by Grantor Management Trainers for developing or updating existing training materials, training manuals, training guidance, step-bystep guides, scripts as well as the delivering in-class training courses for Grantor Management. 2. Grantor Management Business Process The Grantor Management Business Process is a part of the UN Business where the UN is acting as a Grantor, i.e. giving money to its Implementing Partners and End Beneficiaries. This business process is currently supported in Umoja in both the Grantee Management and Source to Acquire (Procurement) modules, but with the introduction of Grantor Management the current processes will eventually be phased out. Page 6 of 114

7 In the diagram below, you can see the definition of the Grantor and Grantee. These terms are key in understanding both on the Umoja Grantee Management and Grantor Management modules. If the UN plays the role of the Grantee (e.g. receiving money from the donors), the Grantee Management will be the module recording the transactions. If the UN acts as a Grantor (e.g. giving money to Implementing Partners and End Beneficiaries) the Grantor Management will be the module capturing the related transactions. The outgoing grants presented in the diagram (Passthrough Grants) will be phased out with time. In Foundation, Umoja leveraged the use of the Procurement process for the grantor process. Purchase Orders were utilized as obligation for the IP/EB agreement. With the introduction of the Grantor Management system, a distinction is clearly made from the Procurement Process where the UN follows specific policies in contracting with Commercial Vendors. (The Procurement process is supported by another Umoja module called SRM (Supply Relationship Management). It is also important to note that Grantor Management can be used for scenarios with different funding sources and not only for Agreements with Implementing Partners and End Beneficiaries that are funded by Voluntary Contributions recorded in Grantee Management. During the Grantor Management Workshop in May 2018, representatives from various entities met and agreed on business requirements for the Grantor Management. Page 7 of 114

8 As per the structure of the Umoja Project the Grants Management (that consists of Grantee Management and Grantor Management) belongs to Finance Management. Therefore, the high-level business process, defined in the Workshop in May 2018 are categories in Umoja as Level 3 Business Process steps for Grantor Management. During the Grantor Management Workshop in May 2018, representatives from various entities met and agreed on business requirements for Grantor Management. High Level Business Process Steps were identified as follows: Naming conventions for the process steps: GRT stands for Grantor Management L301 stands for Level and Business Process step, where first two digits represent Level 3, and last two digits represent Grantor Management Process step. GRT_L301 Grantor Program GRT_L302 Identify and Engage Potential Grantees GRT_L303 Screening and Registration GRT_L304 Application GRT_L305 Post Application Approval Page 8 of 114

9 GRT_L306 Negotiations on Grantor Agreement GRT_L307 Signing of Grantor Agreement GRT_L308 Budget Consumption of Grantor Agreement GRT_L309 Fund Certification of Grantor Agreement GRT_L310 GRT_L311 Life Cycle Execution of Grantor Agreement GRT_L312 Closure of Grantor Agreement GRT_L313 Closure of Grantor Program Level 3 business process steps represent the conceptual business process of the UN. Level 4 business steps represent actions that would need to be performed in Umoja. It is worth noticing that not all business steps in Grantor Management Process will be performed in the Grantor Management module, but they are the part of the Grantor Management Process. See diagram below for Level 4 process flow: Page 9 of 114

10 Each step of end-to-end process is described in the scripts are located in the Testing Community on Unite Connections ( Each step is performed by users that have a certain enterprise role assigned to them. The roles might be entity specific, but Umoja is harmonizing the Grantor Process across the UN entities. There are two major business scenarios in UN for creation of the Grantor Program in Grantor Process: Page 10 of 114

11 Scenario #1: Grantor Program is launched for existing UN projects. In this case the Grantor Program has detailed project specific requirements dictated by project needs. Scenario #2: Grantor Program is launched without an existing UN project and has a broader framework based on the Mandate. In this case, the applicants will submit to the UN the proposals of the project within the guidelines established by the Grantor Program. The steps of the overall Grantor Management Process are the same for both scenarios but the timing of creation of the Project and linking it with the Grantor Program is different. The design of the process allows creating the Grantor Program and go through the selection process without actually having the project in the Umoja. But at a certain point in the process, the project has to be defined in the system as well as the rest of the account assignment. The account assignment has to be defined on the Application during negotiations. Depending on the scenarios the description, objectives, summary and priorities of the Grantor Program will be different. See the section on Grantor Program for further details. As UE2 Implementing Partner project is being implemented in phases the next diagram below shows which steps are not implemented yet in Release 1. Page 11 of 114

12 In Release 1, the following functionalities are not introduced or partially introduced (workaround marked with *): GRT_L301 Grantor Program o Create Grantor Program Planned Budget will be done in BPC not in GRT o Approve Grantor Program Planned Budget will be done in BPC not in GRT GRT_L302 Identify and Engage Potential Grantees o Profile the UN Grantees o Create Target Groups for NGOs and Government Institutions o Create personalized s for NGOS o Assign Target Groups to Campaign o Create and Run the Campaign to send s to Potential BP GRT_L303 Screening and Registration o Submit BP Request for User Credentials (online) IP/EB o Create User ID with Role Provisioning for Contact o Submits IB/EB Registration Contact o Request for Due Diligence o Capacity Assessment o Approve Registration Request GRT_L304 Application o Apply for Grantor Program (Concept Note) o Pre-assessment (Concept Note Review) o Endorse List of Selected Potential Grantees o Send Notifications to Potential Grantees o Assign Grantor Program to Project Activities GRT_L305 Post Application Approval o Create Grantee in ECC (Post-Application Approval) o Maintain BP Grantee in ECC o Move Grantee to CRM o CRM Duplication Check and Merge GRT_L306 Negotiations on Grantor Agreement* o Some variances for the process, e.g. GEF Agreement GRT_L307 Signing of Grantor Agreement* GRT_L308 Budget Consumption of Grantor Agreement this will be done in ECC via Funds Management or Grants Management with a streamlined and improved process with less steps. No system changes required. All changes in the process should be addressed through training. GRT_L309 Fund Certification of Grantor Agreement GRT_L310 GRT_L311 Life Cycle Execution of Grantor Agreement o Reminders and Alerts* o Progress and Tracking Reports* Page 12 of 114

13 o IP/EB Monitoring and Evaluation o Submit Audit Reports * o Review audit Reports on IP Implementation * GRT_L312 Closure of Grantor Agreement* GRT_L313 Closure of Grantor Program* Planned soft releases will introduce new processes, improve the current functionality or fix certain issues as well as accommodate the variances to already existing process step. Later versions of the Base Line Document, that will represent subsequent releases in functionality and improvements to the process, will incorporate such changes. There are master and transactional data in Grantor Management that support to-end Grantor Process and allow transactions to be recorded in the system. Master Data: Business Partner A Business Partner may be a person or organization in which your organisation has a business interest. Grantor Program A master data in the Grantor Module that represents the UN Call for Proposal and facilitates the outreach to the Implementing Partners and End Beneficiaries. Transactional Data: Application A business transaction that contains data submitted on an application form by a potential grantee together with other additional data necessary for processing transactions with this application. Agreement A business transaction that contains the conditions under which a grantor awards a grant to a grantee. Change Request - A transactional data functionality used in Umoja in three ways: o Funds Certification the transactional data in Grantor Management for obligating funds against the Agreement o Payment Request The transactional data in Grantor Management to process payment or disbursement to the End Beneficiary or Implementing Partners. o Amendment to record changes to the Agreement. Claim: Statement of Income and Expense aka Expense Report Used to record the Expense Report which is also called Statement of Income and Expense. Each of the master and transactional data objects have their statuses and workflows. See Annex for workflow overview. Page 13 of 114

14 3. Logging in to SAP CRM Grantor Management The URL to access SAP CRM in production is To login, the user needs to use his/her Unite ID and password. Note that the preferred internet browser when using Grantor Management is Chrome. Refer to the ilearning course on how to access the system. For external users who will be accessing the system via the web outside of the firewall, the system name in the guiding screen is UN Global Partner System (Grantor Management Module). For Internal users who will be accessing the system via Citrix, an icon called Implementing Partners will be available under Umoja Production and will bring the user to the login screen Grantor Management. Note that for training purposes, a separate set of instructions that will be provided to the trainees to access the training environment. 4. Process 4.1 GRT_L301 Grantor Program Creation and Approval SAP has indicated the use of a Grantor Program as follows: New or amended policies or regulations are developed or adopted by public-sector organizations and foundations to provide financial assistance to a group of individuals or a group of organizations. Customer organizations commonly manage a diverse range of program types that deliver grants to the external community. These result in the definition of a program and its related characteristics to deliver the external funding and achieve the goals of the policy or regulation. The program serves as a unifying element for the grantor delivery system to manage the data entry and transaction processing effectively and to minimize program management costs, ensure data integrity and overall internal and external accountability It is a master data in the Grantor Management. The UN implements its program of work as follows: UN Offices implement programmes and projects which are in line with the mandates, goals and aims of the Organization. Page 14 of 114

15 The UN can either execute its programmes and projects on its own or use Implementing Partners to help carry out its mandated activities. Programmes and projects can also be executed together with the Partner. In both cases, the UN entrusts the partner to implement its programmes/projects and transfers money to the partner. The partner in turn is responsible and accountable to the UN for the execution of the activities. The UN can also transfer money to the End Beneficiaries to carry out its programmes/projects as long as the End Beneficiaries goals and aims are aligned with that of the UN s. Implementing partner is executing the mandated activities and projects on behalf of the UN. The UN transfers money to the partner who is accountable and responsible for the effective use of resources and to carry out the project, in part or in its entirety. The implementing partner will report periodically to the UN on the implementation of the project. Administrative costs, known as a Programme Support Cost may be shared with the partner. End Beneficiary is receiving money and/or in-kind resources for executing the projects/activities which are in line with the aims and the objectives of the UN and benefit the End Beneficiaries themselves, support its programme objective and build its capacity. The SG is proposing new financial regulations and rules for Implementing Partners and End Beneficiaries. The Controller s Office is leading the effort to establish a framework, policy that will govern Implementing Partnership and End Beneficiary arrangements. In Umoja the Grantor Program is defined a Master Data in the Grantor Management Module that represents the UN defined scope of work with which the UN reaches out to its Grantees (Implementing Partner and End Beneficiaries) to solicit applications with business proposal. The Grantor Program invites UN Grantees interested in the Grantor Program to submit their proposals with the objective of receiving funds from UN. As a rule the applications go through a selection process. It is a unifying element for the Grantor Management delivery system to manage and report on funding given out to UN Grantees, i.e. Implementing Partners and End Beneficiaries. The closest analog to the Grantor Program in UN business term is a Call for Proposal or Request for Proposal depending on the business model of the UN entity. The Grantor Program has the following elements: Grantor Program ID Program ID is a Unique identifier (24 characters, alpha-numeric). Once the Grantor Program is saved, this number is automatically generated and may bit be edited. Page 15 of 114

16 Description Short description of the Grantor Program. Long Description - It is important to note that Long Description of the Program will be used in Application and finally in Agreement. Make sure that there are no typos and avoid abbreviations for the long description. Objectives The objectives of the Program. This should be concise and clear. Summary Summary of the Program. This is is entered in the section called Notes and should be concise and clear. Priorities Priorities of the Program. The summary is entered in the section called Notes and should be concise and clear. Program Type Classifies programs based on common characteristics (4 characters, alpha-numeric). In Umoja, only two types of the Grantor Program are used, i.e., Grantor Programs for End Beneficiary and Grantor Program for Implementing Partner. Start Date and End Date Start Date and End Date define the Life of the Grantor Program to control processing activities. Only within defined by start and end date period the Grantor Program and linked to it transactional data such as Application, Agreements, Claims, Change Request, can be used in Transactions. Service Organization Service Organization is an organizational unit that forms part of an organizational model and represents a functional unit where tasks are performed. Each entity will have a set of service organizations that have their Grantor Programs for Implementing Partners and End Beneficiaries. Tolerance Profile The percentage by which each agreement item can be over/under spent, with the total amount of the agreement remained unchanged. Note that the level of tolerance is established at the Grantor Program level and defaults to all underlining Agreements. It cannot be changed at the agreement level. Expense Types The available agreement expense types or categories are defined on the Grantor Program. It is important to ensure that both summary and itemized level expense types will be set up on the Grantor Program. Currency The currency defined on the Grantor Program is defaulted to transactions and transactional data under this Grantor Program. Status The status defines the stage of the Grantor Program at each point in the business process. See detailed explanation below. As earlier noted, there are two major business scenarios in UN for creation of the Grantor Program: Scenario #1: Launched for existing UN projects. In this case the Grantor Program has detailed project specific requirements dictated by project needs. Page 16 of 114

17 Scenario #2: Launched without an existing UN project and has a broader framework based on the Mandate. Here, applicants submit to the UN the proposals of the project within the guidelines established by the Grantor Program. Depending on the scenarios the description, objectives, summary and priorities of the Grantor Program will be filled in differently. If the Grantor Program is created for a defined UN project (Scenario #1) and the whole project is outsourced to IP, the description, objectives, priorities and summary of the Grantor Program should be that of the Project s. If the Grantor Program is created as part of the project, e.g. for one outcome the description, objectives, priorities and summary of the Grantor Program should be aligned with this outcome. If the Grantor Program is created based on the Mandate of the UN entity and the proposals for the projects have to be submitted by the applicants to this Grantor Program, the description, objectives, summary and priorities of the Grantor Program should be defined based on the Mandate of the entity. In addition, there are controls on the Grantor Program for the period of time when Application, Agreement and other parts of the process can be conducted. For example, the period of submitting the application can be established on the Grantor Program All transactional data have to be set up on the Grantor Program to support end-to-end process. All the expense categories that are used by the UN has to be set up on the Grantor Program. And the list of the documents that are required from the Applicant, Call for Proposal as well as other documentation necessary for the Applicant have to be attached to the Grantor Program. There are four main steps related to Grantor Program. They are as follows: S.no Process Steps Required Role 1 Create Grantor Program Program Assistant (PA) GR.01 2 Submit Grantor Program for Approval Program Assistant (PA) GR.01 3 Level 1 Approves Grantor Program Program Officer (PO) GR.02 4 Level 2 Approves Grantor Program Certifying Officer (CO) GR.07 In each stage of the Grantor Program, it will have always have two statuses: System Status and User Status. System Status is delivered by SAP while the User Status were defined and created in Umoja. System Statuses: Created, Released, Closed (see diagram below). User Statuses: In Process, Programmatic Review, Financial Review, Approved, Completed, Closed (see diagram below) Page 17 of 114

18 The Program Assistant (PA) creates the Grantor Program. When saved, the status defaults to Created/In Process. At this stage, the Grantor Program can be modified as many times as needed. The Grantor Program can also be cancelled a this stage ( Created/Cancelled ) which can then be reinstated back to status Created/In-Progress when needed. Once the Grantor Program is ready to be submitted for approval, the Program Assistant manually changes the status to Created/Programmatic Review. Saving it with this status will send this document to the workflow for the Program Officer s review and approval. The Program Officer (PO) receives the Grantor Program in his worklist with the status Created/Programmatic Review. The PO can either Approve (status will change to Created/Financial Review and will be sent to the Certifying Officer s worklist), Return (status will change back to Created/In Process and returned to PA) or Reject (status will change to Created/Rejected and will terminate the workflow). The Certifying Officer (CO) receives the Grantor Program in his worklist with the status Financial Review. The CO can either Approve (status will change to Released/Approved and will be removed from the workflow), Return (status will change back to Created/Programmatic Review and returned to PO) or Reject (status will change to Created/Rejected and will terminate the workflow). Page 18 of 114

19 At this point, the Grantor Program is fully operational and can be used in transactions. The settings on the Grantor Program will define if it is open to receive Applications. Once the Grantor Program is in status Released/Approved, it cannot be reinstated to the previous statuses. It can only go further to the end of the process, i.e. the end of life cycle for the Grantor Program. The statuses beyond this point is changed by the Program Officer. Other statuses such as Released/Completed and Closed/Closed will be used during the closure of the Grantor Program Create Grantor Program Step a. In CRM, locate the Navigational Bar on the left side and click on Programs. b. On the right side of the screen, click on Programs under Create. Page 19 of 114

20 c. This opens a screen for new Grantor Program which requires completion of certain sections. Complete the program details by entering Description, Program Type, Start and end date, Service Organization. Program Management Area, Currency, Program Profile, Objective and Long Description. Save the program clicking on save icon. Program ID not editable; this field is automatically filled in with the Grantor Program Number once the master data is saved Description enter a short description of the Grantor Program Program Type click the dropdown selection arrow and choose if this program is for an Implementing Partner (IP) or an End Beneficiary (EB). Please refer to the policy when deciding the program type. Note that this selection drives the corresponding accounting entries; hence, it is very important that the correct Program Type is appropriately decided. It is important to bear in mind that when actual transactions are processed against the Agreement, the Program Tpe can no longer be changed due to its financial implications. Start date enter the Start Date of the Grantor Program End date enter the End Date of the Grantor Program Employee responsible system defaults the name of the user creating the Grantor Program Service organization this element defines the organizational unit to which the Grantor Program belongs to. Note that this is an important element required in configuring the workflows. Page 20 of 114

21 Program Management Area is a system-defined Grantor Program element that encompasses the UN organization. It is not editable and always has a fixed valie of UN Sales Org. Current status this reflects the current status of the Grantor Program New status Leave blank except submitting the Grantor Program to the workflow for approval where the Program Assistant sets this to Programmatic Review to trigger the workflow. Currency select the appropriate currency. This will drive the currency for the agreement and the subsequent financial transactions. Program Profile this profile defines the tolerance rate for expenses. The Program Profiles defined in the system are the following: 0%, 10%, 15%, 20%, 25%, 30%. Note that the tolerance rate applies to all agreements under this Grantor Program. Zero tolerance rate has the strictest control. The system checks the line item of the Agreement/ Authorized Amount, after checking that the claim total does not exceed the advance amount. Objective - wnter the objectives for this Grantor Program. Long Description this allows the user to enter a long description of the Grantor Program. Note that this is required when generating the details in the agreement. The top right side of the screen shows the system messages. While creating the Grantor Program, it will show what fields are required to be filled up, if not filled up yet. Once all mandatory fields are completed, these errors will disappear. The Process Control section of the Grantor Program defines the period when applications, agreements, claims or change requests can be created, submitted or blocked. If the option Open is chosen, there is no restriction for creation or submission. Blocked means that no transaction can be initiated. Date Restriction allows transactions to be created within the defined date range. Page 21 of 114

22 Note: Always check the top right side of the screen for any system messages which may show error messages for any data that needs to be entered or corrected. d. Complete the Process Assignments section by clicking on Edit List by selecting the Transaction Type and the Web Form. Note that all Transaction Types and Web Forms shown below need to be selected. It is an important step as each transaction type correspond to the object in the process that needs to be created. If the transaction type is not selected for the object, all Agreements related to this Grantor Program will not be able to record this process step. For example, if the Change Request Object for Amendment transaction type is not selected on the Grantor Program, the Agreements under this Grantor Program will not be able to have Amendment. Note that Change Request object is used in three ways for: Funds Certification, Payment Request and Amendment. Claim object is used for Expense Report that is called Income and Expense Statement. Page 22 of 114

23 e. Complete Expense types by clicking Edit List and enter UN Expense Type under Expenses Catalog, both Summary Expense Type and Itemized Expense Types under Expense Group and all the Expenses Types as shown below. Save. f. Attach your Call for Proposal and other documents by clicking on Attachments. Likewise, attach other Templates for information required from Applicants. g. In the Notes Section, add texts for the Notes, Summary and Priority of the Grantor Program. It is important to record the Summary and Priorities in the Note section. To do this, click on New icon, choose the appropriate note type, i.e., Note, Summary or Priority, and enter the corresponding text. Click on back arrow once done and save the Grantor Program. The created note will be displayed as link with the corresponding note type. h. Save the Grantor Program. After saving, the Grantor Program ID no. is generated by the system as shown below. Page 23 of 114

24 4.1.2 Submit the Grantor Program a. Click on Edit under the Program Details section. b. Change the New Status to Programmatic Review. lick on Save and note the Grantor Program number. At this point, the Grantor Program is submitted for approval in the workflow Approve Grantor Program L1 - Program Officer Programmatic Review This step involves Level 1 workflow approval for Programmatic Review; therefore, the user must have the Program Officer role associated to the specific service org. In Programmatic Review the Program officer reviewed all the Programmatic Aspects of the Grantor Program, among others the most important are: Type of the Grantor Program (IP or EB) Description Page 24 of 114

25 Long Description Objectives Summary Priorities Attached documentation including Call for Proposal, list of required supporting documents, etc. Project profile tolerance Start and End Date The Grantor Program settings in Process Control Section Process Assignment section contains all object and transaction types as well as WebForms a. Go to the Worklist and click the relevant Grantor Program GPXXXXX under Associate Business Object. b. Review the appropriate Program Type, Tolerance profile, Start/End date and Currency captured in the Program details. c. Check that the Objective and Long description provide the correct details about the Grantor Program. Page 25 of 114

26 d. Note any periods selected. In the given example, the application is open from 1 st Jan 2019 to 28 Feb This means IP/EB can make the application in the given date range only. e. Ensure that the Process assignment section captures all the Object type, Transaction Type, Web Form, expense Types and attachment. f. Ensure that the Expense Types section have both Direct Cost Summary and Indirect Cost Summary are included and that all itemized expense types are included as shown below. g. Click Back button on the top right side of the screen to get back to the main Worklist screen. On the main screen of the Worklist, click the relevant Grantor Program under the Subject column. Page 26 of 114

27 h. On the next screen (see below), approve or reject the Grantor Program. If necessary, return the document to the Program Assistant to provide the additional information or correction. (This completes the Level 1 Approval by the Program Officer.) Click the Back icon to get back to the main screen of the Worklist. You can use the notes to explain the justifications behind your action: Approval, Return or Rejection Approve Grantor Program by Certifying Officer Financial Review This step involves Level 2 approval in the workflow Financial Review; therefore, the user must have the Certifying Officer role associated to the specific service org. a. Go to the Worklist, review the document by clicking on the specific Grantor Program ID number under the column Associated Business Object. Page 27 of 114

28 b. Review the Grantor Program as outlined in the steps above for Program Officer and pay special attention to the following: Ensure that the appropriate Program Type is selected. Note that if the Program type is selected incorrectly, the wrong accounting entries would be recorded in the books. Review the Tolerance profile and ensure that all the Expense Types have been selected. If selected incorrectly, each expense line will be overspent/underspent with different threshold. Review Process Assignment section and ensure that is contains all object and transaction types as well as WebForms Review Expense Types section and ensure that is contains all expense types, both summary types and itemized types. c. After your review of the document, exit to the main Worklist screen. Click on the Grantor Program number under the Subject column. d. On the decision screen, indicate your approval (or rejection) by selecting the appropriate decision from the dropdown list and click on the button Execute Decision. Page 28 of 114

29 You can record comments justifying the decision to approve, reject or return under Add Note. e. After the Certifying Officer s approval of the Grantor Program, the status should change to Released, Approved status. Note that the Grantor Program is only available for use in transacting when it has status Released, Approved. f. To check the status of the Grantor Program, locate Programs on the left side of the main CRM screen, select Programs under Search. On the Search Criteria screen, look for the Program ID field and enter the Grantor Program ID number and click Search. As shown below, the Grantor Program status has now changed to Released, Approved Errors & Notes Error Messages: If there are any errors, a message appears on the Grantor Program object (top right side of the screen) with a red icon. The error has to be resolved in order to save the Grantor Program. 1. Check that the date range is appropriately set. IP/EB cannot submit any Application if the application period is blocked and the date of Application is out of range. Page 29 of 114

30 2. If the object and transactional type is not on the Grantor Program, the corresponding step in the business process will not be possible for agreements under this Grantor Program 3. If the expense type is missing on the Grantor Program, all underlining application/agreements will not have this expense type and transactions against it will not be possible. Important Notes: Pay special attention when choosing the Program Profile Tolerance Limit. Depending on the UN Entity rules, the tolerance limit is set from 0% to 30%. The tolerance limit allows the expenses to be posted subject to the tolerance limit without exceeding total budget in an agreement. Note that 0% tolerance means that the user cannot exceed the agreement line item at all. It is, therefore, considered as having the strictest control. Note that tolerance profile is set up on the Grantor Program and cannot be changed at the Agreement level, therefore all the Agreements under Grantor Program will have the tolerance profile established on the Grantor Program. The restriction on process control dates prohibits the creation and execution of transactions beyond the dates. Therefore, carefully review the process control dates and, if necessary, make the changes. If the dates need to be changed in an approved Grantor Program, The Program Officer is authorized to do the changes. The change in dates does not require workflow approval. Process assignment- Object Types, Transaction Types and Web Form currently require manual entry. As the entries are fixed for all Grantor Programs, these will be defaulted in future releases to minimize the user effort to set up the process assignment. There are 8 Expense types required by all entities indicating the summary for direct and indirect plus 2 summary expense types. This will also be defaulted in future releases. If the Grantor Program is rejected from the worklist, it goes out of the workflow and cannot be sent back again (to the workflow). There will be a feature asking for additional confirmation and justification before executing the Reject option in a subsequent release. The Grantor Program can be cancelled before submitting it for approval Programmatic Review and Financial Review. It can be reinstated back by changing the status to In-Process. Grantor Program is moved to Released/Completed and further to Closed/Closed manually by the Program Officer for the closure. There is no integarion with other modules and therefore it is a Program Officer s responsibility to check if all Grantor Agreement under the Grantor Program are Page 30 of 114

31 closed and there are not pending applications. This process will be improved in future releases. 4.2 GRT_302 Identify and Engage Potential Grantees This process involves creating profiles for UN Grantees, creating target groups for NGOs and Government Institutions, assigning target groups to campaigns and running campaigns to send s to potential IPs/EBs. This functionality will be designed, configured and made available in a future release. It is not available in Release GRT_303 Screening and Registration This process involves an online process for submission of BP request for user credentials, creation of user ID with role provisioning for contact, submission of IP/EB registration contact, request for due diligence, capacity assessment, approval of registration request, creation of CRM grantee prospect and contact and creation and maintenance of BP grantee in ECC and CRM. Currently, only the creation and maintenance of BP grantee in ECC and CRM are operational. The rest of the process will be designed, configured and made available in a future release. 4.4 GRT_304 Application There are four phases in the Application process and each is designated with a specific user status in the system. Creation of Application The IP/EB responds to a Grantor Program Call for Proposal and completes an Application. Selection Review The UN Entity receives and reviews the Applications from a pool of Applicants. Negotiation In this phase, the Program Officer compiles the required information for the Agreement and negotiates the terms with the IP/EB. Details of the process are covered in GRT_L306 Negotiations on Grantor Agreement. Agreement Review The final review of the Agreement takes place in this phase. Following approval and signature, a signed copy is uploaded to the system, the dates of the signatures are updated in the system and the Agreement is generated. Details of the process are covered under GRT_L306 Negotiations on Grantor Agreement and GRT_L307 Signing of Grantor Agreement. Page 31 of 114

32 Note that the Application object is used for all four stages of the business process: Creation of the Application (status In-Process ) Selection Review (status Selection Review ) Negotiation of the Agreement and (status Under Negotiations ) Agreement Review (status Agreement Review ) Once the agreement review is over, the status of the application goes to Awarded To generate the Agreement in the system as an object, the Application object should have been approved and in status Awarded. Depending on the UN entity, there are various stakeholders engaged during the review and approval of an application. Selection Review and Negotiation of the Agreement are entity specific processes and the levels of approval differ from entity to entity. The last status in the Application cycle is Awarded. The workflow allows the reviewer to approve, reject or return the application for additional information. The approval of the Application moves it to the next step, Return sends back the Application to the previous user and Reject moves the application out of the workflow. If the application is returned, an additional action is required from the approver/user of the previous level. If returned, it can be resubmitted after the necessary actions are completed. Grantor Management allows all users to view the status of the Application. Page 32 of 114

33 4.4.1 Creation of Application Once the Grantor Program is approved, it will be available for application. The IP/EB can log into Grantor Management, choose the relevant Grantor Program and submit their application together with their supporting documents. The IP/EB completes all the details required in the Application form and submits it for assessment review and approval. The Program Assistant can fill in the application on behalf of the IP/EB as well. When the IP/EB applies, the Business Partner (BP) information is automatically displayed from the BP master data. If the PA fills in the application on behalf of the IP, he/she should select the correct IP/EB on the Application. The IP/EB and its contact or focal point should have been registered with the UN Entity and presented the necessary credentials prior to submitting an Application. If the BP is already registered but its details are not available when BP is creating an application, the IP/EB must contact the UN Entity focal point to resolve the issue. Note that the BP not only has to be registered, but should also have a BP contact (focal point that will apply on behalf of the BP) registered with the UN. If certain information needs to be corrected in the master data, then the IP/EB should liaise with the concerned entity focal points to modify the BP master data. Without a contact, the BP will not be able to apply. The Application form in Grantor Management is a Webform that allows the IP/EB to make a print copy for their own record. They have the option to print the application before submitting it. In situations where the IP/EB is unable to complete an Application, a UN staff member with the Program Assistant (PA) role would be able to complete the form on their behalf. (For purposes of preparing this guidance document, it is the Program Assistant s role that is used in entering data in the Application.) The submitted application undergoes assessment review and approval based on the entity specific levels of approval (see Annex 3.3) The IP/EB must have user credentials to log into Grantor Management. Request for user credential can be submitted to the UN Entity Focal Point. IP/EB should contact UN entity focal point if there are issues in the BP data, contact details or if any modification on BP data and contact details are required. UN entity focal points reach out to SLO (Security Liaison Officer) to complete the necessary process and make the user credentials available to IP/EB. Page 33 of 114

34 a. In CRM, click Applications on the Navigational Bar (left side of the main screen) and select Application Forms from the Search screen. Do not use Create option to create the Application, it will be removed from the screen at the later stage. b. To access the application screen, enter the Grantor Program Number in the Program ID field and click on Search button. The Program ID should be included in the Call for Proposal and circulated to potential or eligible partners. This allows IP/EB to choose the right Grantor Program. It is important to include the correct Program ID and Program Description in the Call For Proposal (allocation strategy) when inviting IP/EB to submit their application. IP/EB can also search the application entering the program description. Click the Search button. Page 34 of 114

35 Click on the blue link (see below) to get to the Application form screen. The Application Form appears on the screen. It has four pages that have to be filled in by the Applicant. Note that Application Form can be saved at any time even if it is not completed. To save, click Next Page until you get to the fourth page where the Save icon appears and click on Save. When application is saved, the system generates an Application number and Application object that will be used in transactions. The Application Form becomes the integral part of the Application object. Keep the unique number that identifies the Application (both the form and object) for future reference. To access the saved Application, go back to the main CRM menu, and click Application. Note that in the Search section, the Applications link should be clicked this time, not Application Form. (Application Form link is used only the first time when creating and saving the application form. To get back to the saved form, the Applications link is used.) Page 35 of 114

36 You can search the application by its number. Enter the Application ID no. in the appropriate field. Click the Search button and the Application ID no. will appear under the Search Results and click on Applicaton link. The Application Form has four major parts that are located on separate tabs or pages: Applicant Information, Project Information, Budget Proposal information. Application Form Checklist, File Upload and Certification a. Application Information When the Application Form appears, note the UN Entity logo printed above the application. The first field of the Application is the Business Partner number and next field shows the name. If the application is filled in by IP/EB, the BP field is defaulted on the Application Form. However, if it is the Program Assistant who is creating the Application on behalf of the IP/EB, the PA has to search the Business Partner number as shown below. The user can search using the Business Partner ID, the Organization name or a search term. Page 36 of 114

37 The IP/EB should enter the following fields: Type of Institution This field is required in the Agreement; it is therefore, important that the information be entered properly (no abbreviations) as it will be shown as it is on the first paragraph (of the Agreement). In the future, this field could be enhanced with a dropdown list from which a user can select. This will be one in the future after a reasonable list has been compiled. Date of Establishment This is the date of the registration of the institution. This is field is also mapped to the Agreement. Place of Registration The location (city and country) where the institution was registered is likewise mapped to the Agreement. HQ address The city and country where the institution is currently located are also required in the Agreement, hence, the field is mapped to the Agreement. If the Program Assistant is entering the Application on behalf of the IP/EB, he/she must ensure that these four fields are entered accordingly. Note that the system displays greyed out fields on the Form. These fields contain information that are derived from the Business Partner master data such as the Institution Name, Mailing Address, Telephone Number, Address and Contact Information.The blank fields are expected to be completed by IP/EB or the Program Assistant. Page 37 of 114

38 In addition, the following elements in the Application would need to be completed by the IP/EB or PA filling in the application on behalf of the IP/EB. The Applicant Information tab requires data regarding prior experience in implementing similar projects. This information will help the Program Office decide if the Applicant is indeed qualified to do the project. If the Applicant has documents to substantiate such experience, these files could be attached to the last page reserved for Attachments. Click Next page to get to the next tab. b. Project Information Project Information tab: This tab requires project details from the IP/EB. Note the Grantor Program no. and Description fields are greyed out. Project Title Enter a brief description of the project. Note that this title will appear in the Agreement document. It is, therefore, important to give this project a title that is accurate and concise. Page 38 of 114

39 Project Summary Provide an overview of the objectives, salient statements about this project, its merits and its broader impact to the beneficiaries, the community, the environment, etc. Currency This field cannot be edited. The system defaults the currency selected in the Grantor Program. Amount Requested from UN - This amount should be the same as the total of the proposed budget IP/EB Contribution Amount (if applicable) In projects where the IP/EB is contributing, enter the amount in this field. As mentioned, this may not be applicable to all cases. Co-funding provide the names of other donors to the same project other than the Applicant and UN. Include the amounts, a justification for the selection of those partners and their roles in the project. Location of the Project enter the country, province, district and community (if applicable) Duration of the Project - Provide the project start date and end date in the applicable fields. The proposed dates should be within the Grantor Program valid dates. By default system displays the Grantor Program start/end date. You can edit the dates based on the project activities but within the Grantor Program time period. Grant Justification describe the added value that the IP/EB can provide to the Organization Page 39 of 114

40 Sustainable Development Goals (SDGs) select the SDGs applicable to this project Context Analysis describe the problem conditions that the project aims to influence positively. Project Methodology describe the project plan to be executed. Project staffing describe the staffing plan and the roles and responsibilities of the staff involved in the project. Beneficiaries (Gender and Age) provide information regarding the targeted beneficiaries including vulnerable and at risk groups. Page 40 of 114

41 Demographics if available, indicate the number of men, women and children impacted by this project Transfers and Grants to Sub-grantees If sub-grantees will be utilized, provide the necessary details such as the specific work to be sub-contracted, the duration of their work and the staffing involved. Monitoring and Evaluation Plan Describe the tracking process for the progress of the project. Risks and Mitigation Measures Indicate the main risks of the project and the plan to mitigate such risks. Page 41 of 114

42 Sustainability describe the plan of sustaining the project after the grant has ended. Cross-cutting principles from the list, select the cross-cutting principles that impact the project. Reporting plan indicate the nature of the reports and the plan for reporting Environmental Impact explain how the environment is impacted by this project. Click Next page to get to the next tab. c. Budget Proposal Information: This tab contains the information on the project cost plan that represents the budget proposal and requires the the Applicant to enter a PSC rate and a budget by expense type. d. IP Project Support Cost Rate (PSC) The PSC rate may intially be proposed by IP and subsequently reviewed by the Program Officer based on UN entity rules. Note that this rate is subsequently copied over to the Application object header automatically. When the Application is approved, the system automatically creates a tab with the negotiated IP PSC rate. The PSC rate on the Application header cannot be edited. Any change has to be done on the Project Budget Proposal tab of the Application Form. The Project Cost Plan (Budget Proposal) is created by clicking on the Add button to display the cost component (expense type). Click on the drop-down list to select the appropriate cost component to be budgeted. Type a description, select the unit of measure and enter the quantity and the unit cost. The system will automatically Page 42 of 114

43 multiply the quantity with the unit cost and extend the amount under the column Total. Note that it is possible to show details of the budget on the description column for each expense type as shown in the screen shot below. If further budget breakdown, Bill of Quantity and supporting calculations are required, these information need to be attached to the Application on the File upload section. The user can find this next to the Application tab. It may be possible to propose a budget line for a group of expenses (eg. Construction of schools, temporary shelters) but such budget line must be supported by a Bill of Quantity (a more detailed budget breakdown). The supporting documents should explain how the budget was calculated and should include the list of items, quantity, rate and total amount. If these supporting documents are not uploaded, or the appropriate calculation are not disclosed, there could be a delay in the review of the application. e. Application Form Checklist, File Upload and Certification Complete the Application Form Checklist, attach additional files and read through the assertions on the Certification. Page 43 of 114

44 On the right hand side of the screen, there is a Print button to enable the user to generate an output of the application in PDF or in print. The Focal point information, date and signature are mandatory and should be completed before submission of the Application. By clicking the Submit button, the user releases the application for review and assessment of the UN Entity. Click the button Submit when the Application is ready to be sumitted for approval. Note the message at the lower left side of the screen. This will indicate that the application is being saved and processed for submission. Once submitted for approval in the workflow, a confirmation message will be displayed. When the application is saved or submitted (without saving it first), an Application Number is autimatically generated by the system. The IP/EB needs to make a note Page 44 of 114

45 of the application ID for future reference. Once submitted, the IP/EB can no longer make changes to the application as this has been moved to the workflow for review Printing the Application The IP/EB or the Program Assistant who created the Application can print the Application Form by searching the Application (not the Form). On the Application object, the IP/EB clicks on the Application Form and then, clicks the Print Application button (beside the Edit icon). The next screen shows a PDF copy of the Application which can be generated from the printer or can be saved as a PDF form. Page 45 of 114

46 4.4.3 Selection Review of the Application After submission of the Application, the status changes to Selection Review. At this stage, several rounds of reviews are made for each Application until the determination is made to award the grant to an IP/EB. The steps being followed by the approver when approving the Application in the system, are the same for different levels of approval. However, the levels of approval vary according to the UN Entity business process. In UN Habitat, for example, a Program Assistant reviews the Application submitted by the IP/EB in UN Habitat. In case a Program Assistant creates the Application on behalf of an IP/EB, another Program Assistant (not the creator of the Application) reviews the Application to comply with the segregation of duties policy. This may not be the case in other Entities where the Program Officer reviews the Application after submission of the Application. In addition, Applications over $200,000 are approved by the Regional Committee whereas Applications over $500,000 are reviewed and approved by HQ. To illustrate, following are the levels of approval for UN Habitat Applications Application Status Workflow Level Role L1-L1 Program Review Program Assistant (GR.01) L2-L2 Program Review Program Officer (GR.02) Selection Review L3-L1 Financial Review Certifying Officer (GR.07) L4-L2 Financial Review (0-200K) DOA (GR.06) L4-L2 Financial Review ( K) Committee (Regional) (GR.11) L4-L2 Financial Review (501K+) Committee (HQ) (GR.11) For your specific Entity, refer to the Annex 2.3 to familiarize with the different levels of approval to find your bearings in this system. Note that regardless the number of the approval levels, the Application stays in status Selection Review during the application selection process. Once the last reviewer approves Programmatic Review This review and approval focus on ensuring that the IP/EB has selected the correct Grantor Program, that the submitted application is duly completed and that all required project information are attached to the Application. If additional information is required from the IP/EB, the Approver has the Return option to send the document Page 46 of 114

47 back to the IP/EB. It is a must to ensure that contents of the Application comply with the UN Regulations and Rules and the Entity policies. Financial Review This review and approval focuses more on the financial aspects of the project particularly the amount being requested, the amount being contributed by the IP/EB (if any) and the details in the Project Budget Proposal. It entails a scrutiny of the supporting calculations and the justification for the proposed PSC rate and requested project costs. (PSC rate must comply with UN Entity guidelines.) The Certifying Officer conducts this review to ensure that the submission of budgets and related supporting documents are in line with UN Financial Regulations and Rules (UNFRR) and UN entity procedures and guidelines. He/she communicates to the IP/EB to provide sufficient information to support the budget. (The supporting documents uploaded by IP/EB are available in the attachment section.) The following steps to approve in workflow are the same all throughout the Grantor Management process. Please refer to these steps when approving a document in workflow. a. Log into CRM and click on Worklist. b. Click on Associate Business Object to review the application. This allows the Approver to access all the details related to the Application. c. After reviewing the Application Form, click on Back button on the right top corner. The screen will get back to the worklist. Click the Application ID no. under the column Subject to go to the Decision screen. d. On the next screen, select the appropriate action Approve, Reject or Return and execute the decision. Approve - moves the process to next stage, Page 47 of 114

48 Reject - drops the request from workflow, Return - sends back the request to the previous user. e. The task is removed from from the worklist once the decision is executed. f. It is recommended that the Approver checks the Application status through Applications> Grantor Applications. Search with the Application ID to ensure that the application does not contain any error. Page 48 of 114

49 4.4.4 Errors and Notes Error Messages If there are any errors, those will appear on the top right corner of the screen.errors with red icons are hard errors which mean the transaction cannot proceed. The PO can click on the red icon to read more details about the error. The error(s) must be resolved first before the application can move to the next level of review. Notes: Before creating an Application, the IP/EB must register with the UN Entity to ensure that their profile has been set up in the BP master data and their Contract is set up in the CRM/Grantor. (BP Creation and update of contact details is done by the MDM Team. It is critical to provide the correct Grantor Program (GP) ID and GP Description. It allows the IP to select the appropriate GP in their application. When publishing the Call For Proposal/ allocation strategy, the UN entity needs to clearly highlight the GP ID. If any changes are required after completion of review process, the PO is allowed to make the necessary changes. 4.5 GRT_L305 Post-Application Approval This process is related to the creation of Business Partner for those Applicants that were created as prospects in CRM for selection review and for whom this selection review was successful. Upon selection, BP is created and maintained in ECC and sent back to CRM for duplication check and merge. This functionality is planned for a future release. 4.6 GRT_L306 Negotiations on Grantor Agreement This phase entails indicating the account assignment in the selected Application, negotiating with the IP/EB, drafting the agreement and reviewing/approving the draft Agreement prior to printing the final hardcopy of the Agreement. At this time, the status of the Application is Under Negotiation. Certain sections of the Application such as the Editable Fields for the different Agreement template, the Miscellaneous Provisions and the Bank Details now appear in the Agreement object. Harmonized/standardized templates, reviewed by the Legal Office (OLA), were created in the system for the following types of Agreements: Agreement with External Parties Agreement with a UN Agency Page 49 of 114

50 Agreement with an Entity within the Secretariat The templates can be used for both IP and EB. These can be printed at any time to facilitate the compilation of the data needed for the Agreement. Since the template document cannot be edited directly, Umoja has mapped fields from the Application form, the Application object and the BP master record. Where the paragraphs/sentences require an input, Umoja has created editable fields in the Application object. These fields are referenced to the Agreement template with the appropriate Article or Section number, so the user knows exactly where the information being typed will be reflected in the Agreement. The user is expected to complete the editable fields, review and select the bank account (if there are multiple bank accounts) and enter the special clauses (Miscellaneous Provisions) before generating the Agreement again for review and for signatures. Mapping Fields from the Application form such as Institution Name, Type of Institution, Date of Establishment, Place of Registration, etc. to the Agreement template have been mapped to the Agreement. Likewise, information from the BP and the Application object (e.g. dates) are mapped to the Agreement. Editable Fields These fields were configured to provide a place for the user to input the information required in the Agreement. There are different Editable Fields tabs according to the type of Agreement selected. The specific tab will only appear after the user has indicated the type of Agreement applicable to the IP/EB, on the Application Details tab. An example of these fields is the Project Objective as required in Article II 5 of the Agreement. On the Application object tab for Agreement with External Parties, you will see Art. II 5. Project Objective, with a box where the user can type in the rest of the required sentence. Special Clauses (Article VII Miscellaneous Provisions) Article VII Miscellaneous Provisions in the Agreement for External Parties is reserved for special or non-standard clauses. The tab is currently labeled as Miscellaneous Terms but please note that this will be changed to Miscellaneous Provisions to align with the title of Article VII. Enter all special clauses here, if there are any. If you don t have special clauses, leave this tab blank and the system will enter Not Applicable beneath the title. If there are special clauses, click the box in the tab which serves as an indicator that the special clauses need to be routed to Legal Review in the Workflow. We will be removing this box in the future as entering data in the tab should be a sufficient indication that the workflow should be routed to Legal for review. Page 50 of 114

51 Bank Details Note that bank details are required in the Agreement. The Application has a tab specifically for the bank details where the Program selects the specific bank account where the funds would be deposited. Annexes The Agreement with External Parties includes the following Annexes: a. Annex A - Terms and Conditions b. Annex B Project Information (output is still in progress) c. Annex C Project Budget Proposal (output is still in progress) d. Annex D Payment Schedule Annex A Terms and Conditions is a document that cannot be edited. The content, as mentioned earlier, has been reviewed by OLA and all paragraphs are static. This is already included in the template. Annex B Project Information is an output from the Project Information of the Application form currently work in process in Umoja. Included in Annex B is the Project Log-frame that the Entity s office is supposed to compile manually and should be attached to the Application Object. Note that the Project Log-frame is NOT AN OUTPUT from the Grantor system. Annex C Project Budget Proposal is an output from the Application form, but development is ongoing. Annex D Payment Schedule is an editable field and included in the tab. Type Due Date and Amount as column labels to enter the specific due dates and amounts. The Negotiation process is managed and completed by the Program Officer by performing the following tasks as described in steps 1 through 9. It is recommended that steps be followed in order. Note that Process Steps 1, 2, 3, 6, 8, and 9 are mandatory steps and need to be performed in all cases. Process steps 4, 5 and 7 are optional and depends on the situation. Adding non-standard clauses trigger one more step in workflow for Legal Officer review and clearance. In this case, workflow will be diverted accordingly. Page 51 of 114

52 S.no Process Steps Required Role 1 Enter Account Assignment Program Officer (PO) 2 Generate Proforma Contract for Program Officer (PO) negotiations 3 Enter and change editable fields Program Officer (PO) 4 Add non-standard clauses Program Officer (PO) 5 Change the amount of the Proforma Program Officer (PO) Contract 6 Change the dates of the Proforma Contract Program Officer (PO) 7 Attachments additionally submitted Program Officer (PO) 8 Generating Finalized Proforma Contract Program Officer (PO) and Attach 9 Program Review and approval in Workflow Program Officer (PO) Enter Account Assignment in the Application: Before entering the Account Assignment, ensure that the budget for consumption is issued for the Grantor Program and in particular activities (WBS elements) that are part of the Account Assignment on the Application. Please ensure that there is sufficient funding and available cash as well. Account Assignment is a coding block that is required for financial and budgetary postings. By entering the Account Assignment, you ensure that the integration with financial and budgetary modules in Umoja is established. The Account Assignment defines the funding for the Application/Agreement. The funding can come from different sources: Voluntary Contributions recorded in Grants Management (Fund 32) Voluntary Contributions unearmarked (Fund 40) Peacekeeping fund (Fund 20) Regular Budget Funds (Fund 10) It is important to know that in Grantor Management only projects, i.e. WBS elements (projects) are used. Thus, for all above funding, the project has to be created. If Account Assignment is funded by Grants from Voluntary Contributions, only the WBSE element has to be entered. If the Account Assignment is funded by other sources both, WBSE and Fund have to be entered. Page 52 of 114

53 Note that there might be multiple Account Assignments on the application/agreement. The percentage must be assigned to each Account Assignment with the total Account Assignment lines equal 100%. To enter the Account Assignment in the Application: a. Log into Grantor Management. b. To search Application, click on Applications and Applications under Search. c. Enter Application ID number, and then click Search. This displays the search result. Click on Application ID. d. On the Application object screen, locate the Multi-Funding section, click Edit, enter the WBSE and the percentage. If there are multiple WBSE, click Inset Line and enter the info accordingly. Total percentage (%) should be 100%. e. The Indirect Cost Rate reflected on the right side of the Multi-Funding Rule is the Program Support Rate stipulated in the Donor Agreement with UN and reflected on Main Implementation or Simple Grant against the Sponsored Classes for Direct Cost of the IP. This is a change from the Foundation solution where the rate represented only the UN portion of the PSC. Page 53 of 114

54 f. Click Check Lines and if there are no error messages, proceed by clicking Save Rule. Please ensure that you do not click Delete Rule and Add Condition icons. g. Click the Back button and SAVE the Application. Page 54 of 114

55 4.6.2 Generate Proforma Contract for Negotiations During this process the appropriate agreement type will be selected, and a draft Proforma contract will be generated for review purpose. This is an initial agreement template which requires additional input from the Program Officer. (The final agreement will be generated after entering specific information, contact details, payment schedule in the Editable fields, bank details, implementation dates and Miscellaneous provisions, if applicable. Note that the processes below can only be performed when the status of the Application is Under Negotiation. It is only in this the status that certain fields appear on the Application such as the Proforma type, the Editable fields, Bank details and Miscellaneous Provisions appear. a. Search the Application by entering the Application ID number (*XXX) and on the Result List, click on Application ID. b. Click Edit in the application details and select the appropriate Proforma type. The proforma type defines the type of contract/ agreement that will be generated by the system depending on the nature of the IP/EB. If the IP/EB is other than a UN agency or a UN Entity within the UN Secretariat, the appropriate proforma type is the Agreement with External Parties. The two Page 55 of 114

56 other proforma types are Agreement with UN Agency and Agreement with Entity within the Secretariat. c. Save the application details. d. To generate the Proforma contract, click on the button With Template. (if the button With Template is greyed out, you have not saved the Application. Go back and save first.) This opens a new window of the PDF version of the Agreement type that was selected previously. In the example below, the Agreement UN Agency to Agency was selected. This template will be generated by Grantor Management system. e. The next screen shows the PDF document of the template. At this point, the user has the option of printing the template (locate the printer icon on the right side) or saving a PDF document on the user s hard drive. Page 56 of 114

57 f. Go back to the system by closing the screen above then close the pop-up box that appears (shown below) to get back to the Application screen. g. Once you are back to the Attachment section, note that the system generates a file. Note that the most recent file is always the first file on the list Enter and change editable fields a. Click the arrow to expand the editable field for the specific pro-forma type of Agreement. In our example, the pro-forma type selected is the Agreement with External Parties. Click the Edit button to show all the editable fields. The system then shows a series of boxes with references corresponding to the Articles/sections in the Agreement that require input from the user (Program Officer) before the agreement can be finalized. Refer to the specific Articles/sections in the Agreement if the editable field is not clear. Page 57 of 114

58 b. Enter the required information in the fields to complete the text in the respective clauses of the agreement and annexes. These are mandatory fields and the information appears in the agreement accordingly. At this point, the Program Officer liaises with IP/EB to get the details for operational, financial and signature details and enter the information accordingly. Enter Schedule of payment to reflect the installment in Agreement as Annex D. Editable Fields for the different Proforma Templates: 1. Agreement with External Parties Shown below in the screenshot are the editable fields for this type of Agreement. Article II 5 Complete the sentence The Project, which is decsribed in a more detailed manner in Annex B, hereto, aims at. Article III 2 Complete the sentence Cooperating Entity is committed to the objective of Page 58 of 114

59 Article VIII Enter the details of the focal points for UN and Cooperating Entity Operational and Financial and Policy Matters Article XI Enter the names of the Signatories (for the Agreement) and their titles. Annex D is the Payment Schedule. The header should be Instalment no, Due Date and Amount. Because this is a text box and the BSP program that CRM uses has limitations, align your columns accordingly. 2. Agreement with UN Agencies Screenshot below shows the editable fields that need input from the user. Summary of Activities enter the description for the following fields that are required in the Agreement: o Nature of Activities o Purpose o Expected Outcome Reporting enter the Report Name, Report Coverage and Due Date Contributions has the same format as Annex D Payment Schedule for Agreement with External Parties. Enter the Instalment no., the Amount and the Due Date Correspondence enter the address for both the Contributing Agency (UN Entity) and the Recipient Agency (Cooperating Agency) Page 59 of 114

60 3. Agreement for UN Entities within the Secretariat Exchange Letter Salutation This editable field is intended for the name of the Executive Officer in the Recipient Entity. Exchange Letter Complimentary Close This editable field is intended for the name of the Executive Officer signing the Exchange Letter from the Contributor Entity. Exchange Letter Date Enter the appropriate date for the Exchange Letter Section VI 20. Substantive and Financial Reporting Date Enter the date when the Recipient is required to submit the final substantive and financial statement. Section V Financial Arrangements This is the Payment Schedule. Please enter Instalment no., Due Date and Amount. Section VI Reporting, Audits and Evaluation Enter the Report Name, Due Date and Period Covered *Note. There is a second section for the editable fields for UN Secretariat. Expand this section and click Edit. Section III Coordination Designated Points of Contact - Enter the names of the designated focal points for the Contributor and the Recipient in these fields. Page 60 of 114

61 4.6.4 Enter Bank Details Review the Bank Details if the information provided by the system is correct. If there are several bank accounts, select the appropriate Bank ID. The rest of the details are derived from the BP master data and cannot be modified. If there is a new bank account to be added, please follow the usual process of completing the appropriate form (F.249) and submitting to Treasury to establish banking details Add non-standard clauses a. Go to the section Miscellaneous Provisions and click Edit. b. Ensure that the Misc Indicator box is turned on (selected) to route the document to Legal office for the review of the nonstandard clause. c. Type the additional (non-standard) clauses Change the amount of the Proforma Contract a. On the Application Form, click Edit and go to Project Budget Proposal section to make the changes in the Project Cost Plan and PSC rate. Page 61 of 114

62 b. Make the necessary changes in cost plan and PSC rates and click Back Change the dates of the Proforma Contract a. Enter Agreement implementation start and end date, Operational closure, Finanical Closure and Expiry dates. Note that the entered dates should be within the grantor validity date. Signed date will be entered based on the actual agreement signature date which can be completed only after signature of the agreement. Page 62 of 114

63 4.6.8 Attach additional submitted documents If there are any additional attachments related to the application have been submitted, upload the files in the attachment section. a. Expand the Attachment section and click Choose file to upload the doc. b. Remember to save the Application object as necessary Generate Finalized Proforma Contract During negotiation, the Program Officer makes the necessary changes in the dates, amounts and other details in the Application. Once the negotiations are finalized and changes are completed, the Program Officer generates a final version of the Proforma Agreement confirming that: Negotiations for amount and dates are complete Editable fields are complete Banking detail have been reviewed for accuracy Special clauses (non-standard clauses) are complete. It is also important to check if the Account Assignment is entered in the Multi-Funding Section of the Application, although Account Assignment is not reflected in the Proforma Contract. a. Scroll down to the Attachment section Page 63 of 114

64 b. Click With Template. A new window displays the agreement in Pdf. c. At this point, the user can print or save the output file in the local drive. Find the pop-up box (see below) and close it (If you don t find on your screen, minimize it and this pop-up box will appear. Close it to continue. d. Next, check that a PDF file is generated as an attachment with the Name "UN_IP_PROFORMA (for agreement with external parties). The first one on the list is the most recent copy. Page 64 of 114

65 e. Save the Application Generating the Annexes To generate the Annexes, click on the section for Attachments and click the button Attach Annex as shown below. The Annexes are generated as a file and attached. For the Agreement with External Parties, the annexes generated are as follows: Annex A General Terms and Conditions (standard template) Annex B Project Information (generated from Application) Annex C Project Budget Proposal (generated from Application) Other Annexes Note that Annex D Project Logical Framework is not generated by the system since it is created manually and attached to the Agreement. Likewise, additional annexes are identified through the editable field and attached manually. Page 65 of 114

66 Program Review and Approval in Workflow When the draft Agreement has been finalized, the Program officer submits the Application to the workflow for further approval. The Program Officer then selects the appropriate action Approve, Reject or Return and execute the decision Agreement Review (based on UNMAS Example) After completion of negotiation by Program Officer, the application status is moved from "Under Negotiations" to "Agreement Review". This stage is entity specific and each entity might have different number of approval levels during Agreement Review. The example below is the Agreement Review process in UNMAS. Each entity has to check Annex 2.3 for specific their specific process. Although the number of approval levels differs from entity to entity, the Agreement review in general consists of: Legal review of the non-standard clauses. This level is optional for all entities and will be skipped if there are no non-standard clauses. Programmatic Review Financial Review Final Approval Each of this review stages can have more than one level of approval or skipped completely, with exception of Legal Review and Final Approval. It is important to know that for the Legal Review, the workflow will route the document to the Legal Officer for review of the additional clauses captured in the agreement only if the Miscellaneous Provisions indicator is turned on. Page 66 of 114

67 As stated above, Agreement Review vary from Entity to Entity. UNMAS applications, for example, are reviewed by a Senior Program Officer after a Legal officer has reviewed it, assuming there are special (or non-standard) clauses in the Agreement; otherwise, the flow would have been from Program officer to Senior Program Officer. Application Status Process Step Role L6-L1 Legal Review of non-standard clauses Legal Officer (GR.08) L7-L3 Prog Review Sr. Prog Officer (GR.03) (UNMAS only Agreement Review L8-L2 Financial Review Certifying Officer (GR.07) L9 - L3 Financial Review Sr. Finance Officer (GR.05) UNMAS only L11 - L5 Final Approval Committee (Controller) (GR.11) Legal Review of non-standard clauses As mentioned earlier, the process will be diverted to legal review when the program officer enters non-standard clause(s) in the agreement and marks the box Misc. indicator. This is an optional process step, which is only required when there are non-standard clauses to be added to the agreement. When using the standard agreement, there is no need to go through the legal review process. To review the Miscellaneous Provisions, log into CRM click Worklist. a. Click on Application number under Associate Business Object. b. Expand the Attachment section and download the latest version of the UN Proforma agreement. (The most recent copy is the first one on the list. This can be verified by checking the date of creation date and time. Page 67 of 114

68 c. Review the Miscellaneous Provision and its legal implications to the project and to the UN. d. Click Back to exit the Application and get back to the main Worklist screen. Click the Application link under Subject e. Select the appropriate action, Approve, Reject or Return and execute the decision. The task disappears from the list once the decision is executed. Second Program Review (UNMAS only) Programmatic Review For UNMAS, additional review by a Senior Program Officer is required in Grantor Management. This process is applicable only for UNMAS. Follow the steps for Workflow Approval outlined in Annex 2.3 for your entity. Page 68 of 114

69 Financial Review After legal review and the additional Senior Programme Officer review, the Certifying Officer reviews the Agreement in UNMAS. Follow the steps for the Workflow Approval outlined in Annex 2.3 for your entity Financial Review by Senior Finance Officer As indicated earlier, this workflow step is applicable to UNMAS only. The Senior Finance Officer of UNMAS to logs into the system and approves following the workflow steps outlined Annex 2.3 for your entity Final Approval This is the last stage of agreement review. For UNEP and UN HABITAT, the Account Officer completes the Final Approval. For UNMAS, the Controller s Office completes the final approval. At this point, the system changes the status of the application form Agreement Review to Awarded. It is recommended to check the status after approval from the worklist. This can be done by Clicking into Application> enter Application ID> Click Search. The status will be shown in the result list Application Errors and Notes When assigning the WBSE, ensure that it is correct, and that sufficient budget and cash are available. Page 69 of 114

70 Once the review process is completed and moved to the negotiation stage, the Program Officer makes changes to the Application if necessary. Special attention is required when selecting the proforma type of Agreement. An incorrect selection generates the wrong agreement which could have financial and legal impact. Annex D - Payment Schedule is completed in line with UN Entity policies. There are various practices across UN entities in calculating the number and amount of installment. Generally, it takes into consideration of the project s cash availability, duration, risk level and budget. For Release 1, agreement files and supporting documents are available in the Aplication object. These documents are currently not available in the Agreement object. There is no workflow to send the document for signature to IP/EB. The Program Officer needs to send the Agreement and related annexes to IP/EB in the same manner that agreements are shared today (e.g. via ). 4.7 GRT_L307 Signing of Grantor Agreement Generate Grantor Agreement The Program Officer generates the Grantor Agreement in the system. This is done after the Application has gone through the workflow for Agreement review and is now in status "Awarded". The Program Officer should get the Agreement signed by both parties and attach the signed copy (PDF) to the Application object. a. In CRM, click Application> Applications under Search. Enter the Application ID in the Search Criteria and Click Search. b. Go to the Section for Attachments c. Expand the Attachment section of the Application and click the final copy of agreement named as UN_IP_PROFORMA if it is an Agreement for External Parties, UN_AG_PROFORMA for Agreement with a UN Agency and UN_Secretariat Proforma for Agreements of UN Entities within the Secretariat. The pdf agreement will open in a new window. Download the Agreement, the Annexes and related supporting documents by using the Print option on the PDF screen. Page 70 of 114

71 d. The Agreement hardcopy is then signed by the UN Entity (represented by the officer with the delegation of authority). At this point, the Agreement is ready for third party signature and is shared by or other document sharing option. The Program Officer scans a copy of the hardcopy signed agreement when received from the IP/EB. Attach the signed copy of the agreement and other related documents by clicking Choose Files and Upload buttons. e. Once the signed document is received from IP, the Program Officer updates the signature dates in the Application object. In CRM, go to the Application object and expand the Dates section. f. Enter the signature dates into the indicated fields by clicking on the calendar icon. g. Enter the Financial Closure date (the end of the Opearational Closure period establisished in your entity). h. Save the Application object. After the signed hardcopy of the Agreement has been uploaded to the system and the signature dates have been updated in the Dates section fo the Agreement object, the Agreement can now be created/generated in the system. Click on Create Agreement on the menu (located on the upper part of the screen). Page 71 of 114

72 The screen changes to Agreement: New. SAVE the Agreement. This action finalises the Agreement process and displays the agreement ID on the upper part of the screen and indicates the number in the Transaction History. 4.8 GRT_L308 Budget Consumption of Grantor Agreement The amount that will be consumed by the Grantor Agreement will be established during the Funding is set aside for Grantor Agreements through a Released Budget for consumption in ECC (Funds Management/Grants Management). This process is done outside of Grantor Management system. Note that if this step is not followed, a Funds Commitment could not be generated in ECC upon approval of the Fund Certification. Page 72 of 114

73 4.9 GRT_L309 Fund Certification of Grantor Agreement At this point the agreement hard copy was signed and uploaded in the Application object, Agreement object was generated in CRM, the budget for consumption was established in ECC. The next step is to create and approve Funds Certification document that will obligate or commit the funds for this Grantor Agreement. The user might choose to create the Funds Certification for the total amount of the Agreement. However, the Funds Certification amount should be up to the level of cash received by UN. Note that the policy is currently under review with respect whether to issue the Funds Certification for the full amount or up to the cash received. Funds Certification is a transactional object in the system, once approved, it will result in creation of the Funds Commitment in FM/GM ECC that will encumber (obligate or commit the funds) Create Funds Certification Document The Funds Certification Document is created by the PA. The Funds Certification in Umoja utilizes the Change Request functionality. As in the case of Application, there is a form for Funds Certification, the object for Funds Certification is generated in CRM and the Earmarked Funds documents are generated in ECC (Funds Commitment) where the obligation and consumption postings are recorded. The form is an integral part of the object. a. To create Funds Certification in CRM, click Agreements> Change Request Forms b. Enter the Agreement ID, against which you need to commit funds, in the search criteria and click search. Click on Fund Certification blue link in Change Request Form column. Page 73 of 114

74 c. This opens the Fund Certification Change Request Form screen. Complete the column New Authorized Amount based on available cash and budget in ECC. This process reserves the funds specifically for the Grantor Agreement. In Section II, the Agreement Amount is defaulting from Agreement, Authorized Amount is defaulting from existing Funds Certification document (if a prior one was already created and approved). In the screen below, there are zeros in this column as no prior Funds Commitment exists for this agreement yet as we are creating the first one. Enter amounts in the New Authorized Amount column for the first Funds Certification Document. Enter additional details in Section III Notes/Comments section. Upload supporting documents related to the Fund Certification on Section IV: Supporting Documentation. Click Choose File and Upload. Page 74 of 114

75 d. After completing all the details, submit the Fund Certification Request for approval. The system then generates a confirmation of the submission and the request is now moved to the workflow for approval Workflow and Approval for Fund Certification After the Fund Certification is submitted, it goes to the workflow for review and approval. The workflow levels for Fund Certification are as follows: Entity in Release 1 has the same levels of approval for Funds Certification document. Please refer to the workflow steps outlined In Annex 2.3 to approve the Fund Certification in the system. Page 75 of 114

76 The steps for approval of the Funds certification is the same as any other transactional data document in CRM. Once the Fund Certification is approved, two Earmarked Fund Documents are generated by the system in ECC: one for Direct Cost (total amount of itemized expenses) and one for Indirect Cost (amount is calculated by multiplying the PSC rate against the Direct Cost). This can be viewed through the Agreement Transaction History. To view this, go to Agreement> Agreements and search the Agreement ID. Click in the agreement number and expand the Transaction History. Note the Earmarked Fund Documents for Direct and Indirect Costs. Click the Earmarked Funds Document item number to display the Funds Commitment details in ECC. The screenshot below shows a Funds Commitment as a result of drilling down in the Earmarked Funds in the Transaction History of the Agreement. There is no need to go to ECC to display a Funds Commitment. Page 76 of 114

77 4.10 GRT_L310/GRT_L311 Life Cycle Execution of Grantor Agreement The life cycle execution is similar for both IP and EB process. It consists of several steps: 1. The money is paid to the UN Grantee via Payment Request 2. The UN Grantee reports the expenditures via Claim or Statement of Income and Expense 3. Based on the agreement terms, steps 1 and 2 can be repeated until the final payment is done by the UN and final report is received from UN Grantee. 4. In some cases, the Grantor Agreement is Amended for extension of the project duration, an increase in value, change in bank account or the outcome/outputs/activities on the Project Logical Framework Payment Request Payment Request the transactional data in Grantor Management to process payment or disbursement to the End Beneficiary or Implementing Partners. In Grantor Management, the Change Request functionality is used for Payment Request. As in the case of Application and Funds Certification, there is a form for Payment Request and the object (for Payment Request) is generated in CRM upon approval. The form is an integral part of the object. Once approved, a Grantor billing document is created which is posted in ECC through a batch program. The document that is posted in ECC is an invoice and the accounting document is posted debiting Advance (if the Program type is IP) or Expense (if the Program type is EB) and crediting Accounts Payable. The levels of approval for the Payment Request and its creation are the same for all three entities in Release 1. It is created by the PA. Payment Requests are made in accordance with Annex D - Payment Schedule. The Program Assistant creates a payment request for the advance amount required for Direct and Indirect Cost. If the Program Type is IP, the payment is recorded as an advance and is liquidated when a Claim (Statement of Income and Expenses) is Page 77 of 114

78 submitted. A payment request to an EB is recorded as expense immediately. The Payment Request is always processed at the summary level, i.e. IP/EB Direct and IP/EB Indirect Cost expense type, and the amounts are validated against the authorized amount in the Funds Certification. In other words, you cannot pay more than you committed Payment Request Creation a. In CRM, click Agreement > Change Request Forms> Enter Agreement ID then Click Search b. Click Payment Request blue link in the column Change Request Form c. On the Payment Request Form, select the appropriate payment method based on the Payment Method Quick Guide ( Refer Annex 2.2). Select the Bank ID as per the bank informaiton provided in the Agreement. The field Page 78 of 114

79 for UNDP partner is filled in if the payment is to be made through UNDP. The next paragraphs explain the steps for a UNDP Financial Authorization. The Approved Amount is defaulted from the Agreement, the Authorized Amount is defaulted from the Funds Certification and Paid Amount is only reflected when a prior payment has already been made. As this is the first Payment Request, Paid Amount has zero values. The Baseline Date indicated in the Payment Request becomes the due date of the invoice unless the BP master data has a payment term, in which case, the due date is recalculated based on that payment term (e.g. if payment term is 30 days, the due date becomes 30 days from the baseline date entered in the payment request; in the example below, idue date is because baseline date is ) d. Complete the Advance request by entering the amount in the New Requested Amount columns. Notes and attachments can be uploaded in Sections III and IV. Keep the default (current date) for the Baseline Date. Submit the Payment request by clicking the Submit button. The system then generates a confirmation of submission. Page 79 of 114

80 Payment through UNDP Financial Authorization Some UN Entities utilize the services of UNDP as a pay agent. If there are payments to be made via UNDP Financial Authorisation, follow the same steps to create a Payment Request as stated in the previous paragraphs. a. Select payment method U-UNDP Pay Agent. b. For the UNDP Partner field, select the UNDP country office that is going to process the payment to the IP/EB by clicking on the dropdown list. A UNDP Country office can only make the fund transfer in the same country; therefore, the IP/EB bank account should have been maintained in the same country as the UNDP Country Office. c. Enter the advance request in the New Request Amount and submit the Payment Request. The system generates a confimation indicating the submission number. Page 80 of 114

81 After completion of the Payment Request approval, the Accounts Officer proceeds to issue the Financial Authorisation, the payment is processed through the UNDP process instead of the bank transfer Payment Request Approval-L1-PO After submission of the payment request, the Payment Request goes into the workflow and appears in the Program Officer worklist. The Program Officer then logs into the system and approves the Payment Request. The workflow is outlined in the Annex 2.3. The steps for approval are exactly the same as for any other document in CRM. a. Once decision is executed, the task will disappear from the list. The status of the request changes to Financial Certificaiton. b. To check if there are any errors in the Payment Request, go to Agreement> Change Request, enter Agreement ID number and click Search. c. Click on the Payment Request (Change Request ID) Page 81 of 114

82 d. If there is any error, it will be indicated with a red icon on the top right side of the screen. Common are errors aredue to insufficient budget, insufficient cash in the WBSE or the grant validity period in ECC Payment Request Approval-L2-CO After programmatic review of the payment request, it goes into the workflow and appears in the Certifying Officer worklist. The certifying officer pays attention to the amounts stated in the Payment Request and checks if they are within the authorized amounts, a. Certifying Officer log into the system and Click Worklist b. To view the payment request details, click Associate Business Object and back button to back on worklist. c. Select the Appropriate Decision (Approve, Reject and Return) and Execute Decision. d. Once decision executed, the task will disappear from the list. The status of the request will be changed to Financial Approval Payment Request Approval-L3-AO After Financial Certification, the Payment Request goes into the workflow and appears in the Account Officer worklist. a. Log into the system and click Worklist b. To view the payment request details, click Associate Business Object. After your review, click the Back button to get back to the main screen of the worklist. c. Select the appropriate decision (Approve, Reject and Return) and Execute Decision. d. Once the decision is executed, the task will disappear from the list. The status of the request will then be changed to Awarded. Page 82 of 114

83 e. After approval of the Payment Request, the system automatically generates a Grantor Billing Document in ECC. The Grantor Billing Document number appears in the Transaction History of the Agreement. If the Grantor Billing Document is not available; there may be an error. The Accounting Officer needs to go into the agreement and check if there are any error notifications on the right top corner. The Grantor Billing Document is automatically included in a batch that is posted automatically in ECC as an invoice as it has already been approved in CRM. Subsequently, the Treasury payment run includes the invoices (payable document) and disburses the payment to the IP/EB. The same steps are followed in processing the first and all subsequent payments Payment Request Notes Notes: Payment request steps remain the same in all scenarios. UMOJA sends Financial Authorization to the concerned UNDP partner and a copy is obtained by the Account Officer for payment to be made via UNDP-FA., The advance amount cannot exceed the Authorized Amount (Funds Commitment amount). The alert system will be developed in Grantor Management Module to notify the concerned user regarding the payment status. Page 83 of 114

84 Expense Report Claim is the transactional data in Grantor Management that is used to record Expense Report, also called Statement of Income and Expense. The Agreement requires IPs to report expenses so that the advances paid by the UN Entity are consequently settled and the appropriate accounting entries to offset the advances are recorded in CRM and posted in the General Ledger. EBs on the other hand, are also required to provide the UN Entity a report of the expenses incurred as per the current Agreement with External Parties template although the payments are processed as expenses. Note that payments to EB are recorded as Direct and Indirect costs. The Claim when posted, will offset (credit) the Direct and Indirect Costs with the detailed expenses such as Staff Cost, Travel, Operating Expenses, etc. The Agreement also requires Narrative reports regarding the progress of the project to be submitted and these can be attached to the Claim together with the IP/EB s Expense Report Creation of the Expense Report The IP/EB logs into the system to complete the Claim. The Program Assistant may also complete and submit the Claim on behalf of the IP/EB. Statement of Income and Expense (Expense Report): Agreement Status Process Step Role Create Expense Report Program Assistant Awarded Approve Expense Report Program Officer Approve Expense Report Certifying Officer Approve Expense Report Accounts Officer a. IP/EB log into the system: b. Click on Claims and click on Claim Forms under Search c. Enter Agreement ID, click Search and click on Claim Form Statement of Income and Expenses Page 84 of 114

85 d. Enter the last day for the transactions for the reporting period on the field For the period ended (cut-off date). If this is a second reporting period, report expenses from the last cut-off date.. Please do not select any future dates. e. All grayed out information are derived from GRANTOR MANAGEMENT MODULE data. f. IP/EB must report interest separately on the appropriate fied and any other type of income related to the UN grant such as foreign exchnage gain on the Other Income field. g. Note the Agreement amounts on the first column and the Reported Expenses on the second column. In this example, there are no prior expenses reported, so the values are all zero. h. If the total amount being reported is more than the total advances, the system will generate an error. Instructions on how to resolve the error is provided in the succeeding paragraphs (following the approval of the i. Enter the expenses under the column Current Expenses in Section II B. Details of Expenses. Claim). j. Indicate if this report is final claim. Page 85 of 114

86 k. Provide additional information relevant to the Claim under the Comments section If there is a a Payment Request to be made while submitting the claim, IP/EB can indicate the 2nd or subsequent tranche by making the request on the Comments section. l. Documents related to the Claim can be submitted through the Attachment section. Click Choose File and upload the relevant document. m. When ready, press the Submit button. n. After submission, the system generates the Claim number. IP/EB then makes a note of the number for future reference. Page 86 of 114

87 o. Upon submission, the status of the Claim changes to Program Review Expense Report Approval Program Review After submission of the Claim request, it moves into the workflow and appears in the Program Officer worklist. a. Log into the system b. Click Worklist. The Claim submitted by IP/EB appears in the workflow Tasks. c. To view the Claim request details, click Expense Report under Associate Business Object. d. Review the Claim details: Ensure there is a sufficient advance balance to cover the expense reported. Program Officer can simply approve the claim when the advance is more or equal than the expense being reported. Page 87 of 114

88 In cases where the IP/EB submits a Claim with expenses more than the advance, follow the recommended steps in the succeeding paragraphs. e. If there are any changes to be made in the Claim form, the Program Officer clicks on the Edit icon on the Claim Form and saves the changes after completion. The Program Officer can also return or reject the Expense Report. Return will move the document back to the IP or the Program Assistant who created the Claim. Note that Reject will invalidate the Claim and will remove the document completely from the workflow. This means that a new Claim would have to be created. f. After corrections are made, the Claim is now ready for approval. The error encontered earlier has disappeared. g. To go back to Worklist, click the Back icon to get back to the main screen. Page 88 of 114

89 h. Select the Appropriate Decision (Approve, Reject and Return) and Execute Decision. i. Once the decision is executed, the task will disappear from the list. The status of the request is changed to j. It is strongly recommended that the Program Officer checks to see if there are further errors on the Claim. This can be done through Claims> Claims under search. Enter Claim ID and Search. The user status changes to Financial Certification. Click on Claim ID and note any error on the right side of the screen. Page 89 of 114

90 Financial Certification The Certifying Officer logs into the system to approve the Claim. He/she ascertains that the supporting documents to the Claim are complete and that amounts are accurate. Further review is done on the supporting documentation before approval. Refer to the steps for approval outlined in Annex 2.3. To proceed to the next level in the workflow, the Claim document should not have any errors. If there are errors in approval, a red icon appears on the top right sideof the screen. One cause for the error is insufficient advance to cover the expense amount reported on the Claim. As mentioned earlier, if this issue, follow the instructions in the succeeding paragraphs. Financial Approval After Financial Certification approval of the Claim, it goes into the workflow and appears in the Account Officer worklist. He/she reviews the amounts on the Claim against the supporting documents and ensures that there are no errors on the Claim. Furthermore, he/she checks the Claim amounts against the advances paid to the IP/EB. On the income side, the Accounts officer checks if interest income or any other income was recorded by the IP/EB so those can be recorded separately in ECC. Refer to the steps for approval outlined in Annex 2.3. After approving the document, the Approver checks if the Claim has been posted accordingly in ECC by going to the Transaction History. He/she must verify the accounting documents generated in ECC for the Claim. To do this, search the Claim by clicking on Claims on the main menu (left side of the screen) and entering the Claim ID. From the Results List (see below), click on the Claim (blue) link. Note that the Claim status is now Awarded. Page 90 of 114

91 The Transaction history in the Claim will indicate the Grantor Billing Document and the FI documents posted in ECC. It is important to check this section to ensure that Fi documents were indeed posted in the General Ledger. Page 91 of 114

92 If there are error in the Claim, it will reappear in the worklist with error suffix in Account Officer worklist. The Account Officer needs to analyze the cause for error and may send back the request to Certifying Officer for necessary correction Procedure for Claims where Reported Expense is More than the Advance Amount a. The Program Officer instructs the Program Assistant to create a Payment Request for the difference between the advance balance and the expense amount being reported. This additional advance allows the processing of the Claim. If an installment balance is due, process the Payment Request for this installment instead. b. The Program Assistant initiates the Payment Request following the steps suggested in and is then submitted for approval to the Program Officer, Certifying Officer, and Accounts Officer. c. Once the Payment Request approval is completed and paid by Treasury, the Program Officer follows the steps above to complete the approval process for the pending Claim Expense Report Errors and Notes To avoid a delay in processing Claims, the PO should check that the advance is sufficient to cover the amount being claimed as expense. Remember that the Claim can only be processed up to the advance amount. Pay special attention to dates like Claim restriction dates in the Grantor Program, start of Financial Closure date and Grantor Program (validity) end date.. If there are restrictions in the Claim submission date, and Claim is submitted after the designated restriction date, an error will be generated by the system. PSC calculation on IP/EB Transactions: The system calculates Indirect Cost for the Application and Agreement amounts. On the Fund Certification, however, indirect costs are manually entered by the Program Assistant. (This process will be calculated automatically Page 92 of 114

93 in the future based on the final PSC rate negotiated and agreed upon.) Currently, the IP/EB reports the actual Indirect Costs on the Statement of Income and Expenses. In the future, a validation will be made to check that the total Indirect Costs reported are calculated based on the agreed PSC rate/amount Amendment In Release 1 the solution for Amendment is limited to workarounds and will be improved in subsequent releases. The solution that is described below is a temporary solution till the process will be improved. Change Request for Amendment is a Transactional Data in Grantor Management used to record changes to the Agreement. All other transactional data that are based on Change Request functionality, it has a form and the object. The Amendment process utilizes the form initially and the object is created once the form is approved. The Amendment document is prepared off line and singed. Based on this signed document certain actions have to be performed in the system. The signed Amendment has to be attached to the Agreement Object (see in the following sections for steps). Thus, there is no template or proforma for Amendments available in Release 1. Hence, the UN Entity creates a manual Addendum to the Agreement to document the Amendment and the Program Officer collects the signatures from both parties. Depending on the nature of the amendment, the actions in the system will be different: a. If the amendment is an extension of the agreement, the Program Officer will change the dates directly on the agreement object. No workflow is available for time extension of the Agreement. Note that if the Agreement extension goes beyond the Grantor Program, the Grantor Program dates have to be extended first. b. If the amendment is a change on the agreement amounts, a Change Request (Amendment) must be created and should go through the approval process. c. If amendment is both an extension and a change on the amounts of the agreement, (i) and (ii) must be done. d. If the change is only on the project log frame and there is no budget and financial implications, then the revised log frame should be attached to the agreement. Page 93 of 114

94 Amendments to the Agreement amount may be an increase or decrease to the Agreement amount. Note that a decrease in amount can only be made if there is enough balance to be reduced. If the Agreement amount has been paid in full and a reduction of the Agreement amount is desired, the UN Entity should initiate a refund of the outstanding advance that has not been utilized first, before the Agreement can be reduced Creation of Amendment for change the Agreement Amount S.no Process Steps Required Role 1 Creation of Amendment- Change Program Assistant (PA) Amount 2 Program Review of Amendment Program Officer (PO) 3 Financial Certification of Certifying Officer (CO) Amendment 4 Financial Approval of Amendment Accounts Officer (CO) 5 Attached signed PDF Amendment Program Officer (PO) In Release 1 only Program Assistant can create the Amendment in the system, although the Amendment should be initiated by both UN Grantee or the UN Entity. Make sure that you have the singed Amendment document before creating the change request. You can also attach it to the Agreement object before creating Change Request for Amendment. See how to attach the Amendment to the Agreement in the following section. Based on the signed Amendment to the Agreement that was don off-line Program Assistant can initiate a process to change the amount in Agreement. This process will trigger the change in approved amount. a. Program Assistant logs into CRM system. b. Click on Agreement > Change Request Forms c. Enter Agreement ID and click Search. Click on Amendment to open Amendment Form. Page 94 of 114

95 d. Section I: Agreement Header information is defaulted. e. Section II: Request Options- Mark the box Increase/ Decrease Amounts for an amendment to change the Agreement values. f. Enter the appropriate amount in Decrease Amount and Increase Amount column. Note that the amount cannot be increased or decreased at summary level; hence, these fields are greyed out. Any changes to the amount shall be done at each line item. Negative amounts are not accepted and will generate an error. Page 95 of 114

96 g. Enter notes/ comments in section V and upload supporting document in Section VI. h. Program Assistant submits the amendment by clicking Submit button. After submission, the system generates a change request number. Page 96 of 114

97 Approval of the Amendment The Approval of the Amendment is the same for all entities in Release 1. The steps for each level of the review are the same in the system for all transactional data, including Amendment. 1. Program Review of the Amendment Program Officer review the proposed changes through the worklist. The worklist displays all pending request waiting for Program Officer attention. a. Program Officer logs into the CRM system. b. Click on Worklist and click on Amendment Number under Associate Business Object. This allows Program Officer to review the amendment details and supporting documents. c. After completing the review click on the Back button to go back to the Worklist. Page 97 of 114

98 d. The Program Officer can Approve, Reject or Return the Amendment request. To approve, select Approve under Decision and click on Execute Decisions. e. Once the amendment request is approved, the task will disappear from the Worklist. The workflow will trigger the next action. 2. Financial Certification of Amendment Certifying Officer logs into the CRM system. a. Click on Worklist and click on Associate Amendment Number under Associate Business Object. This allows Certifying Officer to review the amendment details and supporting documents. b. After completing the review click on back. This takes back to the worklist. Page 98 of 114

99 c. Certifying Officer can Approve, Reject or Return the Amendment request. To Approve, select Approve under Decision and click on Execute Decisions. Once the amendment request is approved, the task will be disappeared from the worklist. The workflow will trigger the next action. 3. Financial Approval of Amendment a. Accounts Officer to log into the CRM system. b. Click on Worklist and click on Associate Amendment Number under Associate Business Object. This allows Accounts Officer to review the amendment details and supporting documents. c. After completing the review click on back. This takes back to the worklist. Page 99 of 114

100 d. Accounts Officer can Approve, Reject or Return the Amendment request. To Approve, select Approve under Decision and click on Execute Decisions. e. Once the amendment request is approved, the task will disappear from the worklist. 4. Attach/Upload signed Amendment PDF A copy of the signed amendment (pdf) should be attached/ uploaded in the Grantor to the Agreement Object. a. Program Officer logs into the CRM system. b. Click on Agreements and click on Agreement under Search c. Enter Agreement ID number in search criteria and click on Search. The agreement ID will appear in the Result List and click on Agreement ID number. Page 100 of 114

101 d. Scroll to the attachment section and expand the section. Click Choose Files and select the signed amendment document and upload in the system Creating Funds Certification for Amendment S.no Process Steps Required Role 1 Creating Funds Certification for Program Assistant (PA) Amendment 2 FC L1-L1 Program Review for FC Program Officer (PO) Amendment 3 FC L2-L1 Financial Certification of FC Certifying Officer (CO) Amendment 4 FC L3-L1 Financial Approval of FC Amendment Accounts Officer (CO) Based on the signed Amendment to the Agreement, the Funds Certification is required for Amendment. a. Program Assistant logs into the CRM system b. Click on Agreement > Change Request Forms Page 101 of 114

102 c. Enter Agreement ID and click Search. Click on Fund Certification. d. Enter the increase in amount in New Authorized Amount column. Notes/ Comments and supporting document can be uploaded in the Section III and Section IV. If the amendment is for a decrease in amount, enter a negative amount in the Funds Certification Form. Page 102 of 114

103 e. Submit the amendment to FC for Approval. Approval of Funds Certification is the same as described in the section devoted to Funds Certification Approval. It goes through three levels of approval: After Funds Certification is Approved and the Funds Commitment documents for direct and indirect costs are increased in value, the Program Assistant can proceed with creating the Payment Request and submitting it for approval in the workflow Time Extension - Changing the Dates Agreement implementation start and end dates should be changed on the Agreement object directly to extend the implementation duration. Note that currently, there is no workflow for the approval of the extension. The Program Officer is doing this amendment based on the signed Addendum to the Agreement. Page 103 of 114

104 Once changes in the in the implementation duration are done, the dates for operational closure and financial closure need to be adjusted accordingly and in line with the entity operational procedures. The following dates should be amended in the Agreement object under the Dates section: Agreement Implementation End Date - should be within the Agreement expiry date and the Grantor Program validity date. This should match the extension date stated on the signed amendment and e should also match the Start of Agreement Operational Closure date. Start of Agreement Operational Closure - should be within the Grantor Program validity date and matches the Agreement Implementation End Date. Start of Agreement Financial Closure - should be within the Grantor Program validity date and is based on the entity internal operational procedures for closure. Expiry Date is the date when the Financial Closure ends and should be within the Grantor Program validity date; the date after which no further transactions can be made. As mentioned earlier, there is no template to document the Amendment in the Grantor Management module for Release 1, hence, the UN Entity must prepare an Addendum to the Agreement manually for any amendment including the extension of dates. A standard template for amendments shall be generated in the system in a future release. S.no Process Steps Required Role 1 Amendment for extension only IP/EB Program Officer (PO) 2 Attached signed PPDF Amendment Program Officer (PO) To update the dates on the Agreement Object: a. The Program Officer logs into the CRM system. b. Click Agreements and Click Agreements under Search. Page 104 of 114

105 c. Enter Agreement ID in search criteria and Click Search. Then Click on Agreement ID number. d. Scroll down to the Dates Section and Expand it. Signed by Implementing Partner/End Beneficiary entered by the Program Officer; it is the date of signing the Agreement by IP or EB Signed by United Nations - entered by the Program Officer; it is the date of signing the Agreement by UN Entity Agreement Implementation Start Date is the date when work in the project can commence. This is entered by the Program Officer following negotiations of the agreement with the IP/EB while status of Application is Under Negotiation). Agreement Implementation End Date is the date that project work is completed. This is entered by the Program Officer following negotiations of the agreement with the IP/EB while status is Application is Under Negotiation. Page 105 of 114

106 Start of Agreement Operational Closure is defaulted from the Agreement Implementation End Date. As of this date, no further obligation (Funds Certification) can be processed in the system. Payment Requests, Claims (Expense reports) and Amendments can still be processed in the system. Start of Agreement Financial Closure is filled in by the Program Officer based on the internal Standard Operating Procedure of the Entity). The Start of Agreement Financial Closure means that all Payment Requests, Claims and Amendments related to the specific Agreement have been processed. At this time, the only transactions allowed to be processed are refunds, uploading of Narrative reports, evaluations and audit reports. Expire Date is filled in by the Program Officer for now manually and should be equal to the end of the Financial Closure and should be earlier or the same as the Grantor Program valid to date. Note that If the Expire Date is beyond the Grantor Program the Valid to date on the Grantor Program has to be extended. e. Click on Edit list f. The Edit list button makes the dates editable (when clicked) and allows the user to make changes in the dates. Change the Agreement Implementation Start and End dates and the Closure dates accordingly. Note that only the following dates should be changed: Agreement Implementation End Date, Start of the Agreement Operational Closure Date and Start of the Financial Closure date changed. Expiry Date Page 106 of 114

107 In case the Grantor Agreement Expiry date needs to be extended beyond the Grantor Program valid date, the Grantor Program must be updated first. Go to the Grantor Program and extend the date. After, go to the Agreement object and expand the Dates section. Change is the Expiry Date accordingly. g. Click Save to record the changes. h. The copy of the signed Amendment that was the basis for changing the dates on the Agreement Object should be attached (to the Agreement Object). Scroll to the Attachment section and expand the section. Click Choose Files and select the signed amendment document and upload in the system. Changes in the dates will not have any financial implication Amendment Errors and Notes: For Release 1, amendments should be prepared offline using the current (pre-grantor Management) format the UN Entity has. Depending on the type of change, the action in the system differ. An amendment to change the Agreement amount is done using the Change Request Amendment form) while a change in dates is a direct change Page 107 of 114

108 on the Agreement Object in the section Dates. Note that no approval is required and there is no workflow for the latter change. For a change in banking information, the request has to be submitted using F.249 and submitted to tha local Cashier to update the BP in ECC. There may be other reasons to initiate an amendment (e.g. change in log frame, change in project location). Other changes that do not have financial and budgetary implications are done off line and the Addendum and other supporting documentation are attached (uploaded) to the Agreement object. For the amendment that is increasing the Agreement amount, it is important to ensure that sufficient budget and cash available. At present a new line item (an expense type not included in the Agreement) cannot be added through an amendment. A subsequent release will include the function to add a new line item in the Agreement expense types. There is no return option for the amendment. It can be approved or rejected. Where the amendment increases the Agreement amount, the creation of Change Request Amendment increases the value(s) in the Agreement amounts column only and not the Authorized amounts. It is therefore, necessary to create a Change Request - Funds Certification for this type of Amendment to increase the Authorized amounts in the Agreement which would allow the processing of transactions. After the Fund Certification (for the amendment) is approved by the Accounts Officer, the value in the specific Earmarked Funds document in ECC will be updated with the change. Budget revision should not decrease the amount from any line lower than previously approved Agreement amount. The Agreement approved budget should not result to a negative balance(s). A validation will be built for subsequent release. When the total amount of the Earmarked Funds is fully consumed as a result of the advance(s), an amendment to reduce the Agreement amount will not be allowed. The outstanding advance must be processed as a refund to decrease the Earmarked Funds first before a decrease in the Agreement amount can be processed. Note that as of this writing, the refund process is still being developed. An amendment to the Agreement may be made for banking information changes. Page 108 of 114

109 To update banking details, an Addendum to the Agreement for this type of amendment is prepared offline for Release 1 and shall be signed by both the parties. Once signed, the document is then uploaded in the Attachment section of the Agreement by clicking on the buttons Choose Files and Upload. The change is requested via F.249 form (Fund Request Form (for commercial and non-commercial third parties) and submitted to the local Cashier. Follow the Business Partner Banking Details Maintenance Guide GRT_312 Closure of Grantor Agreement In Release 1 there will be limited introduction of functionality supporting closure. There are no validation for this process. Once the check list below is done by the Program Officer, he/she will move the status on the Grantor Agreement to Closed. The Grantor Agreement shall be closed when all projects activities are completed, and final settlement is done. Therefore, it is important to ensure the following: There are no outstanding Calls (Requests) for Proposals; There are no Applications to be reviewed; Final Financial and substantive reports are submitted, approved and uploaded to the Grantor Agreement object; Final payment and refunds under the Agreement are processed; Project audit, monitoring and evaluation reports, if any, are submitted, reviewed and uploaded to the Grantor Agreement object; If there is any refund, including the ineligible cost from audit report, funds should have been received and applied; No outstanding payment to and from the UN Grantees. The Statuses on Agreement will be updated manually by the Program Officer. Note that in Release 1 the Grantor Agreement can be set directly from status "Award" to status "Closed". It might change in Release 2 depending on the overall solution for the Closure of the Grantor Agreements and corresponding Grantor Program with introduction of the evaluation and monitoring steps. By closing the Agreement, the system prohibits any posting against the Agreement. a. Log into Grantor Management Module. Page 109 of 114

110 b. Click on Agreements and then, Agreements under Search. c. Enter Agreement number, click the Search button,tand enter the Agreement ID number. d. Click Edit on Agreement Overview, change the status to Closed and save. Page 110 of 114

111 e. The status changes from Awarded to Closed. Once the Agreement has changed to the status Closed, the system prohibits the processing of any transaction under the specific Agreement. Note that status Closed can be manually moved back to Awarded Closure of the Grantor Agreement Errors and Notes Note that the dates on the Agreement are not linked to statuses of the Agreement. The Program Officer should ensure that the Expiry Date in section Dates on the Agreement is in sync with the Closed status of the Agreement Manual process will be streamlined in the subsequent Umoja releases GRT_313 Closure of Grantor Program In Release 1, there will be limited introduction of functionality supporting closure. There are no validation for this process. All validations are done manually. The Grantor Program can only be closed when all the activities under the Grantor Program are done, no new applications are expected, no applications in status "Selection Review" or "Agreement Review" and all Agreements are closed. The Program Officer can decide to close the Grantor Program and manually change the status from Released, Approved to first Released, Completed and from Released, Completed to Released, Closed. Ensure that all the activities under the Grantor Program are completed before setting the status of the Grantor Program to Closed. Ensure that all Agreements under this Grantor Program have been set to status Closed. If any Agreement has not been closed, the system will generate an error when setting the status of the Grantor Program to Closed. a. Log into CRM System b. Search for the Program. Click on Programs, then, Programs under Search. c. Enter Program ID, then click Search. Click on the specific Program ID to be closed. Page 111 of 114

112 d. Click Edit in Program Details and change the New Status to Completed. This will bring the current status to Completed. e. Save the Grantor Program. f. Next, click Edit again on the Program Details and change the New Status field to Closed. This will change the current status to Closed. g. Save the Grantor Program. The status of the Grantor Program can be reinstated from Closed, Closed to Released, Completed and from Released, Completed to Released, Approved. Page 112 of 114

113 Closure of Grantor Program Errors and Notes Note that in Release 1 the Grantor Program must be set first to status "Completed" and then to status "Closed". This may change in Release 2 depending on the overall solution for the Closure of the Grantor Agreements and corresponding Grantor Program with introduction of the evaluation and monitoring steps. Page 113 of 114