Disaster Recovery Grant Reporting System
Disaster Recovery Grant Reporting System
DRGR Training Slides_Day 2_Participant Notes_5.24.12_rev_FINAL.pptx
Disaster Recovery Grant Reporting System
OMB: 2506-0165
Disaster Recovery Grant Reporting System Training for NSP Users
<number>
<number>
<number>
Session Rules
•Ask lots of questions
•Set all cell phones to silent or vibrate.
•Raise your hand if you are having computer problems or fall behind. We are here to help!
<number>
2
Today’s Agenda
•Quick overview of yesterday’s material
•Items to be covered:
–Drawdown Module
–Admin Module
–Reports Module
–Telling Your NSP Story via DRGR
–Common Issues & Troubleshooting
•Q&A Session
2
3
3
The Basics: DRGR Modules
3
DRGR is now composed of five major modules: Admin, Action Plans, Drawdowns, QPRs, and Reports. The Admin module was enhanced in late 2010 and is now a more prominent feature in DRGR. Each of these modules will be covered today. Even if you will only work within one of the modules, it is important to understand how the five modules inter-relate.
•Admin: Admin module allows the grantee admin users to certify other grantee users and assign them to grants. Grantees can also record any monitoring, audit, and technical assistance (TA) events they conduct as part of grant oversight.
•Action Plans: The Action Plan in DRGR mirrors the information submitted in the substantial amendment sent to HUD. If the grantee has not yet identified specific organizations and programs, the activities listed in the amendment may show as projects in DRGR. The Action Plan may be resubmitted multiple times as new activities are awarded and entered.
•Drawdowns: Once the Action Plan is set up and approved, grantees will use the Drawdown Module to obligate funds, receipt program income, and create draw vouchers.
•QPRs: As grantees move forward with their NSP grants, they are required to submit quarterly reports to HUD via DRGR. The information reported in the QPR module is key to demonstrating progress – both financial and performance.
•Reports: The DRGR system has a comprehensive set of canned reports available to pull information out of the system, including administrative reports, financial reports, and performance reports. Reports can serve as valuable management tools for two main reasons: (1) to help grantees monitor the status and progress of their various funded projects and subrecipient, and (2) troubleshoot issues or concerns a grantee is facing within DRGR. The reports can be viewed online, printed, or downloaded as a PDF or Excel file.
<number>
<number>
Action Plan Review:
City of Zorro Example - Activity Structure
•Financing Mechanisms (Eligible Use A)
–City LLR LH25
–City LLR LMMI
–Sub recipient LLR LH25
•Acquisition/Rehab (Eligible Use B)
–Sub recipient Acquisition/Rehab LH25
–City Single Family Acquisition/Rehab LMMI
–City Multi-Family Oak Street Property LH25
–City Multi-Family Elm Street Property LH25
<number>
•The projects are straightforward. Each eligible use becomes a project, so we have Financing Mechanisms and Acquisition/Rehab. Most likely, the grantee will also be funding Admin, so that would be a third project.
•Under Financing Mechanisms, we have two responsible organizations: the subrecipient and the City. This means two activities. However, the City thinks it will serve some households at or below 50% AMI and some households above 50% AMI. In order to get credit for the set-aside requirement, the households at or below 50% AMI must be associated with the set-aside national objective. To do this, the City will set up one activity with the LMMI national objective for the proposed households over 50% AMI, and one activity with the set-aside national objective for the proposed households below 50% AMI.
•We see the same breakout under Acquisition/Rehab, but we see two additional activities to represent the proposed multifamily properties. Again, HUD would like these multifamily properties reported under their own DRGR activity.
•Notice what is not on the slide. Please note that none of the following are “wrong,” but they tend to complicate data entry and make the whole process less efficient.
oThe City is not creating a separate activity for each single-family property.
oThe City is not breaking out separate activities for acquisition and rehab.
oThe City is not creating a separate activity for disposition, which can be lumped under the other activities based on its end use.
oKEY POINT: The program description in the Substantial Amendment MUST be adapted for purposes of DRGR. This is not a one-for-one breakout.
5
5
5
5
Action Plan Review: Accomplishments
5
Performance Measure | NSP1 | NSP2 | NSP3 |
Households Benefitting | Required | Required | Required |
Housing Units | Required | Required | Required |
Income Levels | Required | Required | Required |
Renter/Owner | Required | Required | Required |
Single/Multi Family | Required | Required | Required |
Race/Ethnicity | Required | Required | Required |
Female-Headed | Required | Required | Required |
Number of Properties | Encouraged | Encouraged | Encouraged |
Green Measures | Encouraged | Required* | Required* |
This slide illustrates which of the accomplishment and beneficiary data is required and which is encouraged.
•The majority of fields are required. Some of these fields, like Race/Ethnicity and Female-Headed Households, will only appear on the quarterly report; there is no need to break out your goals by these characteristics.
•Again, many grantees have not gone back and back-filled these data elements. It is important for grantees to do so as if the information is not provided on the Action Plan (the front end), the grantee will not have an option of reporting under these categories in the QPR (the back end).
•It is recommended that you verify this information is in the system before submitting your next QPR. Some of the Microstrategy Reports can quickly summarize the proposed goals entered for each activity.
•You can add a wide variety of additional accomplishment data, but if you don’t have that particular item as a regular component of your program and you won’t be tracking it, don’t include it.
<number>
<number>
<number>
<number>
QPR Review
•Purpose
–Report progress for quarter and cumulative basis by:
•Identifying accomplishments once a national objective has been met
•Pulling financial data as entered in the Drawdown Module
•Detail, in narrative format, progress of the grant as a whole and per activity
•HUD FO role
–Approval or rejection of the QPR in a timely manner
–Provide and share comments with grantees (if desired)
<number>
Given the urgency associated with NSP, HUD wanted to make sure there was good communication between the grantees and the HUD Field Office regarding performance. The QPR module in DRGR provides a tool and framework for that communication. It is the tool to identify progress towards statutory requirements, such as national objectives being met and progress toward expenditure milestones.
You, the grantee, will show progress on three levels:
1.Performance – by identifying actual metrics once a national objective has been met
2.Financial – by all the financial data entered into Drawdown Module that quarter
3.Narrative – by explaining how the program is progressing
After the end of each quarter, the grantee will create and submit a QPR. The HUD Field Office will review it and approve or reject the report in a timely manner.
7
7
7
7
Drawdown Module
8
Obligating Funds
Program Income
Create Vouchers
Create and Approve Draw Vouchers
Voucher Corrections
This section will cover the functions that can be performed in the Drawdown Module. This include:
•Obligating funds
•Reporting and applying program income
•Creating and approving draw vouchers
•Correcting or revising vouchers
<number>
<number>
<number>
<number>
Drawdown Module Overview
•Drawdown Process
–Obligate Funds
–Create Draw Voucher
–Approve Draw Voucher
–Over Threshold?
•Yes – Send additional info to HUD for approval
•No – wire transfer in 2-3 days
•Additional Functions
–Draw Corrections
•Revise
•Reject
•Cancel
–Program Income
The Drawdown Module is where nearly all of the financial functions of DRGR are located. This includes reporting obligations and initiating the reimbursement of eligible expenditures from the grant line of credit.
•The request for funds is called a “drawdown” request, thus the name of the module.
•Each drawdown request becomes a “voucher,” or a record of the drawdown request against the grant line of credit.
•In order to draw down grant funds and receive reimbursement from the U.S. Treasury, you must complete several tasks within DRGR. These are summarized below. Detailed instructions on completing each of these tasks will be provided later in this section. It is assumed that a grantee has already set-up their Action Plan and submitted and received approval on the original submission.
oObligate grant funds to an activity from a project.
oCreate the voucher.
oApprove the voucher.
•Note that if a voucher line item exceeds a drawdown threshold, it is forwarded to HUD for approval before being submitted to LOCCS.
DRGR will then automatically “send” the voucher to the federal Line of Credit Control System, also called “LOCCS.”
oThis is the system used to directly reimburse grant funds to grantees.
oIt is an interface with the U.S. Treasury.
oLOCCS will receive and process the item overnight.
oFunds will be wired to you two to three days from when the voucher is processed.
•Please remember that the ability to perform these tasks is restricted by the user permissions granted to the individual DRGR user.
•DRGR also allows draws to be revoked, cancelled, and revised, and for program income to be reported as received and applied.
<number>
<number>
Drawdown Module Overview: Field Office Actions
•Give policy recommendations on when/how to obligate funds.
•Get help from CFO if grantee has missing Tax ID (TIN) or Bank Routing Information in LOCCS.
•Take action on draws over the threshold.
<number>
Most drawdown actions can be completed by grantees alone. However, there are some instances where HUD staff may have to assist the grantee.
•HUD field office staff can help grantees determine what is, and what is not, a valid obligation: this is specifically essential for NSP1 grantees that have a obligation milestone.
•If the grantee is having issues with their Tax ID (TIN) or Bank Routing Information in LOCCS, they may not be able to draw funds from the system. The field office staff can help troubleshoot issues in these cases.
•HUD can take action on draws over the threshold. Details instructions are slide 100 of this training.
11
11
Obligate Funds
•All funds Obligated at Activity Level
–Obligated funds include both Program Funds and Program Income (as of Release 7.3)
•Must meet NSP1 definition of Obligation
–If questionable, clarify with CPD Rep
•Must have Request or Approve Drawdown role
11
Funds must be obligated to an activity before they can be drawn. This serves both as a financial function that precedes the drawdown and reports to HUD that funds have been obligated. Note that obligations are made at the activity level, not at the project level. (Keep this in mind when setting up activities in your Action Plan.)
NSP1 grantees should keep in mind that obligations are a milestone requirement for NSP1 grantees, particular attention should be paid to the timing of making obligations in DRGR. Please consult HUD guidance regarding the NSP definition of “obligation.”
Obligating funds can be performed by users with “Request Drawdown” or “Approve Drawdown” permissions.
12
12
12
12
Obligate Funds
•Necessary Roles: Request Drawdown or Approve Drawdown
Selecting the “Drawdown” module in the top navigation menu will take you automatically to the Activity Obligation screen. To get there from other screens within the drawdown module, use the module navigation links in the left margin.
From the Activity Obligation screen, you will search for activities to obligate funds to them.
You may search by Grant Number, Grantee Activity Number, and/or Responsible Organization. Once you enter the search criteria, click on the “Search” button. To clear the criteria or start over, click on the “Reset” button.
Remember: You must have user permission to either create drawdowns or approve drawdowns in order to obligate funds.
13
13
13
13
Obligate Funds
14
After clicking “Search,” results will appear that meet the search criteria. The default sort order is Grant Number, Responsible Organization, and Grantee Activity Number.
Note that the results may be presented on more than one page. Click on the links below the results table to see more results.
Results can be narrowed by modifying or adding search criteria and clicking on the “Search” button again.
To change the obligation amount, click on the “Maintain” link in the “Action” column at the end of the row for the activity.
<number>
<number>
<number>
<number>
Obligate Funds
Clicking on the link will take you to the “Add-Edit Obligation Line Item” screen. You will see Activity information, including;
•Associated grant number
•Grantee assigned activity number
•Entity responsible for undertaking the activity
•Activity type
•Activity title
This screen will also show current financial information you will need to determine how much (or how little) you can obligate. Remember the math rules of DRGR (see next slide).
•Total Budget (from your Action Plan)
•Total Obligated Amount (currently obligated)
•Available for Obligation (above and beyond the current obligation amount)
•Total Drawn Amount (includes all processed vouchers)
•Total PF and PI amounts drawn.
In the “Obligation Amount” field (the only field that can be edited on this screen), enter the total amount you wish to have obligated to the activity.
Click on the “Save Amount” button to change the obligation amount to the new amount entered.
You will receive the message “Obligation Amount successfully saved” if the change was accepted. If not, you will receive an error message. If you see an error message, review the math rules.
As of Release 7.3, the obligation screen provides a breakdown of the Total Amount Drawn by Program Funds and Program Income.
15
15
Obligate Funds: Drawdown Math Rules
Obligation amounts must be less than or equal to the Total Activity Budget and greater than or equal to the Total Drawn Amount
(can’t decrease the obligation amount to less than the amount that has already been drawn down)
$1,000,000 ≥ $500,000 ≥ $200,000
**As of Release 7.3, grantees enter BOTH program funds and program income as part of the Total Activity Budgets and Activity Obligations.
15
DRGR Math Rules
There are internal controls within DRGR that serve as checks and balances. These “math rules” will stop you in your tracks if you ignore them.
Grantees will not be able to change an obligation amount to an amount that is:
More than the total amount of un-obligated funds available to the grantee in DRGR; or
Less than the amount that has already been drawn down against an activity.
The amount available to obligate is the total budget (in the Action Plan) less the total currently obligated. This is not the same as the maximum obligation amount. The maximum amount that can be obligated is the amount available to obligate plus the amount currently obligated. The financial information provided on the “Add-edit obligation” screen is key to understanding the possible obligation amounts.
•The Activity Budget was set in the Action Plan at $1M.
•The Obligation can never exceed the Budget. The Obligation, as recorded in the Drawdown Module, thus far has been $500,000.
•The Total Activity Draw Amount can never exceed the Obligation which can never exceed the Budget. Total draws to date for the activity for both Program Funds and Program Income is $200,000.
<number>
<number>
<number>
<number>
Obligating Funds
<number>
Let’s obligate funds!
<number>
<number>
Program Income (PI)
•Purpose and Functionality of Updates (Release 7.3)
•Budgeting
•PI Receipts
•PI Accounts
<number>
18
18
18
18
Program Income (PI): Purpose of Updates
As of Release 7.3, the changes in DRGR now:
•allows Activity budgets and obligations to include estimated program income for budgeting to be more interactive.
•complies with the requirements for spending program income first.
•creates a means (called Program Income Accounts) that identifies organizations that a grantee allows to retain PI, and not return to the grantee, for their own uses.
•identifies each PI transaction rather than recording amounts quarterly as in the past.
•creates a means (at the Project level) for users to identify Revolving Loan Funds (RLF)
18
DRGR Release 7.3 made some significant changes to the way Program Income in reported and drawn in DRGR. This and the next few slides outline some of these changes.
19
19
19
19
PI: Functionality of Updates
Budgets: Add estimated PI at the grant level as a distinct line item. Add estimated PI as a component of the Project/Activity Budget.
Draws: To draw funds, DRGR requires all Program Income received in each RLF or PI account to be used before Program Funds. Similar rules apply to activities outside RLF and PI accounts (termed “General Account” for PI)
PI Account: Add and Edit/Search Program Income Accounts to identify activities with the organization they fund that are allowed to retain PI for their own uses.
PI Receipt: Create and Edit/Search Program Income Receipts to identify each PI transaction rather than recording amounts quarterly as in the past.
19
20
20
20
20
PI: Budgets at the Grant Level
Estimate the amount of Program Income the grant will receive over the grant. Re-evaluate regularly to ensure enough funds to accommodate project and activity budgets.
20
On the Action Plan page, you can now enter amount of PI or RLF the grant is estimated to generate. The estimation is done at all three phases of the budgeting in DRGR: at the Grant Level, for Projects, and Activities. These budgets should be re-evaluated periodically to ensure accuracy and to verify enough funds to accommodate Project and Activity budgets. The Grant level the only place that breaks out the PI or RLF, in the Project and Activity budgets it is entered as one sum amount (PF+PI).
At the grant level, for the Edit Action Plan screen, the Grant Amount is automatically loaded into DRGR when the grant is originally entered into the system. The Estimated PI/RL Funds is an editable line item. The Total Budget line sums the Grant Amount and Estimated PI/RL Funds; it provides the budget that the sum of the Project Budgets can not exceed.
21
21
21
21
PI: Budgets for Project/Activity
•Total Project and Activity budgets must include program funds and estimated program income.
•Re-evaluate regularly to ensure enough funds to accommodate project and activity budgets.
•Math Rules:
21
For Projects and Activities, a user includes estimated Program Income budget in the Total Budget.
<number>
<number>
<number>
<number>
PI Categories
PI will now be categorized as:
•General Account: Pool of all PI receipted that is not in any individual RLF or PI Account(s).
•PI Account(s): Separate accounts created by grantee to identify Activities under their funding agreements with their organizations that allow these organizations to RETAIN and use PI on their own Activities. In effect, PI Accounts allow users to “wall off” PI receipts for specific Activities.
•Revolving Loan Fund(s): Projects to identify activities of a single Activity type where loan repayments are used to fund new loans
<number>
•PI is receipted and disbursed by Activity, and each Activity is associated with either a PI Account (as set up by the user), a General PI Account (default account if an Activity has not been associated with a PI Account), or a RLF (identified by a Project).
•A Program Income Account is intended to help grantees use Program Income generated by one Activity or Responsible Organization towards the Activities managed by that same Responsible Organization, if the organization administering these activities is allowed to keep their Program Income. If this does not apply, grantees do not need to set up any program income accounts to work with program income.
•Prior to the set up of these accounts, all Activities will automatically fall into a General Account. Once the grantee if finished “walling off” activities for each Responsible Organization, there may only be the grantee Administration Activity left in the General Account.
<number>
<number>
<number>
<number>
PI Receipts
PI received is recorded in the Drawdown Module as a receipts for individual PI transactions
<number>
•Prior to Release 7.3, Program Income was receipted in the QPR quarterly and drawn in the Drawdown Module. Similar to IDIS, Release 7.3 allowed Program Income receipts to be created in the Drawdown Module for individual PI transactions.
•If the grantee has set up Program Income Accounts, the Program Income received will be associated with the Program Income Account the Activity belongs to. If there are no PI Accounts or RLF, it will automatically apply to the General Account
To Create a Receipt,
1.Select the grant
2.Create a Receipt Number, (there is no required naming convention)
3.Select the Activity that generated this PI
4.Enter the Amount and the Date Receipted
5.The Comment Field is optional, but can be helpful to keep track of PI sources.
6.Save
24
24
24
24
PI Accounts: Set-Up
•Established by Responsible Organization with, typically, all of the Activities associated with that Responsible Org. in their own PI Account.
•Program Income generated by an Activity in this account can only be used for itself or other Activities in that same account.
•Any Activities not assigned to a PI Account will remain in a General PI Account.
24
As the purpose of PI Accounts is to “wall off” PI from one organization from another, a grantee establishes PI Accounts by Responsible Organization.
NOTE: In other cases, states may require all PI to be returned from the local government to the state. It is important to remember that PI accounts do not need to be set up if local governments or subrecipients are not allowed to retain their PI.
25
25
25
25
Program Income Accounts: Set-up
25
•To set up a Program Income Accounts, go to the Drawdown Module and along the left navigation select Add PI Account.
•Select the grant and create a name for the account.
•Select the Responsible Organization. Key Hint: One Responsible Organization could have been entered into the system in a number of ways such as “The City of” or “City of”. To make sure you get all activities that are associated with that Responsible Organization the system allows the user to select multiple variations. Once this is selected, click Assign Org>>.
•Under Available Activities, check to make sure all of the activities for that Responsible Organization are appearing, then add the activities by clicking Assign Activities>>.
26
26
26
26
Program Income Accounts: Set UP
26
This slide shows what the screen for a new PI Account would look like just before saving. The Responsible Organization and its Activities have been moved into this account. The set up of this process is very similar to assigning and certifying users.
27
27
27
27
Program Income Accounts: Search/Edit
27
Grantees can search and edit PI Accounts as shown in the image on this slide.
28
28
28
28
Program Income Accounts: Review
This is an example of a grantee that has set up PI Accounts according to their responsible organizations. (Fin Report 05d)
28
This is a new report available in the DRGR Reports Module that will list all of the PI accounts set up by a grantee and the account’s associated budgets, PI disbursed, and PI balance.
If the grantee has not set up any PI accounts, and all PI is in the General Account, this report might not be available to them.
29
29
29
29
Program Income: Prior to Update
•Program Income recorded prior to the update was automatically turned into receipts based on the QPR and Activity in which it was entered.
•Activity Budgets and Obligations may have been automatically increased if PI was previously receipted through those activities.
•By using the Search/Edit Receipt function, grantees can modify previously recorded PI to be associated with another Activity.
(That Activity’s budget might first need to be increased)
29
30
30
30
30
Program Income Review (FinRept05b)
30
<number>
<number>
<number>
<number>
9. Create a Program Income Account & Estimate PI Budgets
10. Create a PI Receipt
<number>
Time for more Case Studies!
<number>
<number>
Program Income Review
•Activity budgets and obligations include estimated PI.
•Reinforces compliance with the FIFO requirements.
•Grantees can set up PI Accounts to allow their organizations to retain PI.
•PI is recorded in Drawdown module instead of QPR.
•Revolving Loan Funds (RLF) can be created at the Project Level.
<number>
<number>
<number>
Create/Approve Vouchers
Funds Drawn at Activity Level: Must have Request Drawdown role
Two Step Process for a Grantee
•Step 1: Create the voucher
–Must have Draw Requester Role
–Determine Program Funds v Program Income Funds
–Select Activities to draw from
•Step 2: Approve Voucher
–Must have Draw Approval role to approve
–Approve / Reject entire voucher
–Approve / Reject on line item basis
–Provide comments
<number>
Drawing down funds against the line of credit requires the creation and approval of a voucher in DRGR. These are two separate steps: 1) Creating the Voucher, and 2) Approving the Voucher.
Each voucher is composed of at least one line item. A line item represents funds going to a specific activity. A voucher may include more than one line item.
It is best to think of a voucher as a single request “packet.” It “asks” LOCCS to reimburse $X against the line of credit for a grant, for costs associated with a specific activity(ies). The voucher may also communicate that certain costs are being paid for with program income received by the grantee.
Remember that the user must have the appropriate permission to either create or approve vouchers and that the same user may not have both permissions.
To create a voucher, you must know which activities you are drawing against and the funding source (program funds or program income).
Vouchers may be approved or rejected at the voucher or line item level. Approvers may also provide comments.
Remember the math rules of DRGR (see slide 104-105).
34
34
34
34
Create/Approve Vouchers: Roles
34
View a Voucher Line Item | Approve/Reject a Voucher Line Item | Revise a Voucher Line Item | Cancel Voucher Line Item | Revoke Approval of a Voucher Line Item | |
ALL | X | ||||
Draw Requester | X | X | X | ||
Draw Approve | X | X | X |
This slide depicts which user roles (permissions) can perform a particular function within the drawdown module.
•Any user can search for a voucher and view its status. What you can do with a voucher also depends on your role in the DRGR system.
•For most functions associated with a voucher, you will have to search for the voucher first and then click “Maintain” for options on what you can do with it.
<number>
<number>
Create/Approve Vouchers: Daily Draw Thresholds
<number>
HUD may place limits on the daily draw amount in DRGR. If the drawdown pushes the grantee over the daily threshold limit, the voucher will not be processed automatically and it will be given an “Approved Pending HQ” status. These draw thresholds are daily limits per draw, so once a grantee has gone over their threshold for the day, all vouchers submitted after the threshold has been exceeded will be held pending HQ approval.
In cases in which the daily limit is exceeded, the grantee must submit back up documentation to their CPD/NSP field representative. It is always best to anticipate when you may submit a draw that will be over the daily draw threshold. You can then submit documentation to the Field Office in advance of creating the voucher.
In most cases, the system will notify the CPD/NSP field representative assigned to the grant by email that there is a draw that must be reviewed. Grantees should not, however, rely on the system to notify the Field Office when such vouchers are created.
HUD’s goal is to ensure that all draw requests are turned around with 72 hours. To meet this goal, CPD representatives and grantees should be in close communication about the creation and approval of these vouchers.
The CPD/NSP field representative will be looking for the following in the voucher documentation:
•Evidence of the grantee’s internal controls in approving the draw — this usually means two signatures/initials/electronic confirmations;
•Basic math — the draw documentation adds up to the amount requested; and
•The draw documentation is for the same activity shown on the DRGR voucher.
Once the CPD/NSP representative confirms the above information, they can send the confirmation to HQ, which should include the voucher number(s), amount of the draw, and the grant number. Once HQ receives the confirmation from the field, they will approve the draw. Jim Yerdon and Ryan Flanery are approving threshold draws for NSP, so representatives should send this information to them at [email protected] and [email protected]
<number>
<number>
<number>
<number>
Create/Approve Vouchers:
Block Draws
•Draws can be blocked
–at the grant and activity level by HUD (see next slide) or
–at the activity level by the Grantee Admin
•Communicate with FO if draw is blocked by HUD
•Check for Restricted Balance projects
<number>
There are several ways to block draws from occurring – either by the FO or by the grantee.
•For HUD staff, draws may be blocked at the grant level or per activity.
•For grantees, draws may be blocked per activity by the Grantee Administrator.
A grantee should call their FO Rep to discuss if, at the grant level or per activity, draws are blocked. Additionally, if any funds are in the restricted balance project, check with the FO.
37
37
37
37
Blocked Draws – Grant Level
37
Here is the screen that shows if a grant is blocked for draws. You can navigate here by clicking on your Grant Number from the Action Plan screen.
<number>
<number>
<number>
<number>
Blocked Draws – Activity Level
<number>