Baseline Document for Grantor Management Release 1 Guidance for... · The following signatures indicate approval of this document and its contents. Name Signature Date Chandramouli

Baseline Document for Grantor Management – Release 1

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

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.1.0 14.12.2018 Binod Lamsal Initial Draft

v.1.0 06.01.2019 Elsa Bonecillo-Deniega Review

v.1.0 01.02.2019 Nina Tillens Review

v.1.0 01.03.2019 Grantor Management Team Final – Release 1.0

Table of Contents

TABLE OF CONTENTS ................................................................................................................................ 3

GRANTOR MANAGEMENT BASELINE RELEASE 1 ....................................................................................... 6

1. OBJECTIVES ...................................................................................................................................... 6

2. GRANTOR MANAGEMENT BUSINESS PROCESS ................................................................................ 6

3. LOGGING IN TO SAP CRM – GRANTOR MANAGEMENT .................................................................. 14

4. PROCESS ........................................................................................................................................ 14

4.1 GRT_L301 GRANTOR PROGRAM – CREATION AND APPROVAL ............................................................ 14 4.1.1 Create Grantor Program Step ................................................................................................ 19 4.1.2 Submit the Grantor Program ................................................................................................. 24 4.1.3 Approve Grantor Program L1 - Program Officer – Programmatic Review ........................... 24 4.1.4 Approve Grantor Program by Certifying Officer – Financial Review .................................... 27 4.1.5 Errors & Notes ........................................................................................................................ 29

4.2 GRT_302 IDENTIFY AND ENGAGE POTENTIAL GRANTEES.................................................................... 31 4.3 GRT_303 SCREENING AND REGISTRATION ...................................................................................... 31 4.4 GRT_304 APPLICATION .............................................................................................................. 31

4.4.1 Creation of Application .......................................................................................................... 33 4.4.2 Printing the Application ......................................................................................................... 45 4.4.3 Selection Review of the Application ...................................................................................... 46 4.4.4 Errors and Notes ..................................................................................................................... 49

4.5 GRT_L305 POST-APPLICATION APPROVAL ..................................................................................... 49 4.6 GRT_L306 NEGOTIATIONS ON GRANTOR AGREEMENT ...................................................................... 49

4.6.1 Enter Account Assignment in the Application: ...................................................................... 52 4.6.2 Generate Proforma Contract for Negotiations ..................................................................... 55 4.6.3 Enter and change editable fields ........................................................................................... 57 4.6.4 Enter Bank Details .................................................................................................................. 61 4.6.5 Add non-standard clauses ..................................................................................................... 61 4.6.6 Change the amount of the Proforma Contract ..................................................................... 61 4.6.7 Change the dates of the Proforma Contract ......................................................................... 62 4.6.8 Attach additional submitted documents ............................................................................... 63 4.6.9 Generate Finalized Proforma Contract .................................................................................. 63 4.6.10 Generating the Annexes .................................................................................................... 65 4.6.11 Program Review and Approval in Workflow .................................................................... 66 4.6.12 Agreement Review (based on UNMAS Example) ............................................................. 66

4.6.12.1 Legal Review of non-Standard clauses ......................................................................................... 67 4.6.12.2 Programmatic Review .................................................................................................................. 68 4.6.12.3 Financial Review ........................................................................................................................... 69 4.6.12.4 Financial Review by Senior Finance Officer ................................................................................. 69 4.6.12.5 Final Approval ............................................................................................................................... 69

4.6.13 Application Errors and Notes ............................................................................................ 69 4.7 GRT_L307 SIGNING OF GRANTOR AGREEMENT ............................................................................... 70

4.7.1 Generate Grantor Agreement ............................................................................................... 70 4.8 GRT_L308 BUDGET CONSUMPTION OF GRANTOR AGREEMENT .......................................................... 72 4.9 GRT_L309 FUND CERTIFICATION OF GRANTOR AGREEMENT .............................................................. 73

4.9.1 Create Funds Certification Document .................................................................................... 73 4.9.2 Workflow and Approval for Fund Certification ..................................................................... 75

4.10 GRT_L310/GRT_L311 LIFE CYCLE EXECUTION OF GRANTOR AGREEMENT ........................................... 77 4.10.1 Payment Request ............................................................................................................... 77

4.10.1.1 Payment Request Creation .......................................................................................................... 78

4.10.1.2 Payment through UNDP Financial Authorization ........................................................................ 80 4.10.1.3 Payment Request Approval-L1-PO ............................................................................................... 81 4.10.1.4 Payment Request Approval-L2-CO ............................................................................................... 82 4.10.1.5 Payment Request Approval-L3-AO .............................................................................................. 82 4.10.1.6 Payment Request Notes ............................................................................................................... 83

4.10.2 Expense Report .................................................................................................................. 84 4.10.2.1 Creation of the Expense Report ................................................................................................... 84 4.10.2.2 Expense Report Approval ............................................................................................................. 87 4.10.2.3 Procedure for Claims where Reported Expense is More than the Advance Amount ................. 92 4.10.2.4 Expense Report Errors and Notes ................................................................................................ 92

4.10.3 Amendment ....................................................................................................................... 93 4.10.3.1 Creation of Amendment for change the Agreement Amount..................................................... 94 4.10.3.2 Approval of the Amendment ....................................................................................................... 97 4.10.3.3 Creating Funds Certification for Amendment ............................................................................ 101 4.10.3.4 Time Extension - Changing the Dates......................................................................................... 103 4.10.3.5 Amendment Errors and Notes: .................................................................................................. 107

4.11 GRT_312 CLOSURE OF GRANTOR AGREEMENT .............................................................................. 109 4.11.1 Closure of the Grantor Agreement Errors and Notes ..................................................... 111

4.12 GRT_313 CLOSURE OF GRANTOR PROGRAM ................................................................................ 111 4.12.1 Closure of Grantor Program Errors and Notes ................................................................ 113

2. ANNEXES ..................................................................................................................................... 114

ANNEX 2.1: GUIDANCE IN TESTING THE AGREEMENT WITH EXTERNAL PARTIES .................................................. 114 ANNEX 2.2: PAYMENT METHOD QUICK GUIDE (USD-EUR-GBP-XOF-XAF)................................................... 114 ANNEX 2.3: WORKFLOW OVERVIEW........................................................................................................ 114 ANNEX 2.4: SECURITY OVERVIEW ........................................................................................................... 114 ANNEX 2.5: GRANTOR PROCESS FLOW OVERVIEW ....................................................................................... 114

Page 5 of 114 Issued by: Release date:

Changes Introduced in the subsequent soft releases

1. Changes Introduced in Release 1.01

1.1 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 5000000 06)


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-by-step 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.


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.


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


• 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:


Each step of end-to-end process is described in the scripts are located in the Testing Community on Unite Connections (https://connections.unite.un.org/communities/).

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:

https://connections.unite.un.org/communities/


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.


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 emails for NGOS o Assign Target Groups to Campaign o Create and Run the Campaign to send emails 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*


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.


3. Logging in to SAP CRM – Grantor Management

The URL to access SAP CRM in production is https://login.umoja.un.org/vpn/index.html. To log-in, 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.

https://login.umoja.un.org/vpn/index.html


• 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.


• 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.


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)


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


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.

4.1.1 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.


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.


• 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 500000000 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.


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.


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.


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

4.1.3 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


• 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.


d. Note any periods selected. In the given example, the application is open from 1st Jan 2019 to 28 Feb 2019. 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.


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.

4.1.4 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.


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


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

4.1.5 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.


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


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 emails to potential IPs/EBs.

This functionality will be designed, configured and made available in a future release. It is not available in Release 1.0.

4.3 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.


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.


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.


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.


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


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.


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, Email Address and Contact Information.The blank fields are expected to be completed by IP/EB or the Program Assistant.


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.


• 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


• 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.


• 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.


• 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


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.


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


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.

4.4.2 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.


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 (201-500K) 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


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,


• 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.


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


• 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.


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.



1 Enter Account Assignment Program Officer (PO)

2 Generate Proforma Contract for negotiations

Program Officer (PO)

3 Enter and change editable fields Program Officer (PO)

4 Add non-standard clauses Program Officer (PO)

5 Change the amount of the Proforma Contract


6 Change the dates of the Proforma Contract Program Officer (PO)

7 Attachments additionally submitted Program Officer (PO)

8 Generating Finalized Proforma Contract and Attach


9 Program Review and approval in Workflow Program Officer (PO)

4.6.1 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.


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.


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.


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


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.


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.

4.6.3 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.


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………


• 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)


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.


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.

4.6.5 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.

4.6.6 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.


b. Make the necessary changes in cost plan and PSC rates and click Back

4.6.7 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.


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.

4.6.9 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


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.


e. Save the Application.

4.6.10 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.


4.6.11 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.

4.6.12 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.


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)

4.6.12.1 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.


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

4.6.12.2 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.


4.6.12.3 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.

4.6.12.4 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.

4.6.12.5 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.

4.6.13 Application Errors and Notes

✓ When assigning the WBSE, ensure that it is correct, and that sufficient budget

and cash are available.


✓ 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 email).

4.7 GRT_L307 Signing of Grantor Agreement

4.7.1 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.


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


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.


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

4.9.1 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.


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


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.

4.9.2 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.


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.


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.

4.10.1 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


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.

4.10.1.1 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


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 06.02.2019 because

baseline date is 07.01.2019.)

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.


4.10.1.2 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.


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.

4.10.1.3 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)


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.

4.10.1.4 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.

4.10.1.5 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.


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.

4.10.1.6 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.


4.10.2 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.

4.10.2.1 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’


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.


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.


o. Upon submission, the status of the Claim changes to Program Review

4.10.2.2 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.


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.


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.


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.


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.


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.

4.10.2.3 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 1.16.1 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.

4.10.2.4 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


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.

4.10.3 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.


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.

4.10.3.1 Creation of Amendment for change the Agreement Amount


1 Creation of Amendment- Change Amount

Program Assistant (PA)

2 Program Review of Amendment Program Officer (PO)

3 Financial Certification of Amendment

Certifying Officer (CO)

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.


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.


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.


4.10.3.2 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.


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.


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.


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.


d. Scroll to the attachment section and expand the section. Click

Choose Files and select the signed amendment document and

upload in the system.

4.10.3.3 Creating Funds Certification for Amendment


1 Creating Funds Certification for Amendment

Program Assistant (PA)

2 FC L1-L1 Program Review for FC Amendment


3 FC L2-L1 Financial Certification of FC Amendment

Certifying Officer (CO)

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


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.


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.

4.10.3.4 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.


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.


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.


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


• 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


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.

4.10.3.5 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


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.


• 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.

4.11 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.


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.


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

4.11.1 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.

4.12 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.


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


4.12.1 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.


2. ANNEXES

Five annexes from this section are to be provided as separate files. Such Annexes as Workflow, Process Flow overview and Security will be revised as more entities are deployed. As those attachments are under constant revision for new entities, please get the latest copy of the annex from the community. Please pay attention to the date in the name of the files.

Annex 2.1: Guidance in Testing the Agreement with External Parties

GRT Release 1

Guidance for Testing Agreement (UVT).docx

Annex 2.2: Payment Method Quick Guide (USD-EUR-GBP-XOF-XAF)

PMT method

Bank_Determination_Cheat_Sheet_Nov-16.xlsx

Annex 2.3: Workflow Overview

GRT Release 1

Workflows Overview UVT.xlsx

Annex 2.4: Security Overview

GRT Release 1

Security Overview (UVT).xlsx

Annex 2.5: Grantor Process flow overview

GRT Process Flow

Overview (Level 3) v 1.0.pdf