Managing Grants Management Master Data

SAP Grants Management provides you with a solution for sponsored programs through its functionality and its architecture. Architecturally, SAP Grants Management maintains a separate view of your organization's sponsored program activities and projects. This separate view is created by relating your organization's structures (such as projects, general ledger accounts, cost elements, fiscal year, and currency) to the sponsor's projects, cost and revenue categories, budget validity period, fiscal year, and currency.

By creating a separate view, you can review your organization's financial activities and transactions for sponsored programs according to a sponsor's requirements without affecting the integrity of your financial transactions and activities.​

Consider differences between your organization's and your sponsor's budget. Some sponsors require more detailed budgeting; others require less. Not only do the requirements among sponsors differ, they also frequently do not match the budgetary requirements of grantee organizations. These differences often require grantee organizations to compromise their budgeting structures and processes so that they can effectively manage their sponsored programs according to the sponsor's guidelines.

As SAP Grants Management creates an alternative view based on the sponsor's requirements, you can manage, control, and report on your sponsor programs without compromising your budget structures and processes.

SAP Grants Management's primary master data components are sponsor, grant, fund, sponsored program, sponsored class.​

• A sponsor is an institution or individual that provides funding to a grantee organization
• A grant is the funding instrument the sponsor provides and documents the funding agreement between the sponsor and the grantee organization
• A fund represents the source of funding
• External - Sponsors award amount​
• Internal - Grantee's funds and resources (cost sharing)​
• Sponsored programs represent the organization's sponsored projects
• Sponsored classes summarize the sponsor's expense and revenue categories

Manage Grants ​

You can use this SAP Fiori app to manage the grant master data and perform various actions.​

Key features include the following:​

• List existing grant master data using filter and search options.​
• Create a new grant from scratch, or as a copy of an existing grant master record.​
• Revise existing grant master data.​
• Change the lifecycle status of a Grant​
• Delete any grants that are not used and are no longer required. The budget and posting data is checked to ensure that a grant is not used anywhere else.​
• Use the draft function to interrupt creation or revision until you continue editing the draft and save it as new master data to the database.

You have to enter​ (this minimum at least) the following:

• Name of the Grant​
• Grant Type​
• Sponsor​
• Authorization Group​
• Cost Center​

The company code is derived from the Cost Center.

In this section, the validity, fiscal year variant, and Time Slices of the grant are defined.​

Time slices can be used to split the budget according to the sponsor's rule.​

They can be generated with the help of the time slice split rule, or manually entered.

In this section, the dimensions allowed for the Grant are defined. 

Postings to the grant are only allowed with the funds, Sponsored Programs, and Sponsored Classes defined here.​

The functionality of the IDC relevant flag for fund and sponsored class are described in more detail in Unit 4, Lesson 2, Calculating Indirect Costs. ​

The functionality of the Cost Sharing flag for the fund is described in more detail in Unit 4, Lesson 1, Handling Cost Sharing.

In the billing section, it is defined if this grant uses the ResourceRelated Billing functionality, which is described in Unit 4, Lesson 3, Running Billing Processes.​

In the Cost Share section, the Cost Share percentage for Sponsored Program, Sponsored Class, and Fund combinations can be entered. The Cost Share functionality is described in Unit 4, Lesson 1, Handling Cost Sharing.

In the indirect Cost section, the rates and caps for Indirect Cost Calculation can be entered.

The Indirect Cost is described in Unit 4, Lesson 2, Calculating Indirect Costs.

In the following figure, you see all the changes that have occurred in the change log.

In the following figure, you can track the workflow activity for the grant master status changes.

The Sponsor has the financial and administrative details like Name, Contact Information, and Payment Information.​

It also holds defaults for creation of a grant. The defaults shown on the left are taken over to the grant at its creation but can be changed on the grant.

The Fund Type determines if the fund represents external funds (the award amount of the sponsors) or internal funds (own organizations money).

The Sponsored Program​ consists of the following:

It has the Description and Attachments ​

The Sponsored Class consists of the following:​

• It has the Description and Attachments
• The Class Type determines if the Class is for expenses or revenues​
• The Billable Flag determines if expenses are taken into account in billing functionality - see Unit 4, Lesson 3, Running Billing Processes
  Note

  Unit 4 (Managing the Transactions Involved in SAP Grants Management) covers a great deal in relation to billing.

The Grant Master data Grant, Fund, Sponsored Program, and Sponsored Class can be placed in hierarchies.

The hierarchies can be used in Availability Control (link to AVC) and reporting.

Usually grants go through a life cycle, for example, from the status "initial draft" which represents only an idea for a grant to the status "closed" for a completed grant which is ready for archiving. SAP pre-delivers life cycle status (initial draft, proposal, application, award, closing, closed, canceled). Some of the life cycle status follow a specific behavior. For example: In order to post documents, the grant needs to be in the award stage or archiving is only allowed if the status is closed or cancelled. While the life cycle status are pre-delivered, the configuration of status (and all the dependent configuration) is only done via configuration. Thus it is possible for customers to create their own status. Each status will be linked to a delivered life cycle status. With the definition of a status network, you can define which next status can follow the current status.

The status network is linked to the grant type. It is not required to use all the life cycle status for every grant type. For example, for grant type A, you use the status proposal, for grant type B you do not.

Not all grant master data needs to be entered in every status. ​Status changes are performed in the grant maintenance transactions and it is possible to configure the approval process via workflow.

​The following image shows the difference between the delivered life cycle status and the configured status. Where user defined status such as "Application sent to sponsor" or "Application rejected from sponsor" to enhance the life cycle status. Through the network it is possible to model a back and forth application interaction with the sponsor.

​The following image shows the configuration of status and the link to the delivered life cycle status. ​The sequence number is used to determine the order of status in the status network. The data in the value help of the previous status there is sorted according to the sequence number.

​The following image shows the status network for a particular grant type. It is possible to define any sequence of status. The beginning status of the sequence has to be marked. The end status (for example closed) is not used as previous status in any other status.

In this example the data sections for cost sharing and IDC are being hidden, which means that this data can only be maintained from application status on.

​The image shows the configuration to overwrite the posting behavior of a status. If not overwritten the life cycle status "award" and "closing" allow all postings to occur while all other status do not allow any posting. In the example the status "pre-award" allows already contracts and pre-encumbrance but not encumbrances or actual financial transactions.

It might be on the other side that the "closing status" does not allow new contracts and pre-encumbrance any more.

​Once the grant types and the corresponding status configuration are done, it influences the grant maintenance app when the status of a grant is changed. Status changes always trigger a workflow approval process. However without further configuration of the workflow, the status changes are approved automatically.

If a workflow is defined, then a workflow task is sent to one or many users for approval of the status change. Here all the functionality of the SAP S/4HANA Cloud Flexible Workflow applies.

Once the user triggers the next status and the grant awaits the approval, the grant stays in the previous/current status until approved. However if the approver rejects, then current status will not be changed.

The next picture shows a workflow configuration for approval of the status change from application to award (being sent to the sponsor). It is further conditioned for government grants over 10.000 dollars.

Many possibilities for conditions and approver determination (for example the grant responsible) are pre-delivered.

​Only the status (not the life cycle status) is always shown in the header section of the grant master. When pressing the button "Update Status", the system proposes the possible next status according to the configured status network. This action then triggers the creation of a workflow approval task and only the approval will change the status subsequently.

​The following image shows the WF status of the grant. Here the grant responsible has been found as approver. The workflow task is ready for approval. The grant master is blocked for changes until the workflow task is decided by the approver.

Every status change is being logged in the change log of the grant.

​The approver get the task in his inbox, where the grant master can be seen and either be approved or rejected. Once the task is resolved it will disappear from the inbox automatically.