KRA 1.0 User Guide

Kuali Research Administration v.1.
0
User Guide
July, 2008 By The Kuali Foundation, Inc.
Kuali Research Administration v.1.0 User Guide Contents iii
Contents
Preface 1
Introduction..........................................................................................................................1
Kuali Communities Overview .................................................................................1
KRA Development Timeline...................................................................................6
Prerequisites............................................................................................................6
Principal Technical Author and Editor .....................................................................7
Contributors and Reviewers.....................................................................................7
About This Documentation......................................................................................7
How To Use The User Documentation.....................................................................9
Getting Help With Help.........................................................................................11
Copyright and Licensing.....................................................................................................12
Software Licensing................................................................................................12
Documentation Licensing......................................................................................14
KRA Overview 16
Kuali ..................................................................................................................................16
Key Components...................................................................................................16
Access ................................................................................................................................18
Roles ....................................................................................................................20
Logging In and Out ...............................................................................................26
Screen Anatomy, Navigation and Tools...............................................................................30
Screen Layout & Navigation .................................................................................30
Selection, Entry & Action Tools............................................................................34
E-Doc Fundamentals.............................................................................................54
Common E-Doc Operations ................................................................................................66
Initiating a Document............................................................................................66
Copying a Document.............................................................................................67
Saving a Document ...............................................................................................68
Reloading a Page...................................................................................................69
Closing a Document ..............................................................................................69
Canceling a Document ..........................................................................................70
Routing a Document..............................................................................................70
Searching for a Document .....................................................................................71
Using the Action List ............................................................................................74
Common Line Item Operations..............................................................................75
Summary ..............................................................................................................75
Common Maintenance Document Operations......................................................................76
Overview..............................................................................................................76
Searching for a Maintenance Document.................................................................79
Initiating a Maintenance Document .......................................................................80
Editing a Maintenance Document ..........................................................................81
Copying a Maintenance Document ........................................................................83
Submitting a Maintenance Document ....................................................................84
Saving a Maintenance Document...........................................................................85
iv Contents Kuali Research Administration v.1.0 User Guide
Closing a Maintenance Document .........................................................................85
Canceling a Maintenance Document......................................................................86
Maintenance Document Rules & Routing..............................................................86
Summary ..............................................................................................................87
Researcher Menu 88
Proposals Menu Group........................................................................................................90
Quick Links Menu Group ...................................................................................................90
Workflow Menu Group.......................................................................................................91
Unit Menu 92
Pre-Award Menu Group......................................................................................................93
Proposal Development Add Button........................................................................93
Quick Links Menu Group ...................................................................................................94
Workflow Menu Group.......................................................................................................94
Central Admin Menu 96
Maintenance Menu 97
Shared Menu Group.......................................................................................................... 100
Miscellaneous Menu Group .............................................................................................. 102
Proposals Menu Group...................................................................................................... 103
System Admin Menu 105
System Menu Group......................................................................................................... 106
Workflow Menu Group..................................................................................................... 106
Proposal Development Document 108
Overview.......................................................................................................................... 108
Access ................................................................................................................ 109
Document Header Proposal .............................................................................. 110
Pages Overview.................................................................................................. 111
Proposal Page................................................................................................................... 112
Document Overview Tab..................................................................................... 112
Required Fields for Saving Document Tab........................................................... 113
Sponsor & Program Information Tab................................................................... 114
Organization/Location Tab.................................................................................. 116
Delivery Info Tab................................................................................................ 117
Keywords Tab..................................................................................................... 117
Budget Versions Page....................................................................................................... 120
Budget Versions Tab........................................................................................... 120
Key Personnel Page .......................................................................................................... 122
Add Key Personnel ............................................................................................. 122
Person Name Tab............................................................................................. 123
Key Personnel Page Actions................................................................................ 127
Special Review Page......................................................................................................... 128
Special Review Tab............................................................................................. 128
Custom Data Page............................................................................................................. 130
Tabbed Page Section Examples ........................................................................... 130
Required Fields................................................................................................... 131
Custom Data Page Process .................................................................................. 131
Kuali Research Administration v.1.0 User Guide Contents v
Questions Page ................................................................................................................. 132
Tabbed Page Section Examples ........................................................................... 132
Questions Page Process ....................................................................................... 133
Permissions Page.............................................................................................................. 134
Assigned Roles Tab............................................................................................. 134
Users Tab............................................................................................................ 135
Abstracts and Attachments Page........................................................................................ 138
Proposal Attachments Tab................................................................................... 138
Personnel Attachments Tab................................................................................. 140
Internal Attachments Tab .................................................................................... 141
Abstracts Tab...................................................................................................... 142
Notes and Attachments Tab................................................................................. 143
Grants.gov Page................................................................................................................ 144
Grants.gov Tab.................................................................................................... 144
Opportunity Search Section................................................................................. 145
Opportunity Section ............................................................................................ 146
Submission Details Section ................................................................................. 147
Forms Section..................................................................................................... 147
Proposal Actions Page ...................................................................................................... 149
Data Validation Tab............................................................................................ 149
Print Forms Tab .................................................................................................. 151
Copy to New Document Tab ............................................................................... 152
Ad Hoc Recipients Tab ....................................................................................... 154
Route Log Tab.................................................................................................... 154
Proposal Actions Page Action.............................................................................. 155
Proposal Document Routing................................................................................ 156
Budget Document 157
Overview.......................................................................................................................... 157
Access ................................................................................................................ 157
Document Header ............................................................................................... 158
Pages Overview.................................................................................................. 159
Return To Proposal Navigation............................................................................ 159
Budget Versions Page....................................................................................................... 161
Summary Page.................................................................................................................. 163
Budget Overview Tab ......................................................................................... 163
Budget Periods & Totals Tab............................................................................... 165
Summary Page Actions ....................................................................................... 166
Rates Page........................................................................................................................ 167
Page Layout ........................................................................................................ 167
Select View......................................................................................................... 168
Research F&A Tab.............................................................................................. 168
Fringe Benefits Tab............................................................................................. 170
Inflation Tab....................................................................................................... 171
Vacation Tab....................................................................................................... 173
Lab Allocation Salaries Tab.............................................................................. 173
Lab Allocation - Other ........................................................................................ 174
Other Tab............................................................................................................ 174
Unique Page Actions........................................................................................... 174
Project Personnel .............................................................................................................. 176
Page Overview.................................................................................................... 176
Add Project Personnel ......................................................................................... 177
Budget Personnel Tab ......................................................................................... 177
Expenses Page.................................................................................................................. 179
Page Layout ........................................................................................................ 180
vi Contents Kuali Research Administration v.1.0 User Guide
Select Budget Period & Item Type....................................................................... 181
Budget Overview Tab ......................................................................................... 181
Personnel Tab ..................................................................................................... 182
Expenses Page Tabs ............................................................................................ 185
Unique Actions ................................................................................................... 188
Totals Page....................................................................................................................... 189
Totals Tab........................................................................................................... 189
Distribution & Income Page.............................................................................................. 191
Select Budget Period........................................................................................... 191
Cost Sharing Tab................................................................................................. 192
Unrecovered F&A Tab........................................................................................ 193
Project Income Tab............................................................................................. 195
Unique Actions ................................................................................................... 196
Modular Budget Page ....................................................................................................... 197
Page Layout ........................................................................................................ 198
Select Modular Budget Period............................................................................. 198
Modular Budget Overview Tab ........................................................................... 199
Direct Cost Tab................................................................................................... 199
F&A Tab ............................................................................................................ 200
Unique Action..................................................................................................... 201
Budget Actions Page......................................................................................................... 202
Print Forms Tab .................................................................................................. 202
Budget Justification Tab...................................................................................... 203
Budget Actions Page Process Overview............................................................... 204
Proposal & Budget Completion Process 205
Maintenance Documents 211
Abstract Type Maintenance Document.............................................................................. 212
Document Layout................................................................................................ 212
Edit Abstract Types Tab...................................................................................... 213
Examples ............................................................................................................ 214
Activity Type Maintenance Document .............................................................................. 215
Document Layout................................................................................................ 215
Edit Activity Types Tab ...................................................................................... 216
Process................................................................................................................ 216
Example.............................................................................................................. 216
Budget Category Maintenance Document.......................................................................... 217
Document Layout................................................................................................ 217
Edit Budget Category Tab ................................................................................... 218
Process................................................................................................................ 218
Example.............................................................................................................. 219
Budget Category Mapping Maintenance Document ........................................................... 220
Document Layout................................................................................................ 220
Edit Budget Category Mapping Tab..................................................................... 220
Process................................................................................................................ 221
Examples ............................................................................................................ 221
Budget Category Maps Maintenance Document ................................................................ 222
Document Layout................................................................................................ 222
Edit Budget Category Maps Tab.......................................................................... 223
Process................................................................................................................ 223
Examples ............................................................................................................ 224
Budget Category Type Maintenance Document ................................................................. 225
Document Layout................................................................................................ 225
Kuali Research Administration v.1.0 User Guide Contents vii
Edit Budget Category Types Tab......................................................................... 226
Process................................................................................................................ 226
Examples ............................................................................................................ 226
Budget Status Maintenance Document .............................................................................. 227
Document Layout................................................................................................ 227
Edit Budget Status Tab........................................................................................ 227
Process................................................................................................................ 228
Examples ............................................................................................................ 228
Cost Element Maintenance Document ............................................................................... 229
Document Layout................................................................................................ 229
Edit Cost Element Tab ........................................................................................ 229
Process................................................................................................................ 230
Examples ............................................................................................................ 231
Country Maintenance Document ....................................................................................... 232
Examples ............................................................................................................ 232
Current Locks................................................................................................................... 233
Custom Attribute Maintenance Document ......................................................................... 237
Document Layout................................................................................................ 237
Edit Custom Attribute Tab................................................................................... 238
Process................................................................................................................ 238
Examples ............................................................................................................ 239
Custom Attribute Document Maintenance Document ........................................................ 240
Document Layout................................................................................................ 240
Edit Custom Attribute Document Tab.................................................................. 241
Process................................................................................................................ 241
Examples ............................................................................................................ 241
Deadline Type Maintenance Document ............................................................................. 242
Document Layout................................................................................................ 242
Edit Deadline Type Codes Tab............................................................................ 243
Process................................................................................................................ 243
Examples ............................................................................................................ 243
Degree Type Maintenance Document................................................................................ 244
Document Layout................................................................................................ 244
Edit Degree Type Tab ......................................................................................... 244
Process................................................................................................................ 245
Examples ............................................................................................................ 245
Exemption Type Maintenance Document .......................................................................... 246
Document Layout................................................................................................ 246
Edit Exemption Type Codes Tab ......................................................................... 247
Process................................................................................................................ 247
Examples ............................................................................................................ 247
Institute LA Rate Maintenance Document ......................................................................... 248
Document Layout................................................................................................ 248
Edit Institute LA Rates Tab................................................................................. 249
Examples ............................................................................................................ 250
Institute Rate Maintenance Document ............................................................................... 251
Document Layout................................................................................................ 251
Edit Institute Rates Tab....................................................................................... 252
Examples ............................................................................................................ 253
Investigator Credit Type maintenance document................................................................ 254
Document Layout................................................................................................ 254
Specify the Credit Type Tab................................................................................ 255
Process................................................................................................................ 255
Examples ............................................................................................................ 255
Keyword Maintenance Document ..................................................................................... 256
Document Layout................................................................................................ 256
viii Contents Kuali Research Administration v.1.0 User Guide
Edit Science Keywords Tab................................................................................. 257
Examples ............................................................................................................ 257
Mail By Maintenance Document ....................................................................................... 258
Document Layout................................................................................................ 258
Edit Mail Bys Tab............................................................................................... 258
Examples ............................................................................................................ 259
Mail Type Maintenance Document.................................................................................... 260
Document Layout................................................................................................ 260
Edit Mail Types Tab............................................................................................ 260
Examples ............................................................................................................ 261
Narrative Status Maintenance Document ........................................................................... 262
Document Layout................................................................................................ 262
Edit Narrative Status Tab .................................................................................... 263
Examples ............................................................................................................ 263
Narrative Type Maintenance Document ............................................................................ 264
Document Layout................................................................................................ 264
Edit Narrative Types Tab .................................................................................... 265
Examples ............................................................................................................ 266
Notice of Opportunity Maintenance Document.................................................................. 267
Document Layout................................................................................................ 267
Edit Notice of Opportunity Tab ........................................................................... 268
Examples ............................................................................................................ 268
NSF Science Code Maintenance Document....................................................................... 269
Document Layout................................................................................................ 269
Edit NSF Codes Tab............................................................................................ 270
Examples ............................................................................................................ 271
Object Code Maintenance Document ................................................................................ 272
Document Layout................................................................................................ 272
Edit Cost Element Tab ........................................................................................ 272
Process................................................................................................................ 273
Examples ............................................................................................................ 273
Organization Maintenance Document................................................................................ 274
Document Layout................................................................................................ 274
Edit Organization Tab......................................................................................... 276
Organization Type Tab........................................................................................ 278
Organization Audit Tab....................................................................................... 278
Organization Indirectcost Tab.............................................................................. 279
Organization Ynq Tab......................................................................................... 279
Example.............................................................................................................. 280
Organization Type Maintenance Document ....................................................................... 281
Document Layout................................................................................................ 281
Edit Organization Type List Tab.......................................................................... 281
Examples ............................................................................................................ 282
Person Degree Maintenance Document ............................................................................. 283
Document Layout................................................................................................ 283
Edit Person Degree Tab....................................................................................... 283
Person Document Type Maintenance Document................................................................ 285
Document Layout................................................................................................ 285
Edit Person Document Type Tab ......................................................................... 286
Examples ............................................................................................................ 286
Person-Role Maintenance Document................................................................................. 287
Edit Person-Role Tab .......................................................................................... 287
Examples ............................................................................................................ 289
Person Table Editable Columns Maintenance Document ................................................... 290
Document Layout................................................................................................ 290
Specify the Field Name Tab ................................................................................ 291
Kuali Research Administration v.1.0 User Guide Contents ix
Examples ............................................................................................................ 292
Proposal Columns To Alter Maintenance Document.......................................................... 293
Edit Proposal Columns To Alter Tab................................................................... 293
Examples ............................................................................................................ 294
Proposal Type Maintenance Document.............................................................................. 296
Document Layout................................................................................................ 296
Edit Proposal Type Codes Tab............................................................................. 297
Examples ............................................................................................................ 297
Questions Maintenance Document .................................................................................... 298
Document Layout................................................................................................ 298
Ynq Explanation Tab .......................................................................................... 299
Examples ............................................................................................................ 301
Rate Class Maintenance Document ................................................................................... 302
Document Layout................................................................................................ 302
Edit Rate Class Tab............................................................................................. 302
Examples ............................................................................................................ 303
Rate Class Type Maintenance Document........................................................................... 304
Document Layout................................................................................................ 304
Edit Rate Class Types Tab................................................................................... 305
Examples ............................................................................................................ 305
Rate Type Maintenance Document.................................................................................... 306
Document Layout................................................................................................ 306
Edit Rate Type Tab ............................................................................................. 306
Examples ............................................................................................................ 307
Role Maintenance Document ............................................................................................ 308
Edit Tabs ............................................................................................................ 308
Process................................................................................................................ 310
Examples ............................................................................................................ 311
Role-Permission Maintenance Document .......................................................................... 312
Edit Role-Permission Tab.................................................................................... 312
Process................................................................................................................ 313
Examples ............................................................................................................ 314
Rolodex Maintenance Document....................................................................................... 315
Document Layout................................................................................................ 315
Edit Rolodex Tab................................................................................................ 316
S2S Revision Type Maintenance Document ...................................................................... 319
Document Layout................................................................................................ 319
Edit S2S Revision Type Tab................................................................................ 320
Examples ............................................................................................................ 320
S2S Submission Type Maintenance Document .................................................................. 321
Document Layout................................................................................................ 321
Examples ............................................................................................................ 321
NSF Science Code Maintenance Document....................................................................... 322
Document Layout................................................................................................ 322
Edit NSF Codes Tab............................................................................................ 322
Examples ............................................................................................................ 323
Special Review Maintenance Document............................................................................ 324
Document Layout................................................................................................ 324
Edit Special Review Codes Tab........................................................................... 324
Examples ............................................................................................................ 325
Special Review Approval Type Maintenance Document.................................................... 326
Document Layout................................................................................................ 326
Edit Special Review Approval Type Codes.......................................................... 327
Examples ............................................................................................................ 327
Sponsor Maintenance Document ....................................................................................... 328
Edit Sponsor Tab................................................................................................. 329
x Contents Kuali Research Administration v.1.0 User Guide
Process................................................................................................................ 330
Examples ............................................................................................................ 330
Sponsor Forms Maintenance Document ............................................................................ 331
Edit Sponsor Forms Tab...................................................................................... 331
Process................................................................................................................ 332
Examples ............................................................................................................ 332
Sponsor Form Templates Maintenance Document ............................................................. 333
Edit Sponsor Form Templates Tab....................................................................... 333
Process................................................................................................................ 334
Examples ............................................................................................................ 334
Sponsor Type Maintenance Document .............................................................................. 335
Document Layout................................................................................................ 335
Edit Sponsor Types Tab ...................................................................................... 335
State Maintenance Document............................................................................................ 337
Document Layout................................................................................................ 337
Edit State Tab ..................................................................................................... 337
Examples ............................................................................................................ 338
TBN Person Maintenance Document................................................................................. 339
Document Layout................................................................................................ 339
Examples ............................................................................................................ 340
Unit Administrator Maintenance Document....................................................................... 341
Edit Unit Administrator Tab................................................................................ 341
Process................................................................................................................ 342
Examples ............................................................................................................ 342
Unit Maintenance Document............................................................................................. 343
Edit Unit Tab ...................................................................................................... 343
Process................................................................................................................ 344
Examples ............................................................................................................ 344
Unit Hierarchy.................................................................................................................. 345
Valid Calculation Type Maintenance Document................................................................ 346
Document Layout................................................................................................ 346
Edit Valid Calc Types Tab .................................................................................. 347
Examples ............................................................................................................ 348
Valid Cost Element Rate Type Maintenance Document ..................................................... 349
Document Layout................................................................................................ 349
Edit Valid Cost Element Rate Types Tab............................................................. 350
Examples ............................................................................................................ 350
Valid Special Review Approval Maintenance Document ................................................... 351
Document Layout................................................................................................ 351
Edit Valid Special Review Approval Tab............................................................. 351
Examples ............................................................................................................ 352
Kuali Enterprise Workflow 353
Route Levels..................................................................................................................... 353
Workflow Routing .............................................................................................. 354
Ad Hoc Routing.................................................................................................. 354
Viewing Route Levels ......................................................................................... 356
Routing Rules................................................................................................................... 359
Route Log........................................................................................................... 359
Route Status........................................................................................................ 363
Rule Templates and Attributes............................................................................. 364
KEW Operations............................................................................................................... 366
Action List.......................................................................................................... 366
Workflow Action Buttons.................................................................................... 367
Preferences ......................................................................................................... 368
Kuali Research Administration v.1.0 User Guide Contents xi
Action List Filter................................................................................................. 370
Document Search................................................................................................ 372
Setting Up Workflow........................................................................................................ 376
Routing Report.................................................................................................... 377
Rules .................................................................................................................. 378
Rule QuickLinks................................................................................................. 381
Workgroup.......................................................................................................... 387
System Administration...................................................................................................... 394
Parameter............................................................................................................ 395
Person................................................................................................................. 398
Workflow Configuration and Monitoring .......................................................................... 400
Application Constants ......................................................................................... 401
Document Operation ........................................................................................... 402
Document Type................................................................................................... 408
Rule Attribute ..................................................................................................... 410
Rule Template..................................................................................................... 412
Statistics Report .................................................................................................. 413
Workgroup Type................................................................................................. 415
XML Ingester...................................................................................................... 416
Glossary of Terms 419
Kuali Research Administration v.1.0 User Guide Preface 1
Preface
Introduction
The Kuali Research Administration (KRA) system is a community-source software application system developed by and
for higher education institutions to serve their research administration software needs. In this topic you will find a brief
overview of the Kuali Foundation and its communities (of which one is KRA), information pertaining to the purpose
and usage of this documentation, and a summary of related copyright and licensing information.
Kuali Communities Overview
As an introduction to the KRA user documentation, it is helpful to understand how KRA is a community within the
larger Kuali community before you begin to use this as a reference to assist you in learning how to use the KRA system.
2 Preface Kuali Research Administration v.1.0 User Guide
Figure 1 Kuali Communities
The Kuali Community is the hub of a wheel of a growing number of communities, each of which is made up of people
and functions. Together they form a comprehensive suite of open, modular and distributed administrative software
systems that bring the proven functionality of legacy applications to the ease and universality of online services. The
Kuali Foundation serves them all, with specific responsibilities related to keeping the wheel in motion. Each individual
community shares a similar organizational structure and some modular functionality while its components are able to
stand alone to perform unique functions. While all are designed for seamless integration with each other, each project is
made up of modules that offer a variety of implementation combinations to suit any Carnegie-class institutions unique
business needs.
Table 1 Kuali Community Personnel and Functions
Community Name Personnel Functions
Kuali
Community
Kuali Foundation
(KF)
Board of Directors,
Partner Institutions,
Commercial
Affiliates,
Technical Council
Collaboration Infrastructure, Copyright Holding, Licensing,
Resource Planning,, Documentation, Bug Tracking, Legal
Services, User Support
Financial
Community
Kuali Financial
System (KFS)
Project Board,
Project
Management,
Functional Council,
Development
Teams, Subject
Matter Experts
Financial Transactions, General Ledger, Chart of Accounts,
Reporting/Decision Support, Contracts & Grants,
Purchasing/Accounts Payable, Labor Distribution, Budget,
Accounts Receivable, Capital Assets
Research
Community
Kuali Research
Administration
(KRA)
Project Board,
Project
Management,
Functional Council,
Development
Teams, Subject
Matter Experts
Proposal Development, Budget Development, Routing Form,
Grants.gov Integration, Institutional Review Board (IRB) /
Human Subjects, Awards, Conflict of Interest
Kuali
Infrastructure
Community
Kuali Rice (KR) Development Team Kuali Nervous System (KNS), Kuali Service Bus (KSB), Kuali
Enterprise Notification (KEN), Kuali Enterprise Workflow
(KEW), Kuali Identify Management (KIM)
Endowment
Community
Kuali Endowment
Management
(KEM)
Project Board,
Project
Management,
Functional Council,
Development
Teams, Subject
Matter Experts
Investment tracking & reporting, investment participation
(endowment and non-endowment) management and reporting
including unitized transaction, budgeted and actual income
projections (pooled funds and separately invested holdings),
access to donor instructions, manage available funds with
searchable data elements describing the terms of use.
Student
Community
Kuali Student
(KS)
Functional Steering
Committee,
Technical Steering
Committee
Person, Time, Learning Unit, Learning Result, Learning Plan,
Learning Resources, Concierge
Figure 2 Kuali Organization
The following list briefly describes each of the major communities that make up the larger Kuali community:
Kuali Foundation (KF): Employs staff to coordinate partner efforts and to manage and protect the
Foundations intellectual property. The Kuali Foundation manages a growing portfolio of enterprise software
applications for colleges and universities. A lightweight Foundation staff coordinates the activities of
Foundation members for critical software development and coordination activities such as source code control,
release engineering, packaging, documentation, project management, software testing and quality assurance,
conference planning, and educating and assisting members of the Kuali Partners program.
Kuali Partners Program (KPP): The Kuali Partners Program (KPP) is the means for organizations to get
involved in the Kuali software community and influence its future through voting rights to determine software
development priorities. Membership dues pay staff to perform Quality Assurance (QA) work, release
engineering, packaging, documentation, and other work to coordinate the timely enhancement and release of
quality software and other services valuable to the members. Partners are also encouraged to tender functional,
technical, support or administrative staff members to the Kuali Foundation for specific periods of time.
Kuali Commercial Affiliates (KCA): A designation provided to commercial affiliates who become part of the
Kuali Partners Program to provide for-fee guidance, support, implementation, and integration services related to
the Kuali software. Affiliates hold no ownership of Kuali intellectual property, but are full KPP participants.
Affiliates may provide packaged versions of Kuali that provide value for installation or integration beyond the
basic Kuali software. Affiliates may also offer other types of training, documentation, or hosting services.
Kuali Technical Council (KTC): Sets development standards and processes, ensures compliance with
established standards and procedures among contributors. Responsible to the Kuali Foundation Board for the
technical success of the project, the KTC is an operationally-representative group of technical leaders who work
with project managers and other operational leadership to implement sustainable practices that ensure software
quality by ensuring there is an effective balance between a sound architecture, and the meeting of both project
deadlines and functional requirements.
Functional Councils: Provide overall project guidance related to the identification and prioritization of
business practices and functionality requirements to be developed by each software application project.
Comprised of senior administrators from core Kuali institutions, members serve as primary functional subject
matter experts who communicate functional specifications to development teams.
Project Boards: Provide management and oversight of the business and affairs of the project, including
management of assets and resource allocation. The Board of Directors for a Kuali community project establish
and maintain the processes of coordination determined to be necessary to support the development and release
of the Kuali software. Further, the project boards act as a court of final appeal for Discussion, Work Groups,
and collaborative member activities of the project.
Kuali Rice (KR): Provides an enterprise-class middleware suite of integrated products that allow both Kuali
and non-Kuali applications to be built in an agile fashion, such that developers are able to react to end-user
business requirements in an efficient manner to produce high-quality business applications. Built with Service
Oriented Architecture (SOA) concepts in mind, KR enables developers to build robust systems with common
enterprise workflow functionality, customizable and configurable user interfaces with a clean and universal look
and feel, and general notification features to allow for a consolidated list of work "action items." All of this adds
up to providing a re-usable development framework that encourages a simplified approach to developing true
business functionality as modular applications.
Kuali Financial System (KFS): Delivers a comprehensive suite of functionality to serve the financial system
needs of all Carnegie-Class institutions. An enhancement of the proven functionality of Indiana Universitys
Financial Information System (FIS), KFS meets GASB and FASB standards while providing a strong control
environment to keep pace with advances in both technology and business. Modules include financial
transactions, general ledger, chart of accounts, reporting/decision support, contracts and grants,
purchasing/accounts payable, labor distribution, budget, accounts receivable and capital assets.
Kuali Endowment Management (KEM): Delivers a means to account for your institutions endowment funds
(and similarly invested long-term funds) and their corresponding investments, transactions, obligations, and the
underlying funds to which those assets and liabilities belong. Based on the functionality of the IU Foundation
Endowment and Trust Accounting (ETA) System, KEM is a re-engineering effort that adheres to the Kuali
Architecture and Standards. The application includes investment tracking and reporting, investment
participation (endowment and non-endowment) management and reporting including unitized transaction,
budgeted and actual income projections (pooled funds and separately invested holdings), access to donor
instructions, beneficiary disbursement process and information (tax) reporting, management of available funds
with searchable data elements describing the terms of use.
Kuali Student (KS): Delivers a means to support students and other users with a student-centric system that
provides real-time, cost-effective, scalable support to help them identify and achieve their goals while
simplifying or eliminating administrative tasks. The high-level entities of person (evolving roles-student,
instructor, etc.), time (nested units of time semesters, terms, classes), learning unit (assigned to any learning
activity), learning result (grades, assessments, evaluations), learning plan (intentions, activities, major, degree),
and learning resources (instructors, classrooms, equipment). The concierge function is a self-service
information sharing system that aligns information with needs and tasks to accomplish goals. The support for
integration of locally-developed processes provides flexibility for any institutions needs.
KRA Development Timeline
Figure 3 KRA Development Timeline
Kuali Research Administration (KRA): Delivers a means to administer your institutions research information,
improve access to research information, and enhance support for research compliance. Based on the functionality of
MITs Coeus system, KRA is a re-engineering effort that adheres to the Kuali Architecture and Standards while filling in
missing functionality. The application includes Proposal & Budget Development, Routing Form, Grants.gov Integration,
Institutional Review Board (IRB) / Human Subjects, Awards, Conflict of Interest, Institute Proposal / Negotiations,
Report Tracking, Subcontracts, Cost Share Commitment Tracking, Animal Care and Use, Bio-Safety Management,
Subrecipient Monitoring, Export Controls / ITAR Management, and Chemical Tracking System.
For a more detailed description of KRA software, see KRA Overview.
Prerequisites
There are no specific prerequisites for reading this document. However, it will be helpful if you have the following
qualifications:
Basic familiarity with your institutions research administration business rules and practices
Working experience with Web-based software application systems
We recommend that you visit http://www.kuali.org for a general orientation, and strongly encourage you to take a test
drive of the demonstration version of KRA that is accessible from this site. It not only allows you to preview the KRA
functionality, but more importantly, it gives you the opportunity to practice using the software, which helps to reinforce
the concepts and skills introduced in this documentation.
KRA User Documentation and Online Help is not meant to take the place of on-the-job training on your
institutions research administration policies, procedures and tasks. KRA is a tool you will use to accomplish a
portion of those tasks, but this documentation is not intended to train you how research administration activities
happen at your institution. Although it covers enough of the very general principles of online research
administration to instruct you how to use the software, it does not take into account which users with which job
duties use which screens to perform which tasks this is the responsibility of your unit or department within the
organization. KRAs flexibility for configuration and customization dictates that it is the responsibility of your
institution to educate you about its unique implementation of KRA.
Principal Technical Author and Editor
Scott Cooley, Michigan State University (Kuali Foundation Project Staff )
Contributors and Reviewers
Peter Asquith, Michigan State; Damon Dorsey, Indiana; Dan Dwyer, Cornell; Kenton Hensley, Cornell; Phil
McKown, Indiana; Lora OConnor, Indiana; Lisa Oliva, Michigan State; Lori Schultz, Arizona; Keiko Takahashi,
rSmart; Teresa Thomas, Michigan State.
About This Documentation
This guide is designed to assist with efficient usage of the system by describing and demonstrating the tools that come
with it, including a walk through of:
Basic screen navigation
Action options
Using the software to accomplish tasks
Electronic document and workflow routing
The table of contents is organized according to the screens and action options in the software, allowing you to efficiently
locate specific information. All KRA documentation, whether printed or online, is meant to demonstrate how the system
works and thus serves as a helpful desk reference during day-to-day system usage. Once familiar with the basic
functionality of the KRA, you can use this guide as a valuable tool for less common tasks, and as an excellent source of
information should you experience any difficulties.
Scope
This guide covers how to use the KRA software application system. This guide does not cover the requirements, design,
build, testing, installation, configuration, customization, implementation, administration or maintenance of the KRA
application. Some configuration, administration and maintenance features that are accessible via the user interface are
briefly covered, but full details and behind-the-scenes information should be obtained from the KRA Technical
Documentation, access information to which appears on kuali.org.
Description
KRA User Documentation provides high-quality descriptions of how the software system interacts and performs with
manual procedures in order to appropriately respond to business events. These user assistance materials are aimed at not
only providing user guides and online help for implementing institutions, but also at providing a basis for the training
of new system users. They also contain descriptions of the detailed functionality of each component of the application,
and may thus serve as a reference for users who are already quite familiar with research administration and web-based
software.
Audience
The audience is all users of KRA, however, the focus is on standard end users rather than those involved in configuration
and maintenance. Administrator and Superuser functions are also covered, but not in great detail. These user types, as
well as implementation specialists, and those seeking information about installation, customization, configuration,
implementation, workflow, system administration and maintenance should consult the KRA Technical Documentation
resources that are accessible from www.kuali.org. Additionally, you may refer to Technical Documentation on the KRA
wiki for more detailed information resources.
The term end user is meant to differentiate software developers from the users of the programs they write, and similarly,
for information technology professionals to distinguish the system administrator from the users of computers for which
the administrator is responsible. The Administration topics in this documentation cover use of Maintenance Documents
used for maintaining reference tables used in system administration only.
For more detailed descriptions of types of users of KRA software, see Roles in KRA Overview.
Types of Documentation Included
Interspersed throughout you will find the following three basic types of user documentation (typically appearing in this
general-to-specific order):
Conceptual documentation includes reference and overview information that is used to support user
understanding. It documents guidelines that: 1) enhance the completion of a task and 2) are best maintained
independently so as not to interrupt the flow of learning. It does not provide how-to instruction, is not
sequential, and is often in the form of a table. It often appears as a paragraph or two at the very beginning of a
topic, or sometimes at the end of a printed user guide in the form of appendices.
Process documentation contains high-level overviews of process steps and flow charts. It is necessary only if
the activity 1) is complex, 2) involves risk, or 3) must be performed in a consistent manner. It details sequential
actions written as a series of tasks; and may involve multiple departments and/or users. This type of content
usually contains overview information and business rules.
Task documentation contains specific, detailed instructions with notes and action results that guide you through
screen navigation to accomplish tasks. These often appear as numbered (ordered) lists of steps. It is necessary
only when the use of the system involves a task that: 1) involves user input action (data entry) by a single
performer, 2) is complex, 3) involves risk, 4) must be performed in a consistent manner, 5) is best documented
as a separate, stand-alone topic, and/or 6) when the task detail is referenced in multiple procedures or is subject
to frequent change.
Screen Images and Test Data
Screen images (and data displayed therein) may not be technically identical to what can be viewed in the actual
application, and are provided for demonstration purposes only.
Institutional Business Processes and KRA Implementation
Various components of KRA modules contain functions that are configurable prior to implementation, based on
individual institutional business processes. KRA is delivered with a set of data elements; some of which come with pre-
populated (hard-coded) values, while others are configurable by institution. These may include, but are not limited to,
administrative, maintenance and control data such as restrictions, names, types, groups and codes that can be modified,
removed or added to, based on your institution's unique business rules.
Configurable Values
Many values referenced in this user documentation are in fact configurable and an institution implementing KRA could
choose to customize them. Wherever possible an effort has been made to make key values configurable as parameters as
opposed to "hard coding" values into the application. Therefore some of the references in the user documentation to
specific values for fields or attributes may in fact be different at your institution depending on the particular
configuration decisions.
For more information about parameter configuration, see System Parameter in Administration.
How To Use The User Documentation
The table of contents leads you to topic and subtopic headings that provide information ranging from simple notes to a
thorough review of what to do and why, with frequent examples.
User Documentation Structure
The structure of information is organized in such a way as to mirror the software applications user interface wherever
possible. In order to reduce the required effort for documentation maintenance, the documentation is structured so as to
not repeat the same material across various chapters. Topics are designed to cross-reference appendices to reduce
redundant information within procedural topics and give you one common location for information lookup.
Electronic Navigation
Whether using a PDF-formatted version of this documentation (with electronic bookmarks along the left column) or the
HTML-formatted online help version (with hyperlinked contents and index), cross-references, indexes, and the electronic
table of contents are provided at the sub-topic level wherever possible to allow for efficient navigation to sections and
subsections of instructional information (or external Web resources). Each underlined topic functions as a hyperlink that
causes a new section to appear.
Typographic Conventions
This document adheres to specific documentation standards and style conventions to optimize readability. The
formatting of text used to name things you click on are typically bold to enhance visual comprehension and improve
usability.
The following graphical icon symbols are used throughout this user documentation to call your attention to pieces of
textual information and statements that can generally be categorized as described:
Table 2 Icons in User Documentation
Icon Description
Note/Important/FYI
Cross-reference/Link/ Internal or External Hyperlink
Suggestion/Concept/Hint/Tip/Idea
Caution/Warning/Error
Sequential tasks are numbered, notes and action results are indented, and user interface element references are typically
formatted to enhance readability. Mouse pointer icons and callouts are used frequently to show you what to click on at
each process step.
Versioning
If you have received a printed copy of this user documentation, please note that as the KRA application is improved and
enhanced, corresponding updated releases of the documentation will be available online. To ensure you have the latest
and most current version at any time, consult the links from the User Documentation page on the KRA Documentation
wiki site and compare the versioning. Our goal is to make the most recently-updated electronic (soft) copy available in
the online edition, which always mirrors the release version number of the software delivered for download. For
document control purposes, the edition (release version) number appears in the file name itself.
Printing
User documentation made available for online viewing, download and printing may require the use of Portable
Document Format .pdf reader software, such as Adobe Acrobat Reader 4.0 or later (or equivalent); or the Microsoft
Word Reader for the .doc format.
A plug-in may be available to allow you to view .pdf documents in Web browsers as either .pdf or .htm formats.
Consult your Web browser's Help links to explore these viewing options. HTML pages can be printed using your
computer's default printer.
Readers
PDF: Get the Adobe Reader at http://www.adobe.com/products/acrobat/readstep2.html.
DOC: Get the MSWord Reader at: http://www.microsoft.com/downloads/details.aspx?FamilyId=95E24C87-
8732-48D5-8689-AB826E7B8FDF&displaylang=en.
Help Screen Printing
HTM: KRA Online Help screens in hypertext markup language format may be printed from your Web
browser or from within the help tool itself by clicking the printer icon button on the help toolbar.
Getting Help With Help
The documentation you are reading, whether printed or online, is derived from a single content source and published
either as a manual suitable for printing on paper (hard copy), viewing online (soft copy), or as part of the online help that
is embedded within the KRA application. So, regardless of the manner in which you are reading this, it is a knowledge
base that aims to give you all the help you will need to use KRA with ease and success, and serves as the primary source
for self-training. As you read on to educate yourself about how to use KRA to accomplish your tasks, be aware that help
with the help is built in to the online help system itself, and is just a click away. While there are many sources of getting
help with using the KRA system, the feedback e-mail feature of KRA help allows you to quickly ask a question or even
make a suggestion while youre reading a particular topic, a link to which is included in the body of your e-mail
automatically.
Documentation Feedback
The Kuali Foundation values and appreciates your comments as a user and reader of this document. As we write, revise,
and evaluate our documentation, your feedback is the most valuable input we receive. If you would like to contact us
with comments or suggestions for future releases of KRA, please send an e-mail to:
Topic-Specific Online Help E-Mail Feedback:
Figure 4 Online Help E-Mail Feedback
Click the E-Mail icon on the help menu bar from any screen, document or page to immediately provide feedback on a
particular help topic. Your default e-mail application is launched with the 'To' and 'Subject' fields automatically
populated, along with the help URL in the body of the e-mail. Just add your comments and click Send.
For more information on using KRA online help features, see the Drilldown Links & Icons topic in Selection,
Entry and Action Tools.
Contact Information
For a complete list of Kuali contact information, see http://www.kuali.org/contact.shtml.
News & Event Subscription Service
To subscribe to the KRA News & Event Service, see: http://collab.kuali.org/subscribe/subscribe-kra.html.
Copyright and Licensing
Kuali is a registered trademark of the Trustees of Indiana University.
The Kuali Foundation has established a set of intellectual property management practices to protect the foundation, its
members, and the extended Kuali community.
The Kuali Foundation uses various licenses to distribute software and documentation, to accept regular contributions
from individuals and organizations, and to accept large grants of existing software products.
The sections that follow explain Kuali copyright information as it pertains to the following three licensing areas:
Software Licensing
Contributor Licensing
Documentation Licensing
Intellectual Property Contact Information: If you have any questions about Kuali Intellectual property, please contact
The Kuali Foundation at licensing@kuali.org.
Software Licensing
Kuali software is licensed under the Educational Community License (ECL), version 2, the full text of which can be
found at http://www.opensource.org/licenses/ecl2.php.
Copyright 2008 The Kuali Foundation. Licensed under the Educational Community License, Version 2.0 (the
"License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.osedu.org/licenses/ECL-2.0 Unless required by applicable law or agreed to in writing, software distributed
under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied. See the License for the specific language governing permissions and limitations under the
License.
Contributor Licensing
Copyright 2008 The Kuali Foundation. All rights reserved. Kuali software is licensed for use pursuant to
the Educational Community License v. 2.0. Portions of Kuali software are copyrighted by other parties, including the
parties listed below. You should refer to the licenses directory (https://test.kuali.org/confluence/display/KULLIC/Home)
for complete copyright and licensing information.
Third Party Contributions
Portions of Kuali were developed by Indiana University, Cornell University, Michigan State University, University of
Arizona, and Massachusetts Institute of Technology. (http://www.kuali.org/).
This product includes software developed by the Apache Software Foundation (http://www.apache.org).
This product includes software developed by the JAX-RPC Project part of Project GlassFish (https://jax-
rpc.dev.java.net/).
This product includes software developed by the SAAJ Project part of Project GlassFish (https://saaj.dev.java.net/).
This product includes software developed by Displaytag (http://displaytag.sourceforge.net/11/).
This product includes software developed by the JDOM Project (http://www.jdom.org/).
This product includes software developed by the University Corporation for Advanced Internet Development Internet2
Project (http://www.ucaid.edu).
This product includes software developed by the Open Symphony Group (http://www.opensymphony.com/).
This product includes software developed by the Indiana University Extreme! Lab (http://www.extreme.indiana.edu/).
This product includes software developed by the Working-Dogs.com (http://www.Working-Dogs.com/).
This product includes software licensed under GNU Lesser General Public License
(http://www.opensource.org/licenses/lgpl-license.php).
This product includes software licensed under Common Public License
(http://www.opensource.org/licenses/cpl1.0.php).
This product includes software licensed under the Mozilla Public License (http://www.mozilla.org/MPL/).
This product includes the Kuali Rice module licensed under the Kuali Foundation ECL (Rice Acknowledgments).
This product includes the Kuali Enterprise Workflow module licensed under the Kuali Foundation ECL (KEW
Acknowledgments).
The original concept and code base for P6Spy was conceived and developed by Andy Martin, Ph.D. who generously
contributed the first complete release to the public under this license. This product was due to the pioneering work of
Andy that began in December of 1995 developing applications that could seamlessly be deployed with minimal effort
but with dramatic results. This code is maintained and extended by Jeff Goke and with the ideas and contributions of
other P6Spy contributors. (http://www.p6spy.com)
Portions Copyright (c) 2000-2005 INRIA, France Telecom. All Rights Reserved.
Portions Copyright (c) 2001-2006 Sun Microsystems, Inc. All Rights Reserved.
Portions Copyright (c) 2002, 2003 Mihai Bazon. All Rights Reserved. Licensed under GNU Lesser General Public
License (http://www.opensource.org/licenses/lgpl-license.php).
Portions Copyright (c) 2005 Envoi Solutions LLC. All Rights Reserved. (http://xfire.codehaus.org/)
Portions Copyright (c) 1999, 2004 Bull S. A. All Rights Reserved.
Portions Copyright (c) 2003-2005 Joe Walnes. All Rights Reserved. (http://xstream.codehaus.org/)
Documentation Licensing
Copyright 2008 by The Kuali Foundation. Some rights reserved.
Kuali Research Administration User Documentation by the Kuali Foundation is licensed under a Creative Commons
Attribution-Share Alike 3.0 United States License. Permissions beyond the scope of this license may be available at
http://www.kuali.org.
Creative Commons License Deed
Attribution-Share Alike 3.0 United States
You are free:
to Share to copy, distribute, and display the work
to Remix to make derivative works
Under the following conditions:
Attribution. You must attribute this work to the Kuali Foundation.
Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting
work only under the same, similar or a compatible license.
Permissions beyond the scope of this public license are available at http://www.kuali.org.
For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do
this is with a link to http://www.kuali.org.
Any of the above conditions can be waived if you get permission from the Kuali Foundation, the copyright
holder.
Apart from the remix rights granted under this license, nothing in this license impairs or restricts the authors
moral rights.
Disclaimer
Your fair use and other rights are in no way affected by the above.
The Commons Deed is not a license. It is simply a summary and handy reference for understanding the Legal Code (the
full license) it is a human-readable expression of some of its key terms. Think of it as the user-friendly interface to the
Legal Code beneath. This Deed itself has no legal value, and its contents do not appear in the actual license. Creative
Commons is not a law firm and does not provide legal services. Distributing of, displaying of, or linking to this
Commons Deed does not create an attorney-client relationship.
The information in this document is subject to change without notice. It has been obtained from sources believed to be
reliable. Although the authors and the Kuali Foundation have made every effort to ensure the accuracy of this document,
neither the authors nor the publisher assumes any liability or responsibility for any inaccuracy or omissions contained
therein, or for any loss or damage arising from the information presented.
If you discover any issues with the documentation, please report your findings, in writing, to The Kuali Foundation. The
Kuali Foundation does not warrant that this document is error-free.
All other products or company names represented in this document are not to be viewed as endorsements by either the
authors or The Kuali Foundation, and may be trademarks for their respective owners.
16 KRA Overview Kuali Research Administration v.1.0 User Guide
KRA Overview
Kuali Research Administration (KRA) is a community source software project charged with development of an
integrated set of research administration services for higher education. KRA offers a comprehensive suite of modules
including Proposal and Budget Development, Workflow, and Grants.gov integration.
A key component of KRA is an electronic document (also known as e-doc) environment in which e-docs are initiated
on a personal computer and electronically routed through an approval process. KRA is important to those who use and
process research administration information for a variety of reasons. KRA reduces paper processes; enables faster
turnaround and allows for decisions to be made based on up-to-date information; provides built-in checks and balances
reducing mistakes and the need to correct errors; gives more control and management flexibility to documents; and
facilitates efficient tracking, archiving and reporting. KRA Overview is intended to be a guide for the shared
functionality and common operations of most e-docs as well as a foundation for subsequent topics covering specific
functionality.
Kuali
Kuali is an umbrella of applications development, under which smaller applications known as modules are developed
to support coarse-grained end-user tasks. Modules are portions of larger programs that carry out specific functions. They
can be implemented alone or can be combined with other modules.
KRAs modular architecture allows institutions to implement only the functional elements they need. In this way, KRA
can be scaled to meet the needs of institutions of any size.
Key Components
There are many components that work together to make the KRA system work, and they are too numerous and often too
technical in nature to mention here. However, this topic aims to briefly summarize the major ones to give you a basic
level of understanding that will allow you to use the KRA software to accomplish tasks with confidence and success.
Currently falling under the Kuali umbrella is a core system known as Kuali Rice (KR), which is comprised of several
technical modules, including Kuali Nervous System (KNS), which encompasses infrastructure components, and Kuali
Enterprise Workflow (KEW), which automates routing of e-docs (electronic documents) for approval according to
specified business rules. These are considered "core" modules because they depend on one another, and non-core
modules and their components depend on the core, since they are necessary for other functional modules to operate. The
specifications are available for institutions to develop their own interfaces to the core system modules, since any
dependency of one non-core component on another non-core component is flexible to allow implementation of unique
combinations of subsets via parameterization and service interface definition to meet an institutions unique needs.
Kuali Research Administration v.1.0 User Guide KRA Overview 17
Rice
An enterprise-class middleware suite of integrated products that make up a business application development framework
for Kuali and non-Kuali applications using a modular, Service Oriented Architecture (SOA) approach with components
such as workflow, notification, and user interface configuration.
KNS
KNS is the underlying infrastructure code that any KRA module may employ to perform its functions. KNS is
functionality common to many modules. Examples include creating custom attributes, attaching electronic images,
uploading data from desktop applications, lookup/search routines, and database interaction. The KNS is a core technical
module composed of reusable code components that provide common pieces of functionality. The KNS is a technical
framework that enforces consistency in the applications that use it. It promotes adherence to the architectural principles
and development standards defined by the Kuali architects. The KNS also provides a stable core of development tools
providing a more efficient development paradigm.
KEW
KEW is the Kuali infrastructure service that electronically routes an e-doc to its approvers in a prescribed sequence,
according to established business rules based on the e-doc content. It is considered a general-purpose electronic routing
infrastructure or workflow engine. Client applications use KEW to automate and regulate the routing and approval
processes for the transactions/documents they create. It starts with an e-doc that users compose in a client application
such as the KRA or some other Web application that requires routing and approval of documents.
KEW then routes the e-doc electronically to the attention of designated individuals, based on institutional or
departmental business rules and policies. Via this centralized routing system, users can access and search for many types
of e-docs from various client applications. This is accomplished from a single location, the Action List and Doc Search.
The Route Log for a given document allows users to follow its progress. KEW streamlines mediated business processes
across the enterprise.
KRA
KRA is a functional module (application) that interfaces with the core modules of KNS and KEW. It is also an
application that itself is comprised of many modules (sometimes referred to as sub modules). KRA includes a base
system of modules such as Proposal & Budget Development, Routing Form, and Grants.gov Integration, with additional
modules that can be implemented when institutions identify a need such as Institutional Review Board (IRB) / Human
Subjects, Awards, Conflict of Interest, Institute Proposal / Negotiations, Report Tracking, Subcontracts, Cost Share
Commitment Tracking, Animal Care and Use, Bio-Safety Management, Subrecipient Monitoring, Export Controls /
ITAR Management, and Chemical Tracking System.
In this release (version 1.0), the following modules are included:
Kuali Rice Integration (including Workflow)
Proposal Development (including Budget)
Grants.gov Integration
E-Doc
E-doc is short for electronic document. The two terms are used interchangeably to refer to KRAs online forms that
allow for the entry and selection of information. That information can then be saved for future modification by one or
more designated users, each of whom may have different assigned roles in e-doc completion. E-docs can be routed to
collaborators, reviewers and approvers electronically. Routing status is tracked. Records of performed actions are
preserved for reference. In KRA, a user initiates a transaction from their desktop Web browser by creating a new e-
doc.
Upon saving or navigating between the various pages that make up the new e-doc (each with a separate screen), the
initiator or collaborator receives immediate feedback on the validity of the document both in light of the appropriateness
of data and the compliance with business rules via red error messages right on the document screen. Valid documents
are routed by KEW to one or more designated Reviewers and Approvers based on the type of transaction and content of
the e-doc. Fully approved transactional e-docs are sent for final disposition actions. One of those actions is to format and
submit the approved document electronically to external organizations, such as Grants.gov.
Anyone who initiates, reviews or approves research administration transactions may be a user of an e-doc, including:
Principal Investigators; Co-Investigators; Departmental Administrators; Departmental support staff, professional staff,
and faculty; Fiscal Officers and Delegates; Deans, Directors, and Department Chairs; Institutional Review Board
members; Office of Sponsored Projects Reviewers; Preparers; Aggregators; Budget Creators; Narrative Writers; FYI
Viewers, etc.
For more information on the different types of e-docs and their components, see E-Doc Fundamentals.
Access
KRA access is primarily determined by workgroups and document types. Depending on institutional requirements and
implementation, different access rules can be constructed and associated with specific document types or groups of
documents and with specific users or groups of users.
Workgroup
A Workgroup is a collection of users who share a similar responsibility and business function. When a document routes
to a workgroup, all members of the workgroup can see that document in their action lists. After any single member of the
workgroup takes an action on that document, it is removed from the action lists of all other workgroup members. Access
to particular document types can also be controlled by workgroups.
Document Type
Document Type is used to distinguish between the different types of transactions that are possible. A document type
generally allows users to perform a set of functions and contains business rules particular to those functions.
While most document types in KRA are available for anyone to initiate, there are some that may be restricted to
users who are members of particular workgroups. For information on specific restrictions available for particular
document types, see the respective individual document type topics.
Workflow Restrictions
Workflow is used to route a document by matching attributes of a transaction or document with existing rules that
indicate where a transaction or document with those particular attributes should go. Most commonly, Workflow is used
to collect document approvals. The path of approval can be influenced by the type of action and the content of the
document itself. In this way, workflow can restrict the access to portions of the system and/or portions of data for a
particular user based on the underlying, configurable business rules.
For more information about workflow as it applies to types of application access, see Kuali Enterprise
Workflow.
Impediments to Access
Locking Considerations: When more than one user has accessed and is editing the same document at the same time,
there are document locking rules that can be quite complex to a new KRA user regarding this that, when not followed,
could result in loss of data entry work.
For more information about document locking, see Document Locking in E-Doc Fundamentals.
Browser Navigation Button Usage: As a general rule, we strongly suggest that you never use your Web browsers
navigation tools (for example, the Back button) while using the KRA system.
For more information about Web browser functionality as it relates to usage of the KRA Web application, see
Browser Navigation Warning in KRA Overview.
System Timeout: The timing out of your user session in the KRA system also has an effect on your application access.
For more information about access duration limits, see System Timeout in Logging In.
Kuali Identity Management (KIM)
Kuali Identity Management (KIM) is a Kuali module that provides a means for authorization and definition of user
permissions. It is one of many modules that comprise Kuali Rice. Customizable and configurable by implementing
institutions, KIM uses namespaces to restrict who has access to what. Examples include restricting available user
interface options based on a users identity. This flexibility allows the KRA system to be presented to the user in such a
way as to limit them to only what they need to use to accomplish their particular job.
For more information about Kualis identity management module, see http://rice.kuali.org/kim/ in the Kuali
Rice Web site.
KRA Authorization Service
Authorization in KRA works based on the permissions users have for viewing, creating and modifying documents. It
functions as a behind-the-scenes service that gets the user name, document name, and task the user was attempting and
then asks is this user authorized to perform this particular task for this document?. The user is either authorized to
continue with the permitted task, or a violation error message is displayed.
For more information about KRA Authorization, see
https://test.kuali.org/confluence/display/KRADOC/Technical+Documentation in the Kuali wiki.
Most documents in KRA include a Permissions Page with tabs for Assigned Roles and Users.
For more information on assigned roles and users, see Permissions in Proposal Development.
Roles
The word role is used in multiple contexts in KRA, and this section aims to clarify those for you.
There are four primary kinds of roles involved with usage of the KRA system:
System: relate to e-doc routing status & actions (workflow)
User Interface: relate to tabbed main menu screens (functional menus)
Document: relate to e-doc preparation & completion (permissions)
Proposal: relate to the proposed personnel (research project)
System Roles (Workflow)
Roles determine which options are available to a KRA user. Some roles are determined by the users relationship to a
particular document. The role of Initiator is automatically assigned by the system to the user who creates a new e-doc.
Other roles give additional permissions or options in addition to what normal KRA users might possess. For example, a
user could be an Approver for a specific e-doc or have the additional role of Administrator, which gives the user options
that a normal Approver would not have. It is possible, and sometimes common, for a user to have multiple roles. The
primary roles are Initiator, Approver, Delegate, Reviewer, Administrator, and Superuser.
Table 3 System Roles (Workflow) Definition
Role Description
Initiator As an Initiator you can create documents. Any Kuali user may initiate most of the document types, however, an
Initiator may be required to belong to a Workgroup for certain restricted document types.
Approver An Approver is someone who has been granted permission in the system to approve a proposal for submission
to the sponsor. As an Approver you can approve the documents at any route level (including Ad Hoc routing).
As a document moves through Workflow, it moves one route level at a time. An approver operates at a
particular route level of the document. The screen view and available action options of a document may vary,
depending on whether the document is at that approvers route level, or at some other route level.
Delegate As a Delegate you can approve documents at a particular level of routing, as if you yourself were at that level
yourself. Fiscal Officers can delegate the approval authority to other users based on attributes of a specific
transaction, such as document type and dollar amount. There are two kinds of delegates: Primary Delegates and
Secondary Delegates. While documents route directly to Primary Delegates instead of routing to Fiscal Officers,
they route to Secondary Delegates in addition to Fiscal Officers. The Secondary Delegates have a special filter
option in their action list, which allows them to retrieve documents for which they have been given approval
authority.
Reviewer As a Reviewer, a document is ad-hoc routed to you for Acknowledgement, Carbon copy (Cc) or For Your
Information (FYI).
Administrator As an Administrator you can give blanket approval on most transactions you initiate or for which you are an
Approver. Blanket approval is a special workflow option that allows the user to force a document into approved
status without waiting for the normal routing process to be completed.
Superuser As a Superuser you can fully approve any document in the ENROUTE status, can approve or disapprove any
document at its current route level, and can cancel any document that has not been fully approved.
User Interface Roles (Functional Menus)
Figure 5 KRA User Screen Menus
User Interface Roles, unlike System Roles or Document Roles, are identified on the main menu as tabs. They include
Researcher, Unit, Central Admin., Maintenance and System Admin.. Admin. is an abbreviation for Administrator or
Administration, depending on whether youre referring to purpose of the tab or the user of the tab. The idea behind this
user interface design is that your role in research administration work determines the menu tab you are likely to use most
often, if not exclusively. Functionality commonly used by a Researcher, for example, appears on the Researcher screen
when the Researcher tab is selected, and so on. This feature allows users of KRA to quickly access the information they
need based on their role in using the system, and eliminates functionality they are not concerned with. While not
perfectly tailored to everyones needs, particularly when you consider individuals who wear many different hats within
smaller organizations, the efficiency, convenience, and simplicity are all improved by providing a screen that has only
what a particular user needs, and nothing more.
Table 4 - User Interface Menu Role Definition
Role Description
Researcher This screen is designed for the individuals who create proposals and receive awards to conduct research. It
allows them to get a proposal started that others complete, view all information related to the proposal they
started at any time, view award information associated with proposals at any time, create and view protocols,
disclosures, review financial entities, look up opportunities on Grants.gov, and view and modify personnel-
related information such as degree, support, bio-sketches & training. Finally, as with all tabbed main menu
screens, there is the ability to customize workflow preferences.
Unit This screen is designed for the individuals who work in research administration at the unit level. This means they
contribute to proposals started by Researchers and typically work in the same unit that the Researchers do. Unit
users of KRA might coordinate the completion of proposals; do post-award work such as entry of award
information into KRA, award tracking and reporting; work on ensuring proposals are compliant with various
regulations and laws prior to being submitted; and similarly that after a proposal has been submitted the proper
protocols are followed leading up to the award; and additional search and routing capabilities that the Researchers
do not have.
Central
Admin
This screen is designed for the individuals who work in the institutions Central Administration office (also
known as Contract & Grant Administration or Office of Sponsored Projects). It offers functions grouped and
organized in a very similar manner as the Unit screen, but is meant for use by Central Administrators who may
perform the same duties that Unit users would in the absence of personnel resources being available (for example,
in a smaller unit in an institution with fewer staff members than other units).
Maintenance This screen is designed for the individuals who need to maintain information that is referenced by e-docs within
the KRA system via maintenance documents. Maintenance documents are e-docs that provide a user interface
for a database of stored information that is sometimes shared by more than one transactional e-doc, and are
grouped together on the Maintenance screen accordingly. Similarly, functions related to specific functional
modules are also grouped together. In this way, when a code changes for example, a functional user can update it
in the system without the need for a technical software expert.
System
Admin
This screen is designed for administrators of the KRA system by grouping functions those user types need to use
frequently to be sure the software is functioning properly. It is for users who have more technical software
expertise and work to continually update the behind-the-scenes functions to keep the system running smoothly
and according to necessary functional changes. For example, when business rules change, the configuration of
the system must also be changed to support them, which might include updates to system parameters, batch
schedules, messaging or workflow services.
Document Roles (Permissions)
Document roles are user roles for particular document types within the KRA system. They allow different types of
access for different types of users for a particular document type. This facilitates collaboration on the completion of an
e-doc by multiple individuals, each of which take responsibility for portions of a document based on their area of
expertise.
Roles
Permissions
For more information about how roles and permissions are tied together, see Role-Permission Maintenance
Document in Maintenance Documents.
User Roles for Proposal Documents
When performing a custom document search on a specific document type that supports user role bound searches in KRA,
you will be given the option to select the roles that you want to constrain your search by. These roles are always relative
to the currently-logged-in user. Roles to ensure that only specified users can view or change all or parts of a Proposal
Development Document are:
Table 5 Proposal Document Permissions Roles
Role Description
Aggregator The Aggregator is an assigned role in KRA that allows the user to make changes to any part of the proposal.
In the paper world, this is the person who puts the parts of the proposal together and submits the proposal to
the Office of Sponsored Projects (OSP). Additionally, this person assigns roles for completing the proposal.
While the OSP may have the system role of Initiator for a Proposal Development Document, the Aggregator
may also edit it electronically. Typically, this Initiator is a member of the staff that is associated with the
faculty department or college who assembles the proposal.
Budget Creator Creates the Budget Document that is associated with the Proposal document. Typically, this is a member of
the institutions administrative staff (as opposed to faculty) who is a department or business office manager
who might confer with Office of Sponsored Projects. However, some Principal Investigators (faculty
members) create their own budgets.
Narrative Writer Creates the proposal narrative. Typically, faculty or students write proposal narratives and enter them within
KRA, but they may also have administrative staff enter it on their behalf.
Viewer Reads Proposal documents (cannot create new or edit existing).
Approver Approves Proposal documents. Typically individuals with this role work at Dean, Dept. Chair, Research
Office or Business Manager levels, but some might also be Fiscal Officers, depending on institutional needs.
Proposal Document Rights by User Role
Figure 6 Proposal Document Rights By User Role
For more information on assigned roles and users for Proposal documents, see Permissions in Proposal
Development.
Proposal Roles (Research Project)
Yet another type of role associated with use of KRA is a role within the Proposal document that a user (with Aggregator
rights that allow for Proposal document access maintenance) is able to assign to other users. These role names exist for
the purpose of identification of the individual institution employees (or in some cases, third-party contributors) that will
be involved in conducting the research, carrying out the work stipulated in contracts, and ensuring the award conditions
are met.
There are three such roles. They are:
Figure 7 Proposal Personnel Role Selection
Table 6 Research Project Proposal Role Definition
Role Description
Principal
Investigator
Faculty members who are requesting money from sponsor agencies to use to conduct research. The
individual bearing primary responsibility for all essential aspects of the project or protocol, including
programmatic work, compliance with government, sponsor and university policies and regulations, fiscal
stewardship of sponsored funds, and all administrative requirements of the project. The Principal
Investigator/Project Director/Program Director (PI/PD) is the individual designated by the grantee, and
approved by the sponsoring agency, who will be responsible for the scientific or technical direction of the
project. If more than one, the first one listed will have primary responsibility for the project and the
submission of reports. All others listed are considered co-PI/PD, and share in the responsibility of the
scientific or technical direction of the project. The term "Principal Investigator" generally is used in research
projects, while the term "Project Director/Program Director" generally is used in education, and service
projects.
The federal government is making the switch to the term PD/PI for all projects.
Co-Investigator May be another faculty member from the same institution, a student (usually a graduate student), a faculty
member from another institution, or an employee of an organization other than the PIs institution.
Investigators who share responsibility for the scientific or technical direction of the sponsored project.
Key Person An individual (faculty, student or non-employee) who will play a prominent role in the research activities
associated with a proposal. The role in which each Key Person will be assigned for the proposed sponsored
project. A named contributor (other than the PI) who is integral to the proposed sponsored project, or who
makes a significant contribution to the scientific development or execution of the project, including
Consultants (if applicable) and mentors on Career awards. This includes Key Personnel and Other Significant
Contributors as defined by NIH and Grants.gov. All individuals who contribute in a substantive, measurable
way to the scientific development or execution of the project or protocol, whether or not salaries are requested
(NIH definition).
Logging In and Out
Starting KRA
Since KRA is a Web-based system, it is accessed via conventional means using a Web browser. Contact your System
Administrator for the exact Uniform Resource Locator (URL) link.
You may want to bookmark this in your browser, or add it as a shortcut to your desktop if it is not integrated into
another existing Web application portal.
Enter the URL for KRA (for example, https://test.kuali.org/kra-reg/portal.jsp) into your browsers Address box
(a.k.a Location Bar) and click Go (or press your keyboards Enter key).
The Main Menu appears:
The default start screen (Main Menu) displays a message in the notification area of the menu bar that You are not
logged in.
Logging In
When selecting an item on the Main Menu tab (or another tab) for the first time in a session, KRA prompts you to enter a
User ID and Password. KRA performs user authentication and authorization to restrict access to business transactions,
according to the prevailing practices at your institution.
If your institution opts to integrate the user authentication to a different campus authentication system, the login
sequence might vary.
Enter your UserID and Password as appropriate and click Login.
The notification area of the menu bar displays your user ID.
You are able to navigate the system and perform actions according to your role.
Figure 8 Logged In User display
After you have logged in, you are not asked to log in again until you log out from the system by closing the
browser.
Impersonation
Typical of demonstration and training environments, your implementation of KRA may include the ability to
impersonate other users after logging in. This is particularly useful when showing how screens, documents and action
options may differ depending on the workgroup or permissions associated with certain users. If so, you will see a login
box with button in the upper right corner of any screen. When used, the notification area displays both your ID and the
one you are impersonating.
Figure 9 Login To Impersonate
Figure 10 On-Screen Impersonation Notification
Figure 11 On-Document Reminder: Backdoor Id is in use
Logging Out
To log out from KRA, simply close the Web browser by clicking the standard Close button located in the upper
right corner of your browser.
Depending on your institutions implementation of Single Sign-On (SSO), this may remove automatic logins to
other Web applications or systems. Consult your System Administrator to be certain.
System Timeout
Figure 12 Session Expiration Message
The system may time out after a period of inactivity which could result in lost work and require logging in again.
Consult your System Administrator for specific duration and consequences. The KRA default is 60 minutes. Upon
a session expiration, document locks will be released. Each time you click the save button (or navigate to a new
page), the timer is reset.
Central Authentication Service
The default implementation of the authentication module shipped with KRA uses the Central Authentication Service
(CAS) authentication system. CAS is the authentication system used by Yale University and Indiana University, and is
the standard system at those institutions by which Web applications authenticate users.
Figure 13 Generic, Default KRA Login Screen
KRA authenticates users based on the prevailing institutional practice.
Your institution may have opted to extend KRA to use a different authentication service instead of the CAS
framework.
Changing Your Password
1. Click the Change Password link.
The Change Password tab appears:
Figure 14 Change Password Tab
2. Enter your current password, new password, and confirmation of new password in the corresponding fields as desired.
Asterisks appear in place of the characters of your entries.
3. Click the save button.
Screen Anatomy, Navigation and Tools
To help you navigate and use KRAs user interface successfully and without confusion, the following subtopics outline
the various menus and functions that are common throughout the system. They demonstrate how the system is organized
so that you will become familiar with where in the application to find certain types of information and pieces of
functionality, with element terms that are used consistently throughout this documentation.
Screen Layout & Navigation
Most KRA screens have design constants such as a header, body, and footer. The header displays the KRA logo on the
left, menu tabs in the center, and a feedback e-mail link on the top, right. A horizontal toolbar separates the header from
the body with workflow action buttons on the left, a display of your user name, and a login tool that allows for
impersonation of other user roles (used for system diagnosis and training demonstration). The body displays menu
groups, each of which contain links to functional screens (for all transactional e-docs, some maintenance e-docs, custom
searches and reporting). While the header and footer remain static, the body area is dynamic depending on which piece
of functionality has been selected. When e-docs accessed from a menu screen and are currently displayed, the body
contains e-doc page and e-doc section tabs. Lastly, the footer displays copyright information and the small k logo.
Figure 15 KRA System Screen Overview
The following topics briefly describe the purpose and function of each of the major screen elements in KRA:
Menu Tabs
Horizontally laid out across the top of any KRA screen (header area, to the right of the KRA logo) are tabs that have the
look of file folder tabs.
The KRA user interface is organized at the highest level by five menus that appear as having the look of file folder tabs
at the top center of the screen (header area, to the right of the KRA logo) Researcher, Unit, Central Admin,
Maintenance and System Admin. They are laid out horizontally across the top of any system screen.
Figure 16 KRA Menu Tabs
The menu that is currently displayed is highlighted in red background with white letters, while the hidden menu tabs
have black label text and tan backgrounds.
Figure 17 Menu Tab Navigation Example: Navigating to a different menu
When you hover your mouse cursor over a hidden screen tab, you will see that your arrow icon is changed to a pointing
hand, the label text becomes underlined, and tip text pops up to indicate that you are able to click to select and display
the menu.
Browser Navigation Warning
Whether attempting to navigate from screen to screen, menu to menu, or page to page, it is strongly recommended that
you never use your Web browsers navigation tools (for example, the Back, Forward, and Refresh buttons). The tools
on the horizontal toolbar near the top of the Web browser you use to access and use the KRA software application with
are not intended to be used for navigation (or for any other function) within the KRA screens and pages. KRA is
designed for compatibility with most popular browsers, but is not designed to use their functionality for anything other
than viewing the display of the user interface.
Figure 18 Just Say No To Using Browser Buttons
Clicking one of your Web browsers navigation buttons (for example, the [Back] button to go to a previous
screen or page) while using KRA could possibly result in:
Loss of entry/selection work
System-generated error messages
Automatic refresh
Disabled functionality
A need to delete a document lock
Loss of a document lock
If you do click Back by accident, it might not have a negative impact at all. However, it is recommended that you
log out completely, close your Web browser, and open a new browser window to log in again, rather than simply
reloading the page with a KRA action button or browser refresh button, both of which may not be reliable
mitigating options.
Default Start Menu
Figure 19 Startup screen tab in forefront along menu
After successful authentication and login, the screen that is actively displayed by default has its menu tab appear with
white text against a red background. This may also be referred to as the main menu, dashboard or portal, but it is
the screen that is displayed after you log in, and theoretically, the one that you will use the most based on your typical
job duties as they relate to use of KRA.
The initial screen default may be different depending on your implementation and role. For example, if you
primarily work with maintenance documents and/or system administration, your Administrator system role might
dictate that the Administration menu is displayed by default after successful login instead of Main.
Menu Groups
Menu groups are boxes with red headings containing bullet lists of links that group functionally-related features.
Figure 20 Menu Group Examples: The Pre-Award and Post-Award groups on the Main menu
Menu Group Sections
Black, bold headings within each menu group further divide and categorize functionally-related features.
Figure 21 Menu Section Examples: The Conflict of Interest and Institutional Review Board sections of the Compliance menu group
Menu Links
Clicking an underlined link causes a new screen to appear; typically either a transactional e-doc, maintenance e-doc,
search or lookup inquiry.
Figure 22 Menu Link Example: The Sponsor link in the General section of the Inquiries and Lookups menu group
Selection, Entry & Action Tools
This topic covers basic user interface element tools that appear on various screens and e-docs throughout the KRA
system which allow for selection of options, entry of information, navigation, display customization, and action
command initiation.
List
(also known as drop-down menu, combo box or list box) Arrow associated with a combo or list box indicating a list that
drops (expands) downward for viewing. Click the down arrow icon to list menu options, and then click the text to
highlight and select an option (may expand upward to take advantage of available screen real estate).
Check Box
(also known as selection box) Square box that is selected or cleared to turn on or off an option. More than one check box
can be selected. Use a mouse to click within the box to place a check mark symbol to indicate the option is selected.
Option
(also known as radio button, option button) Round button used to select one of a group of mutually exclusive options.
Use a mouse to click within the circle to place a dot symbol to indicate the option is selected.
Box
(also known as edit box, text box or entry field) Rectangular box in which you can type text. If the box already contains
text, you can select that default text or delete it and type new text. Use a keyboard to type or clipboard to paste text and
numbers into the field.
Autocomplete Functionality: Recent entries will appear as autocomplete options when a portion is entered. If
desired, click the text you are presented with to populate the remainder of the box without having to type it and complete
your field entry.
Accessibility Note: While you must click your mouse cursor within the box (essentially selecting that field for
entry) in order to enable the entering of text into it, an alternative method is to use the [tab] key on your
keyboard until the blinking cursor appears on the left of the box. Many KRA screens allow for tabbed
field/option/button navigation to make keyboard entry more efficient.
Default Tabbing Sequence
On all screens, the default tabbing sequence is top-to-bottom (down the first column, on to the second column and
down, and so on) unless otherwise specified by instructions appearing on the relevant portion of the screen.
Alternatively, the standard of left-to-right (across the first row, on to the second row and across, and so on) is used.
All editable fields for a given (expanded) tabbed e-doc section are navigated to first, then all local buttons (buttons or
links that do not take you to another screen), even if a strict top-to-bottom or left-to-right order is violated between fields
and buttons.
The following widgets will not gain focus by tabbing: non-local buttons (buttons or links that change screen focus) and
icon buttons such as Lookup or Inquiry.
Enter Key
Default Enter Behavior: On all screens, pressing your keyboards [Enter] key will by default refresh the screen
unless another button or link has focus, in which case that button or link will be activated as though clicked. Alternate
behaviors may be specified on a page-by-page or section-by-section basis.
Add
(also known as add document or create new e-doc) Round, green button with plus symbol that appears to the right of the
e-doc name on the Main menu. Clicking it initiates an e-doc with a unique system-assigned document number.
Figure 23 Add Button Example: Clicking the Add button to create a new Proposal Development document
Click the add button to the right of the e-doc name (for example, Proposal Development).
A new, blank Proposal Development Document appears with a new Doc Nbr:
Lookup
Lookup screens are accessed either by clicking menu links or by clicking the Lookup icon (round magnifying glass)
located to the right of fields on various screens and documents throughout the KRA system. This function (sometimes
referred to as search or inquiry and maintenance ) allows you to look up reference table information from
maintenance documents and display a list of valid values from which to select and return to populate the field. This
enables you to find what you need when all or a portion of the valid value is unknown, and prevents you from making
data entry errors. Usage of functionality associated with Lookups is covered here according to the following subtopics:
Search Criteria Entry/Selection
Search Results
Maintenance Links
Export Functionality
Field Lookup
Multiple Value Lookup
Search Criteria Entry/Selection
Required Fields: Some fields in the search criteria section of Lookup screens are required to conduct the
search, and are marked with an asterisk (*) to the left of the field label, as with e-doc screens.
Lookup Fields: Search criteria section fields marked with the Lookup icon (round magnifying glass) on the
right of the entry box allow you to look up the reference table information to select from in order to specify
search criteria and avoid data entry errors. Click the icon to display a list of valid values from which to select
and return to populate the box.
Direct Inquiry Fields: Search criteria section fields that also have the Direct Inquiry icon (open book)
appearing to the right enable you to

Selection Tools: Standard selection tools are provided for some criteria section fields. Use the drop-down
menus and radio buttons to select options to specify search criteria as appropriate.
Date Fields: Dates should be specified as mm/dd/yyyy format. Click the date selector icon where available
to select a date from a calendar to populate date fields.
Action Buttons: Click search to initiate your search, clear to return search criteria fields you previously
populated to a blank state, or cancel to return to the main menu.
Create New and Main: Click the create new button on the upper-right corner of the Lookup screen to
navigate to a new, blank document for creating a new record for the lookup document type that is displayed
when clicked. Click the Main link to return to the default start screen (main menu).
Wildcard Use: Wildcard (%) and truncation (*) symbols are allowed on strings when a portion of search
criteria is known. Use the wildcard and truncation symbols to create searches where there are unknown
characters, multiple spellings or various beginnings/endings. Enter the prefix, suffix, or root of a search term
and replace the missing portion with an asterisk to find all forms of that word. Use the wildcard within your
search criteria entry to replace each unknown character within a term to find all citations of that word with the
percent symbol replaced by a letter.
Range Operators: Range operators allowed on numerics and dates are >,<,>=,<=, or ... All operators
except .. should be before date value. Operator .. should separate date values.
Direct Inquiry: Find records based on parameters entered for a particular section.
For more information about using the direct inquiry feature, see Direct Inquiry in KRA Overview.
Top
Search Results
Column Headings: Each result field has link on header for sorting. Click once to sort ascending, and click
again to sort descending.
Result Text Case: Most search result content is displayed in uppercase.
Inquiry Drilldowns: Some row fields have links to inquiry. The inquiry will be presented in a new window.
Return value: Click the return value link to select a row and return the key value to the previous page.
Return with no value: Click return with no value or click the cancel button if you wish to return to the
lookup screen without returning a value.
Top
Maintenance Links
Actions Column: For each result row the action column displays edit and copy links.
Edit Link: Click edit to navigate to a maintenance document for editing the current record.
Copy Link: Click copy to navigate to a new maintenance document but copy over attributes to replace the
current record.
Top
Export Functionality
Export Option Links: At the end of each result set, there are links for exporting the data to a different
format. If you wish to export the result of the table lookup to your local computer, either in the CSV, Excel, or
XML format, simply click CSV to export the data as a comma delimited file (comma separated value),
spreadsheet to export the data as a spreadsheet, or XML to export the data as xml (extensible markup
language).
Open With/Save Options: Depending on your settings, your computers default Web download manager
application will prompt you to either open the file with the default application, choose another to open it with,
or save the exported file to a default location on your computers hard drive.
Top
Field Lookup
When the Lookup icon appears to the right of a field, clicking it takes you to a lookup screen which allows you to enter
search criteria and return a list of valid values from which to select and return in order to populate the field.
To look up valid values:
1. Fill in one or more search criteria boxes to get a list of valid values in the field lookup (or leave all the search
criteria blank to retrieve all).
2. Click search.
A results table appears below the search criteria section of the screen, displaying the list of applicable values
that you have requested.
Available Actions From Field Lookup Results
After KRA retrieves valid values in the field lookup and displays the list, you may take the following actions by clicking
the hyperlinks available in the results table.
Click the name of the column to sort the retrieved values by that column (alphanumeric ascending/descending
toggle).
Click return value to select the code.
Click return with no value to cancel the search (or click cancel).
Top
Multiple Value Lookup
Some documents that require a list of values come with a special multiple value lookup screen where you may select
multiple values from the search list.
You will find the Look Up / Add Multiple xxx Lines (where xxx is the name of the attributes you are updating) in
the applicable section of the tab where this feature is available.
To look up, select and return multiple values:
Click the Look Up / Add Multiple xxx Lines icon to navigate to a special search screen where you are given
an opportunity to build a list of values from which you may choose one or more values by selecting the check
boxes in the right most column.
Then click either:
o to select all values in the list
o to clear the check boxes for all values in the list
o to populate the tab you came from with multiple values
o to return to the tab you came from without populating the tab
Top
Route Log Icon
The Route Log icon (magnifying glass over a piece of paper) appears in search result tables that, when clicked, causes
Route Log information to display in a new browser window in the forefront of the KRA application. It displays the same
document status and routing information that can be accessed and viewed from the Route Log tab that is common to
many e-docs (for example, in the Proposal Development document, this tab appears on the Proposal Actions page).
For more detailed information about the Route Log tab, see the Route Log topic within the Routing Rules
section of Kuali Enterprise Workflow.
Expand Text Area
The Expand Text Area icon displays a larger text entry box in a separate pop-up window that allows you to view/edit
text with more screen real estate.
Figure 24 Enter Text and Click Return
Direct Inquiry
The Direct Inquiry feature appears as an open book icon. It usually appears to the right of the lookup icon for most
editable fields. Its purpose is to display an inquiry screen when the field contains a valid value and the icon is clicked.
It allows you to populate the field quickly and differs from the lookup icon by automatically returning a valid table value
from the database.
Enter known information into the box (for example, Sponsor ID field).
Click the Direct Inquiry icon.
A pop-up window appears in the forefront, displaying identifying information available for the code you entered:
Figure 25 Direct Inquiry Result Popup Window Example: Sponsor Tab Identifying Information
To retain the information in this window for future reference in populating your currently-accessed e-doc, you can either
click on the e-doc screen again to cause this popup to be in the background, or you can minimize it by clicking the
minimize browser button to keep it handy and readily available.
To close the information displayed when no longer needed, click the browser close button to close the popup
window and return to e-doc screen.
Successful Inquiry Results
When the information to populate a field is known and entered, clicking the Direct Inquiry icon will cause the related
text to be displayed beneath the field:
Figure 26 This display of the name serves as confirmation that the field value you entered is valid
Inquiry Errors
Otherwise, a red error message is displayed:
When you click the close button on the popup error message window, the not found message is displayed under
the field:
Calendar
The Calendar (also known as date selector) icon enables you to populate date entry form fields by selecting dates from a
navigable calendar.
About the Calendar icon
Date Selection Help Within the Tool
Click on the Calendar icon to display the calendar
Use Navigation buttons as necessary to locate
Figure 27 Date Selector (Calendar icon) Click on the numbered date to select it
The calendar closes and your selection appears in the box
Error Icon
The large, yellow asterisk icon marks document areas that contain errors after validation.
Figure 28 Error Icon on a Tab
Figure 29 Error Icon on a Field
Sort Column
The column sort toggle button (a down arrow on the left with an up arrow on the right) allows you to sort the display of a
search result table by that column. Unlike other table headings where the column heading text is underlined and can be
clicked on directly to sort, table column heading text that contains sort column buttons is not underlined, and has the
buttons appearing one row below the heading, centered under each column heading.
Figure 30 Column Sort Function
Clicking the column once will sort the columns contents in an ascending fashion (whether alphabetical or numeric), and
then clicking it a second time will sort the data in descending order. Column sort buttons are typically used on Multiple
Value Lookup screens.
For more information on searching for multiple values, see Multiple Value Lookups in Lookup Help.
Expand/Collapse All
You may expand or collapse all tabs by clicking expand all or collapse all. These two buttons are located at the top,
right of e-doc pages.
Clicking the collapse all button on an e-doc page
For example, when you click the button (shown above) while one or more sections have
their content displayed, all of the sections of the page that contain the form fields become hidden
from view and only the tab labels are displayed (as shown below):
Figure 31 An e-doc page with all sections collapsed
Show/Hide
Use the show or hide buttons (located on the tabs to the right of the section labels) to expand or collapse an individual
page section.
The tab button displays show when the page section is closed
The tab button displays hide when the page section is open
Site Index
Site Index is a blue button appearing at the top, right of e-doc screens and to the left of the expand/collapse all buttons.
The word site refers to the Web site that is synonymous with the KRA system, specifically its web-based user
interface. Click it to view an index of the KRA system.
Required Fields
All of the required fields are denoted with an asterisk *appearing to the left of the field label text.
They serve as an indication that you must complete the particular field before you are able to perform one of the
following actions:
add a line (to create a new item in a table row by clicking an add button)
save the document (either when new or to save changes made to existing)
navigate to a different page (which forces an implicit save)
Some fields may not be marked as required and are indeed not required to perform these three actions, however,
they may be required for successful validation (for example, Custom Fields in the Proposal document).
Figure 32 Required field asterisk appears to the left of the field label text
Field-level help includes a Yes/No Required? Display
Some selections for particular required fields cause other fields to become required, even though they are not
marked as such. For example, on the Proposal document, when your selection for the Proposal Type field on the
Required Fields for Saving Document tab is Renewal, Revision or Continuation, the Sponsor Proposal ID
field on the Sponsor & Program Information tab becomes required. You are notified of this via red error messages
upon validation or save.
Drilldown Links and Icons
Since the KRA system is a web-based application, hyperlinks and icons are used both for navigation and for information
display. Many of them allow you to drill down into the document detail or to obtain additional information.
Drilldown Links
Figure 33 Three Types of Drilldown Links within a search result table
Field-Level Help
Field-level help functions as drill-down links by labels that can be clicked to display more information about the field.
To access field-level help:
Click any field label text that is underlined (for example, Description on the Document Overview section).
A new browser window pops up in the forefront that displays the help information:
Typically, the Kuali Help information that is displayed comes from a data dictionary that includes the field label name,
text describing the purpose and function of the field, an indication of whether the field is required or not, the maximum
length of the possible input, the type of input that is accepted (for example, alphanumeric), and a close button that
closes the popup browser window and returns you to the KRA screen that was displayed when help was accessed.
Popup Text Tips
Figure 34 Nonstandard Functionality Is Reflected in Popup Tool Tip Text Upon Mouse-Over
Many buttons, icons, and links throughout KRA have popup tips that appear when the mouse cursor hovers above them.
While these usually display the same text as the related label or common name, some may have different functions (for
example, the lookup icon for adding keywords on a Proposal document displays Multiple Value Search on instead of
Search as it does most commonly elsewhere).
Action Buttons
Page and Screen Action Buttons are generally located at the bottom, center of KRA software screens, and typically
appear as rectangular keys with rounded corners, white backgrounds and red text. Some may be unique to particular
pages of particular documents.
Tab and Section Action Buttons typically are clicked to command system actions whose results are evident within the
tabbed sections themselves. These are usually associated with line items (lists displayed as table rows).
E-Doc Fundamentals
This topic describes the different types of electronic documents (e-docs) that exist in the KRA system, how each is
used, an overview of the general layout of e-doc screens and pages, common e-doc attributes, and their basic functions.
Types of E-Docs in KRA
The essential difference between e-docs and maintenance e-docs:
E-Docs: The term e-doc is simply an abbreviation for electronic document. Standard electronic documents
(e-docs) are sometimes referred to as transactional documents. The terms standard or transactional are
usually used when explaining how standard e-docs are different than maintenance documents (maintenance e-
docs). Transactional e-docs perform actions both within the KRA system (routing) and outside the system
(updates or submissions).
o Internally, they travel through various states of workflow as they are reviewed and approved, and the
information they contain may be included on reports that are generated.
o Externally, they connect to or integrate with other systems to send information they contain.
Maintenance E-Docs: Maintenance e-docs are electronic documents used to maintain data in the system that
is referenced by other e-docs. Within the system, they may be routed for review and approval. Their content
becomes selectable information on form fields within standard e-docs.
Another way to think about the difference:
E-Docs: think word documents or pdf forms. Even though they are electronic forms that allow for information
entry and selection, all of the fields, sections, and pages make up a large document similar to those that
traditionally were printed.
Maintenance E-Docs: think database tables or excel spreadsheets. Although maintenance documents are
electronic documents, they are not really like documents suitable for printing, but rather, listings of available
codes that may occasionally change and thus need to be maintained. Instead of requiring complicated database
administration skills, maintenance e-docs facilitate maintaining data via an electronic document user interface
that makes it easy for non-technical users to update reference information.
A third type of e-doc:
Administration E-Docs: There is a third type of electronic document known as an administration e-doc.
Administration e-docs are like maintenance e-docs in every way, except that instead of maintaining reference
table information, they maintain information related to the administration of the software system itself. Again,
the advantage of using electronic document screens in the user interface for the configuration of the KRA
system is that it allows that type of technical work to be done by users with less technical expertise than would
otherwise be required. An important design principle of KRA is that wherever reasonably possible to include
the ability to configure or maintain the system in the user interface as an e-doc style of screen, it was done to
eliminate the amount of hard-coding and programming work that would be necessary for those pieces of
functionality.
Figure 35 E-Doc type locations by menu
E-Doc Topology
From top to bottom, e-docs start with a title and identifying information at the top, followed by a page navigation bar,
under which the main body includes expandable/collapsible sections of each page that contain form fields for data entry
and selection options, and finally at the bottom are action command buttons.
Header: The header at the top, right corner of any transactional e-doc contains the system information about
the e-doc.
Pages: The individual pages that make up the larger document are accessed via the page tabs that appear
horizontally across the top of the e-doc, just below the header. The first page displayed usually corresponds to
the leftmost page tab and usually requires entry of basic, identifying information that when successfully saved,
allows you to continue to subsequent pages in left-to-right order.
Tabs (tabbed sections or panels): The body of each page is typically organized in a stack of labeled tabs that
look like file folders. Based on the document type, a different set of tabs is displayed. To facilitate the document
input (data entry) process, an initiated document opens with required tabs expanded and the optional tabs
collapsed.
Sections within tabs: Some tabs may contain more than one section, each labeled with white text and a dark
gray background. Sometimes each section has its own unique help icon.
Buttons: The action buttons are displayed below the stacked tabs and differ based on the e-doc type, the e-doc
page, your role and the status of the e-doc.
Figure 36 KRA E-Doc Screen Overview
E-Doc Header
The e-doc header appears at the top, right corner of any e-doc. It contains the system information about the document.
Figure 37 E-Doc Header Example
Table 7 E-Doc Header Field Definition
Field Description
Doc Nbr Document Number is the unique number used to identify each document. The KRA system automatically
assigns a sequential number to each document when it is created, regardless of the type of document. Also
known as the Document ID, it is generated by the workflow environment and is unique to each installation
of KRA.
Initiator Identifies the user ID of the person who created the document. The user name displayed is underlined to
indicate the ability to drill down to additional identifying information about the user by clicking the text.
Also known as the Initiator Network ID.
Sponsor Code The identification number (up to 6 digits) of the organization or agency that is providing support for the
sponsored project, as entered/selected for the Sponsor ID field on the Required Fields for Saving
Document tab of the Proposal page of a Proposal Development document (blank upon initiation). This
may include alpha or numeric characters.
Status Identifies the current state of the workflow process that the document is in.
For more information about workflow status, see Route Status in Kuali Enterprise
Workflow.
Created Identifies the time and date the document was initiated (also known as Creation Timestamp).
PI Principal Investigator is the name selected/entered from the Key Personnel page of the Proposal
Development document (blank upon initiation). The individual bearing primary responsibility for all
essential aspects of the project or protocol, including programmatic work, compliance with government,
sponsor and university policies and regulations, fiscal stewardship of sponsored funds, and all
administrative requirements of the project. This can be up to 20 characters of any type. The Principal
Investigator/Project Director/Program Director (PI/PD) is the individual designated by the grantee, and
approved by the sponsoring agency, who will be responsible for the scientific or technical direction of the
project. If more than one, the first one listed will have primary responsibility for the project and the
submission of reports. All others listed are considered co-PI/PD, and share in the responsibility of the
scientific or technical direction of the project. The term "Principal Investigator" generally is used in
research projects, while the term "Project Director/Program Director" generally is used in education, and
service projects.
Optional Fields In the Document Header:
Copied From
Document ID
When a new document is created based on a previous one by use of a copy function, the document number
of the copied document appears here.
Correct Document
ID
KRA gives you the option of reversing a fully approved document transaction through the use of the Error
Correction function. When one document is a correction of another, the document number of the document
being corrected appears here. This information is displayed only when the document was created using the
Error Correction feature from within an existing document.
E-Doc Page Tabs
Pages of e-docs appear as horizontal folder tabs, each of which contain vertically-scrollable sections. In general,
transactional e-docs in KRA have been organized so that completing them begins on the left and ends on the right.
Initial Display: The default start page typically corresponds with the page tab appearing on the left.
Show/Hide: The page that is currently-accessed (and whose contents are displayed in the body area) has its
associated page tab appear with a white background, while hidden tabs have a grey background.
Navigation & Saving: Clicking a page tab will cause its contents to appear in the body. Most require saving
prior to proceeding to the next page (page validation is performed for each save action).
General To Specific: Pages progress from general information on the left to more specific information in the
middle and workflow routing actions on the right.
Example: Populating a Proposal Development e-doc, for example, begins with basic, required information
about the proposal on the Proposal page, then monetary information display associated with the Budget
Document, the personnel involved, review requirements, questions related to the proposal, information
regarding proposal permissions, additional attached information such as documents, compliance information,
and finally, information related to the routing of the document.
Figure 38 Left-To-Right E-Doc Page Organization and Completion Flow
E-Doc Section Tabs
Sometimes referred to as panels, these are sections of e-doc pages that appear as file folder tabs that can be expanded
or collapsed using the show/hide or expand/collapse all buttons, each of which contain form fields that allow for entry
and selection of information. Vertically-scrollable.
Figure 39 An E-Doc Page with one section tab shown, other section tabs hidden
For more information about show/hide and expand/collapse functions, see Selection, Entry & Action Tools in
KRA Overview.
Tab Sections
Just like a document can have multiple pages, and a page can have multiple tabbed sections, the tabs themselves can
have multiple sections. Each is marked by a label heading with light gray text on a dark gray background, and each may
have a separate associated help icon.
Figure 40 Tab Section Examples: The Organization and Performance Site Locations sections of the Organization/Location Tab
Document Locking
In research administration, it is typical for coworkers to collaborate on putting together a single proposal. Common to
some e-docs (for example, Proposal Development documents) is a feature known as document locking that allows for
more than one person to be able to edit the same document. Refer to the individual e-doc topics within this
documentation to determine whether or not this feature is available.
For more information about locking management, see Pessimistic Document Lock in Administration.
Common E-Doc Tabs
This topic explains tabbed e-doc sections (also known as panels) that appear on more than one e-doc in the system.
While the tabs contained in various e-docs may vary from one document type to another, there is a set of four standard
tabs that are common to more than one e-doc. They are the Document Overview, Notes and
Attachments, Ad Hoc Recipients, and Route Log tabs. The basic functionality of these tabs is explained
below:
Document Overview
The Document Overview tab identifies the document and includes the Description, Explanation, and Org. Doc. #
fields.
Figure 41 KRA Document Overview Tab (Page Section)
Table 8 Document Overview Tab Definition
Field Description
Description Required. Document Description. A free-form text field that describes the purpose or function of the document
(maximum length is 40 characters).
Explanation A free-form text field that explains the purpose of the document in more detail than the Description (maximum
length is 400 characters of any type).
Org. Doc. # An abbreviation for Organization Document Number. The numeric document identification that may include
departmental or organizational information (maximum length is 10 characters).
This number is not the same as the Document Number assigned by the Kuali Financial System
(KFS).
The Description field is a required field on every e-doc. It is used by each transaction and appears in standard reports,
action list and document search.
Text entered in the Description field on the Document Overview tab appears in the respective Title column field of
the Action List table for that documents row:

The Explanation and Org Doc# field entries allow you to include additional information about the document that
become read-only columns when the document is submitted.
Notes and Attachments
The Notes and Attachments tab displays user notes, attachments, or system-generated remarks about the document. The
number of notes and/or attachments is indicated on the tab label in parentheses. It is a default service provided by the
Kuali Enterprise Workflow module, but appears on multiple documents that are a part of multiple functional modules.
Figure 42 Notes and Attachments Tab
Table 9 Notes and Attachments Tab Definition
Column Description
Posted
Timestamp
Display-only. The time and date when the attachment or note was posted
Author Display-only. The full name of the user who has added the notes or attachments.
The Author is the person who did the data-entry, not necessarily the person who completed it, or
authored it.
Note Text Required. Enter comments (type or paste from clipboard).
Attached File Optional. Displays the path and filename after selection. Select the file to attach by clicking Browse and
following Window's standard Choose File dialog box. Click CANCEL to clear the file name that you have
selected.
After an attachment is added, the field displays a paper clip icon with the file name, size and associated
application.
Browse button
Click to use your operating systems Choose File or File Upload dialog window to locate and select the file you
want to attach.
Cancel button
Click to clear the Attached File box if you have already browsed for and selected a file but have not yet clicked
the add button.
Actions This column displays the add command button. Some e-docs may also provide the ability to delete attachments,
but most do not.
Add button
Click this after populating the Attached File field via browse and select. Your note and/or file will display in a
new numbered row beneath the add: row for each note or attachment.
This tab appears on the Abstracts &Attachments page of the Proposal Development document. The basic process
for using this functionality is common to other sections such as Personnel and Internal Attachments as well. See
those respective topics for differences and specific guidelines for each.
To add an attachment:
Step 1: Type in Required Topic and Text fields and Click Browse
Step 2: Select File To Attach Using the File Upload Dialog Box (Windows XP OS example)
Step 3: After the path & name of your selection are populated, click Add
Result: Attachment Line display after the add action
Ad Hoc Recipients
The Ad Hoc Recipients tab allows you to interrupt the normal workflow routing of the document and include individuals
or workgroups in the routing path. Ad Hoc Routing does not supersede the normal workflow routing of the document but
is in addition to the normal routing. The Ad Hoc Recipients tab has two sections: Person Requests and Ad Hoc
Workgroup Requests. Use one or both of the sections to route the document to a person, workgroup, or both.
Figure 43 Ad Hoc Recipients Tab
Table 10 Ad Hoc Recipients Tab Definition
Column Description
Action
Requested
Required. Select the desired action from the Action Requested list. The choices (APPROVE, ACKNOWLEDGE, and
FYI)are actions the recipient is asked to perform.
For more information about the Ad Hoc routing see the Ad Hoc Routing topic within the Route
Levels section of Kuali Enterprise Workflow.
Person or
Workgroup
Required when you want to route the document to an individual or workgroup for the action requested. You may
route to one or both. Enter a user ID name or registered workgroup name as appropriate or use the lookups to
select them.
For more information on how to use the lookup tool to locate and select a Person or Workgroup, see
Lookup Help in KRA Overview.
Actions Add and Delete command buttons are available for either section to add or delete a line (table row) containing
your selections.
Click add in the Actions column to add the current line after youve completed your entry/selection.
Click to delete the current line.
This section appears on the Proposal Actions page of the Proposal Development document.
Route Log Tab
The Route Log tab displays the workflow status details of the document.
Figure 44 Route Log Tab
The fields on the Document Id section of the Route Log tab are display-only. However, both the Document Type and
Initiator field values are displayed as underlined text to show that you are able to click on them to drill down to more
detail about each of them. All fields appearing in the right column are date fields.
Figure 45 Additional Tabbed Sections Within the Route Log Tab
For more detailed information about the Route Log tab, see the Route Log topic within the Routing Rules
section of Kuali Enterprise Workflow.
In the Proposal Development document, this tab appears on the Proposal Actions page.
Common E-Doc Operations
This topic describes the basic e-doc operations with which you should be familiar. These procedures involve usage of
the major action options available for most transactional e-docs (for example, Proposal documents). They include
instruction on initiating e-docs, copying e-docs, saving e-docs, canceling e-docs, closing e-docs, routing e-docs,
searching for e-docs, and using the action list.
Initiating a Document
Initiating a document in KRA essentially means a new document has been created and saved (not necessarily completed
or routed). If an e-doc is started but not saved, and its initiator logs off the system, it ceases to exist. In order to save a
new e-doc, you must first complete some (not necessarily all) required fields. The status of an e-doc when first created is
INITIATED, and when saved changes to SAVED.
To initiate an e-doc:
or
1. Click the add button or an e-doc link from your main menu that corresponds to the type
of document you want to initiate.
2. Depending on your implementation of KRA, you may be prompted to log in at this point if
you have not already done so. Enter your User ID and Password as necessary to proceed.
A new, blank document is created with a unique Document ID. The status of a newly-
created e-doc prior to save is INITIATED, and is displayed as such in the document
header area.
3. Complete the required fields marked with an asterisk.
Some e-docs provide a tabbed section labeled Required Fields For Saving
Document, typically located on a default start page in multi-page e-docs. When this is
the case (as with the Proposal document, for example), there may be fields marked as
required on other pages within the e-doc that are not necessary to complete for initiation.
4. Click save.
The Status field in the document header displays SAVED.
Some selections for particular required fields cause other fields to become required,
even though they are not marked as such. For example, on the Proposal document, when
your selection for the Proposal Type field on the Required Fields for Saving Document tab
is Renewal, Revision or Continuation, the Sponsor Proposal ID field on the Sponsor
& Program Information tab becomes required. You are notified of this via red error
messages upon validation or save.
Copying a Document
Copying a document in KRA is an action that allows you to initiate a new document based on an existing document.
This enables you to take advantage of work already completed in a document and reuse it for another document that will
be similar. It saves you the effort of repeating data entry, selection, and adding attachments.
To copy an e-doc:
1. Retrieve the document you want to copy (for example, by using the doc search
feature).
2. If you used the doc search to locate the document you want to copy, click the Copy
link from the right Copy Document column of the results table.
The document opens, and by default displays the page where the Copy to New
Document tab resides (for example, in the Proposal document, this is on the Proposal
Actions page). Otherwise, navigate to the Actions page of the document and show
the Copy to New Document tab.
3. Make entries or selections as appropriate for any required fields marked with an asterisk
on the Copy to New Document tab (for example, Lead Unit is required on the Proposal
document).
4. Click the copy button (for example, copy proposal) on the Copy to New Document
tab.
A new document appears, open to the default start page (for example, Proposal page for
a new Proposal document).
The document header displays the new Document Number and the status of SAVED.
All information, including attachments, from the previous document are included.
Saving a Document
The save button appears in the action buttons area (bottom, center) of most e-doc pages on most e-docs. It generally
allows you to save your work on an incomplete e-doc and resume working on it at another time. This ability also enables
you to complete a portion of an e-doc for which youre taking responsibility and leave the remaining portions to one or
more other users you are collaborating with. Saving changes the document status to SAVED.
To save an e-doc:
1. Complete the required fields marked with an asterisk.
Some e-docs provide a tabbed section labeled Required Fields For Saving Document,
typically located on a default start page in multi-page e-docs. When this is the case (as with
the Proposal document, for example), there may be fields marked as required on other pages
within the e-doc that are not necessary to complete for saving.
2. Click save.
A message appears in the notification area (top, left of page) to indicate successful
completion of the save action:
If you started with a new, blank e-doc with a status of INITIATED, the Status field in the
document header changes to show SAVED.
Your Selections May Make Other Fields Required: Some selections for particular required fields cause
other fields to become required, even though they are not marked as required. For example, on the Proposal
document, when your selection for the Proposal Type field on the Required Fields for Saving Document tab is
Renewal, Revision or Continuation, the Sponsor Proposal ID field on the Sponsor & Program Information
tab becomes required. You are notified of this via red error messages upon validation or save.
Page Navigation Saving: Making changes to fields on one page and clicking another page tab to navigate to a
different page of an e-doc automatically saves them (without having to click the save button in between). Just as
with clicking the save button, if there are errors that prevent the save from occurring, they are displayed in red in
the notification area (top, left of page) and you are prevented from navigating to the desired page until they are
corrected.
Reloading a Page
Reloading a page simply returns the page to the state it was in when last saved. This is accomplished by clicking the
reload button, which appears in the action buttons area on most pages of most e-docs. Use this feature when you want
to start over from where you began and eliminate recent modifications.
Clicking reload means that any changes youve made to the current page, prior to saving or navigating to a
different page, will be lost!
To reload an e-doc:
1. Click reload.
A message appears in the notification area (top, left of page) to indicate successful completion of
the reload action:
Selections and entries on the currently-accessed page return to how they appeared the last time
the document was saved.
Closing a Document
Closing a document is accomplished by clicking the close button, which appears in the action buttons area at the bottom,
center of most pages of most e-docs.
To close an e-doc:
1. Click close.
You are prompted to save the document first:
2. Click yes if you want to save changes youve made, or no to return the document to its state as
of the last save.
The document closes and you are taken to your default menu.
Canceling a Document
The cancel button does not simply cancel the recent changes youve made on the current page or revert to a
previously-saved version of the document (which is accomplished via reloading), but instead it cancels the ability
to route and/or submit the document. You can copy a canceled document to a new document number that
essentially moves your work from the canceled document to a new one.
To cancel an e-doc:
1. Click cancel.
You are asked for a confirmation:
2. Click yes.
The status is changed to CANCELED.
The document closes and you are returned to your main menu.
You are no longer able to route or submit this document. However, if you want to preserve data entry/selection
and/or attachment work from this document, you are able to copy it.
For more information about e-doc copying, see Copying a Document in this section.
Routing a Document
The e-doc process supports both pre-established Workflow routing and Ad Hoc routing. In the Workflow routing, KRA
routes the document to the proper users based on business rules established in Workflow. Ad Hoc routing allows you to
route the document to one or more individual users and/or workgroups for Approval, Acknowledgement, or FYI.
Unless you want to add an Ad Hoc routing, click the route workflow action button from the bottom, center of the
documents Actions page to route the document in the predefined routing hierarchy.
To route an e-doc:
When your document is validated for correctness and completeness, you are then able to
route it to other users for their review and approval. If errors are present, the document will
not route. It is a good idea to turn on the Data Validation prior to routing to ensure all errors
are identified and fixed first.
1. Click route from the action buttons area of the documents Actions page (for example, the
Proposal Actions page of the Proposal document).
The notification area displays a message indicating the document was successfully routed:
The document status changes to ENROUTE until requested actions are taken by those on the
route.
As the document travels through the route and actions are taken, the routing status changes to
any one of the following:
Searching for a Document
Searching for a document is done by first clicking the doc search button from the toolbar of any KRA screen (located to
the right of the action list button). Search criteria fields allow you to select and/or enter criteria and then click a search
button to produce a results table. From the results table, you are able to click a link to directly open the document you
were searching for.
This only covers how to perform a Basic Search. For more detailed information about advanced search features,
search result table drill-down action options, Detailed Searches and Superuser Searches, see Document Search
in Kuali Enterprise Workflow.
Figure 46 Basic Search Criteria Fields
Table 11 Basic Search Criteria Field Definition
Search Field Description
Document Type Use the lookup function to find and select by returning a value for the type of e-doc you want to search for.
Your selection here may cause additional search criteria fields to appear (for example, if you
select Proposal document, the role fields appear for Aggregator, Budget Creator, Narrative Writer,
Viewer & Approver.
Initiator Network Id
Enter the User ID of the user who initiated the document or select it from the lookup .
Document Id Enter the unique identification number assigned by the system to the document or select it from the lookup
.
Date Created Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on the calendar
icon to specify the range of document creation dates to search. You may select the From date only, or
the To date only, or both.
Name this search Enter a textual name for the search if you want to save the search criteria for future use. All saved searches
are available from the Named Searches list at the top of the document search screen.
To search for an e-doc:
1. Click doc search from the top, left of any KRA screen.
The workflow Document Search screen appears:
2. Enter and/or select search criteria in the Search for a Document section of the screen as
desired.
3. Click search.
The results of your search are displayed in a table that appears below the criteria section of the
screen:
4. Click on an underlined link appearing in the Document Id column of the search result table to
access (open) the document.
Wildcard * Use: The use of asterisks in the search criteria allows you to perform pattern matching. If you want
to search for documents containing a string of characters in the alphanumeric fields such as the document title, you
may enter a character string in the search criteria accompanied by asterisks. For example, enter *test to search
for a document title that ends with the word test. Enter test* to search for a document title that begins with
the word test. Enter *test* to search for a document title that has the word test somewhere in the document
title.
Using the Action List
Use the Action List to view and act on the documents currently pending your completion, acknowledgement, approval,
and FYI.
Documents sent to your Action List may request various types of actions from you. The most commonly requested
actions are:
Complete: Your are being asked to complete a portion of an incomplete document, which requires you to
open, change and save the document to clear this from your Action List.
Approve: Verify that the document content is acceptable. Approved documents continue routing to additional
approvers, or if fully approved, are submitted.
Acknowledge: A request to view and acknowledge an e-doc, without the need for a formal approval. You
must open the document from your Action List to clear it out. This is the type of action request generated back
to prior Approvers and the Initiator when a document is disapproved.
FYI: A courtesy request allowing you to view the document or to just clear the request from your Action List
without viewing it.
Accessing the Action List is accomplished by clicking the handy workflow toolbar button located in the upper left corner
of most KRA screens.
To act on an e-doc using Action List:
1. Click action list from the toolbar of any KRA screen.
The Action Requested column displays what youre being asked to do for each
document row (for example, COMPLETE).
2. Click a Document Id column link to access a document (for example, 2128).
3. Navigate to the Actions page of the document (for example, Proposal Actions for the
Proposal document).
Appropriate action buttons appear at the bottom, center of the page that allow you to
accomplish the action that is being requested from you (for example, blanket
approve, approve, or disapprove):
For e-docs that do not have multiple pages or do not have a separate page dedicated
to actions, the workflow action buttons will likely appear at the bottom, center of any
page.
Common Line Item Operations
Many tabbed e-doc sections in KRA have functionality that allows you to add line items. You fill in enough information
in required field(s) on a blank line and then click an add button, which causes your line to be added as a new row in a
table within the tab. Additional buttons may appear after a line has been added such as delete to remove the line item or
edit to make modifications to a line item.
To add a line to an e-doc section:
1. Enter text and/or make selections in the Add rows blank fields (some may be
marked required, and thus must be populated at a minimum to proceed).
2. Click the add button, typically appearing under the Actions column on the right
of the Add line.
A new, numbered line item row is displayed in the table below that contains the
content you entered.
Subsequent additions appear sequentially in descending, top-to-bottom order.
After a line is added, new action buttons typically appear in the Actions
column on the right of each line row.
Click delete to remove the line item (numbered row) from the table list.
Some sections may include the ability click a copy button that adds a duplicate
line that can then be edited further.
For financial, accounting, and/or budget-related line items, you are often
presented with a recalculate button that adds amounts in recently-added lines
to a section that displays totals.
These are just a few of the basics. Not all tabbed sections of e-doc pages that contain line item functionality are the
same. In fact, most contain very specific functions and additional action options that are not covered here. For
more detailed information about line item operations and complete instructions, see the specific subtopic for each
individual tab.
Summary
This topic gave you step-by-step procedural task instructions for carrying out actions that are common to most KRA
electronic documents. The focus was on the development and editing of Proposal and Budget documents for standard
end users. However, what was not covered was the less commonly-performed review and approval of maintenance
documents. E-docs must be approved by all those in the predefined route in order to move a document to FINAL status
and thereby allow final disposition actions like submission to Grants.gov to happen, so changes are not activated in the
system until this occurs.
For complete details about all e-doc action options and complete routing information, see Kuali Enterprise
Workflow.
Common Maintenance Document Operations
This topic describes the basic operations of maintenance documents with which you should be familiar. Many KRA
maintenance documents have a consistent look and feel, shared features, and similar functionality. KRA maintenance
documents are usually updated in the same manner based on the Kuali Nervous System (KNS) features running on the
Kuali Enterprise Workflow engine. The task steps that follow guide you through some of the most standard actions
associated with typical maintenance e-docs. They include instruction on searching for, initiating, copying, editing,
saving, and routing maintenance documents.
Overview
KRA relies on a variety of user-defined reference tables to function. These tables define the attributes that the system
uses for validation and to allow you to look up values as necessary. They also control the often complex relationships
between elements for internal and external reporting. These reference tables are maintained by e-docs that are
commonly referred to as maintenance documents. They are typically maintained by the members of the central
administration area of an institution.
Each of the KRA reference tables is maintained by a specific maintenance e-doc which is routed for approval before the
table is updated. Whereas all users can lookup KRA reference table information, access to their maintenance documents
is limited to the members of a particular workgroup and only the authorized members of the workgroup can approve the
updating of the tables. While privileged members have the ability to initiate new maintenance documents, other users
may only search for the values from the lookup screens, depending on permissions.
KRA contains many maintenance documents grouped by related functions on the Maintenance menu. Each provides a
handy, e-doc user interface for creation and maintenance of reference table information that is used by other e-docs in
KRA. They allow for lookup and selection of valid values when populating fields to complete other e-docs. All of the
maintenance documents are viewed and maintained in a similar fashion. Selecting the desired reference table link from
the maintenance menu takes you to that maintenance documents lookup screen. From that screen you may create a new
document by clicking the create new link, or search the table to view, edit, or copy a table value. These common
operations are explained below, using the Proposal Type maintenance e-doc as an example.
Maintenance Document Access
When you click a link from a menu group box on the Maintenance menu, you are by default taken first to a lookup
screen associated with that maintenance document. From lookup results, you are then able to access existing
maintenance document screens by clicking edit links. Additionally, most maintenance document lookup screens have a
create new button in the top, right corner that allows you to initiate a new, blank maintenance document.
Figure 47 Maintenance Document Lookup screens and the create new button
Maintenance Document Layout
The typical maintenance e-doc contains the standard tabs such as Document Overview, Notes and Attachments, Ad Hoc
Recipients, and Route Log. Additional tabs that are unique to each individual maintenance e-doc are located in between
the Document Overview and Notes and Attachments tabs. Most maintenance e-docs have just one unique tab that allows
you to specify the details associated with the reference object. Similarly, most maintenance e-docs contain just one page,
and thus are displayed on a single screen in KRA. Standard action buttons appearing at the bottom, center of most
maintenance e-docs are route report, submit, save, blanket approve, close, and cancel.
Figure 48 Maintenance Document Tabbed Sections
About the Edit Tab: Each maintenance document has its own unique tab named Edit xxx where xxx is the
name of the table values that you want to maintain. The layout and data fields within the Edit tab vary depending
on the document type and whether you are creating, editing or copying the document
For information about how to use the common tabs such as Document Overview, Notes and Attachments, and Ad
Hoc Recipients, and Route Log, see the Common E-Doc Tabs topic in E-Doc Fundamentals.
Figure 49 Common Maintenance Document Action Buttons
Searching for a Maintenance Document
Searching for a maintenance document may be accomplished by clicking on a link for the type of maintenance document
you want to view, conducting a search from the lookup screen, and clicking on a search result value drill-down link.
Follow this procedure when you want to locate and view a record when the type of maintenance document is already
known.
To search for a maintenance e-doc:
1. Select the desired maintenance e-doc by clicking a link from within one of the menu
groups on the Maintenance screen (for example, Proposal Type).
The lookup screen for the maintenance e-doc you selected appears:
2. Enter appropriate search criteria (or leave blank to retrieve all) and then click
search.
3. Click the link (underlined value in the left column of the search results table) for the
value you want to view (for example, 1).
A pop-up window appears that displays the value details (code value and
description):
Initiating a Maintenance Document
Initiating a maintenance document is essentially the act of creating a new record entry for a reference table. It is
accomplished by first selecting the specific reference table by clicking the desired Maintenance menu link and then
clicking the create new button from its lookup screen.
To initiate a maintenance e-doc:
>
1. Click an underlined maintenance document link from any menu group box bullet
list on the Maintenance menu (for example, Proposal Type from the Proposals
menu group).
The Lookup screen associated with the maintenance document appears (for
example, Proposal Type Lookup):
2. Click create new from the top, right corner of the Lookup screen.
A new, blank maintenance document appears with an unique document number and
INITIATED status displayed in the document header area (for example, Proposal
Type Maintenance Document):
3. Populate required fields by entering text or making selections as necessary (and
populate remaining optional fields with information as desired).
For specific field entry requirements, see the respective maintenance document
topics field definition table.
4. Complete the common document tabs: Document Overview, Notes and
Attachments, and Ad Hoc Recipients tab as needed.
For information about how to use the common tabs such as Document
Overview, Notes and Attachments, and Ad Hoc Recipients, and Route Log, see the
Common E-Doc Tabs topic in E-Doc Fundamentals.
Clicking save changes the status from INITIATED to SAVED and allows you
to return to work on the document again in a subsequent session.
Clicking submit automatically saves changes and workflow routes it for approval.
Review the Route Log tab as desired.
For more information about the Route Log, see the Route Log topic in Kuali
Enterprise Workflow > Routing Rules.
Upon approval, the status is changed to FINAL. At this point the maintenance
document not only is initiated, but is also operational because the reference table is
updated in the system.
Editing a Maintenance Document
Editing maintenance documents is done by clicking a maintenance document link from a menu group on the
Maintenance menu screen, conducting a search on the lookup screen, and then clicking an edit link from a search result
table row. This opens the maintenance document with an Edittab that displays two columns: Old is static and
displays the present values for each field; and New is partially dynamic and allows modification by entry/selection of
different values for non-identifying fields.
To edit a maintenance e-doc:
1. Select the desired maintenance e-doc by clicking a link from within one of the
menu groups on the Maintenance screen (for example, Proposal Type).
2. Enter appropriate search criteria (or leave blank to retrieve all) and then click
search.
3. Click the edit link in the Actions column for the record (result table row) you want
to edit.
The maintenance document appears with both Old and New columns on the
Edit Tab:
In the edit mode, note that certain fields are not editable. You are only
allowed to change the non-identifying fields associated with the KRA code you are
trying to edit. When the active/inactive flags are available for the reference table,
you can first make the existing code inactive and then create a new code to change
the identifying fields. If the active/inactive flags are not available, the changes
must be made by the technical staff.
4. Make modifications as necessary to required, editable fields within the New
column section of the Edittab.
For specific field entry requirements, see the respective maintenance document
topics field definition table.
6. Click submit.
7. Review the Route Log tab.
For more information about the Route Log, see the Route Log topic in
Kuali Enterprise Workflow > Routing Rules.
Non-Editable Maintenance Documents: There are some view-only maintenance documents that are not
editable because all fields in the table are key identifying fields (for example, the Country Maintenance Document).
When you search for a maintenance document like this, you are not able to see the edit link in the lookup screen
result table. These tables must be updated directly in the database by the technical staff.
Copying a Maintenance Document
Copying a maintenance document is done when you want to create a new maintenance document that is similar to an
existing one so that you can take advantage of reusing existing information and not have to re-enter it. After the copy is
made, you can then make changes that make it unique from the one you copied. This is accomplished by first using a
lookup screen for the maintenance document type to search for the one you want to copy, and then clicking a copy action
link to create the new document with new identification number.
To copy a maintenance e-doc:
1. Select the desired maintenance e-doc by clicking a link from within one of the menu groups on
the Maintenance screen (for example, Proposal Type).
2. Enter appropriate search criteria (or leave blank to retrieve all) and then click search.
3. Click the copy link from the Actions column of the lookup result table for the document you
want to copy.
A new maintenance document is created with an unique document number.
The Edit tab contains both the Original (static) and New Copy (editable) column sections:
4. Make changes to editable fields as desired.
At a minimum, you must ensure required fields are populated.
5. Complete the common document tabs: Document Overview, Notes and Attachments, and Ad
Hoc Recipients tab as needed.
For information about how to use the common tabs such as Document Overview, Notes
and Attachments, and Ad Hoc Recipients, and Route Log, see the Common E-Doc Tabs
topic in E-Doc Fundamentals.
6. Click submit (or save if you want to submit it at a later time).
For more information about the Route Log, see the Route Log topic in Kuali Enterprise
Workflow > Routing Rules.
Submitting a Maintenance Document
Submitting a maintenance document routes it via workflow to predefined reviewers and approvers on the route (and any
ad hoc recipients you added). Each of the KRA reference tables that is maintained by a specific maintenance e-doc can
only be updated as a result of the maintenance e-doc being routed for approval. Only authorized members of particular
maintenance workgroups can approve the maintenance e-docs and thereby update the reference tables.
To submit a maintenance e-doc:
or
1. Access a saved maintenance document by clicking a search result table edit link or
initiate one by clicking the create new button from a lookup screen.
2. Ensure required fields are populated.
4. Click submit from the action buttons area at the bottom, center of the maintenance
document screen.
For more information about the Route Log, see the Route Log topic in Kuali
Enterprise Workflow > Routing Rules.
Saving a Maintenance Document
Saving a maintenance document is possible after initiation, and at any time prior to submission. It allows you to
complete only a portion and return to edit and complete it at a later time. This is accomplished by clicking the save
action button located at the bottom, center of the maintenance document screen.
Some maintenance documents may require that certain fields be completed first in order to save the document.
When this is the case, and it is not evident in the user interface, system messages will alert you appropriately by
displaying red error notifications after clicking the save button. You are prevented from completing the save action
until you comply with the prompts that tell you which fields you must first populate.
To save a maintenance e-doc:
or
1. Access an existing saved maintenance document by clicking a search result table
edit link or initiate one by clicking the create new button from a lookup screen.
2. Ensure required fields for saving document are filled in.
3. Click save.
If the document was new, the status changes from INITIATED to SAVED.
Closing a Maintenance Document
Closing a maintenance document is accomplished by clicking the close button, which appears in the action buttons area
at the bottom, center of the maintenance document screen.
To close a maintenance e-doc:
1. Click close.
You are prompted to save the document first:
2. Click yes if you want to save changes youve made, or no to return the document to its state as
of the last save.
The document closes and you are taken to your default menu.
Canceling a Maintenance Document
The cancel button does not simply cancel the recent changes youve made to a maintenance document or revert to a
previously-saved version, but instead it cancels the ability to submit the document to workflow and route it for
review and approval. You can copy a canceled maintenance document to a new document number that essentially
moves your work from the canceled document to a new one.
To cancel a maintenance e-doc:
1. Click cancel.
You are prompted to confirm:
2. Click yes.
The status is changed to CANCELED.
The document closes and you are returned to your main menu.
You are no longer able to route or submit this document. However, if you want to preserve data entry/selection
and/or attachment work from this document, you are able to copy it.
For information about copying a maintenance document, see Copying A Maintenance Document.
Maintenance Document Rules & Routing
Business Rules
All users can look up table values
Only members of a predefined Initiators workgroup can initiate a document to create or modify the table values
Only members of a predefined table maintenance workgroup can approve maintenance documents
After approval, KRA changes the status to FINAL and the reference table is updated with the new values
Workflow Routing
Figure 50 Maintenance Document Workflow
Summary
This topic gave you step-by-step procedural task instructions for carrying out actions that are common to most KRA
maintenance documents. The focus was on the establishment and editing of maintenance documents for standard end
users. However, what was not covered was the less commonly-performed review and approval of maintenance
documents. Maintenance documents must be approved in order to move a document to FINAL status and update the
reference tables accordingly, so changes are not activated in the system until this occurs.
For complete details about all maintenance document action options and complete routing information, see Kuali
Enterprise Workflow.
88 Researcher Menu Kuali Research Administration v.1.0 User Guide
Researcher Menu
The Researcher menu screen is accessed by clicking the Researcher menu tab that is located in the header area of any
KRA screen.
It is comprised of the following menu groups:
Figure 51 Researcher Menu
Table 12 Researcher Menu Group Descriptions
Menu Group Description
Proposals Houses three links related to proposals: Create Proposal initiates a new, blank proposal; Proposals in Progress
conducts a search of all proposals with a status of IN PROGRESS; and All My Proposals conducts a search
of all proposals for which you are associated (for example, as an Initiator or Aggregator).
Awards Future release functionality.
Negotiations Future release functionality.
Protocols Future release functionality.
Compliance Future release functionality.
Quick Links Includes a direct external hyperlink to the area of the Grants.gov Web site that allows you to search for and
view details of grant opportunity listings.
Kuali Research Administration v.1.0 User Guide Researcher Menu 89
Personnel Future release functionality.
Workflow Contains a link to a workflow screen that allows you to update your Action List settings for a customized
appearance and functionality based on your preferences.
90 Researcher Menu Kuali Research Administration v.1.0 User Guide
Proposals Menu Group
The Proposals menu group includes the following three links:
Create Proposal
For complete details of how to create a new proposal document, see Proposal Development
Document._D2HLink_705
Proposals In Progress
For more information about using the Proposals in Progress link, see Document Search in Kuali Enterprise
Workflow.
All My Proposals
For more information about using the All My Proposals link, see Document-Specific Searches in Kuali
Enterprise Workflow > Document Search.
Quick Links Menu Group
The Quick Links menu group includes the following two links:
Current Locks
For more information about current locks, see Current Locks in Maintenance Documents.
Grants.gov Opportunity Lookup
For more information about using lookup screens, see Lookup Help in KRA Overview, and for more
information about Grants.gov opportunities, see also Grants.gov Page in Proposal Document.
Change Password
Kuali Research Administration v.1.0 User Guide Researcher Menu 91
Workflow Menu Group
The workflow menu group contains the following link that allows you to customize the appearance and functionality of
your Action List:
Preferences
For more information about setting preferences, see Preferences in Kuali Enterprise Workflow > KEW
Operations.
92 Unit Menu Kuali Research Administration v.1.0 User Guide
Unit Menu
The Unit screen is accessed by clicking the Unit menu tab that is located in the header area of any KRA screen.
Figure 52 Unit Menu
Table 13 Unit Menu Group Descriptions
Pre-Award Includes the add new button for Proposal Development, which creates a blank Proposal document.
Post-Award Future release functionality.
Pre-Submission Future release functionality.
Kuali Research Administration v.1.0 User Guide Unit Menu 93
Compliance
Post-Submission
Compliance
Future release functionality.
Quick Links Includes a direct external hyperlink to the area of the Grants.gov Web site that allows you to search for and
view details of grant opportunity listings. Non-employee Lookup and Sponsor Lookup links allow you to
conduct inquiries that display results in the form of links to maintenance documents which contain valid
values from reference tables.
Workflow Links to several workflow-related application screens that allow for customization of routing functionality.
Pre-Award Menu Group
The Pre-Award menu group houses four functions (link and lookup buttons) for screens and information related to the
activities leading up to a contract or grant being awarded by a sponsor agency.
Future Release Functionality Note: Submitted Proposal, Proposal Log, and Negotiations are inactive functions
intended to be completed after release 1.0.
Link Description
Proposal
Development
Click the plus button to cause a new (blank) Proposal Development document to appear that will allow
you to start, save and submit a proposal. Click the lookup button to search for existing Proposal
Development documents.
Proposal Development Add Button
For complete details of how to develop a proposal by creating/adding a new proposal document, see Proposal
Development Document._D2HLink_713_D2HLink_714_D2HLink_715
94 Unit Menu Kuali Research Administration v.1.0 User Guide
Quick Links Menu Group
The Quick Links menu group contains the following links:
Current Locks
For more information about current locks, see Current Locks in Maintenance Documents.
For more information about using lookup screens, see Lookup Help in KRA Overview, and see also
Grants.gov.
Non-employee Lookup
For more information, see Lookup Help in KRA Overview, and see also Rolodex Maintenance Document in
Maintenance Documents.
Sponsor Lookup
For more information, see Lookup Help in KRA Overview, and see also Sponsor Maintenance Document in
Maintenance Documents.
Change Password
Workflow Menu Group
The Workflow menu group is made up of the following links:
Preferences
For more information about setting preferences, see Preferences in Kuali Enterprise Workflow > KEW
Operations.
Kuali Research Administration v.1.0 User Guide Unit Menu 95
Routing Report
For more information, see Routing Report in Kuali Enterprise Workflow.
Rules
For more information, see Rules in Kuali Enterprise Workflow.
Rule QuickLinks
For more information, see Rule QuickLinks in Kuali Enterprise Workflow.
Workgroup
For more information, see Workgroup in Kuali Enterprise Workflow.
96 Central Admin Menu Kuali Research Administration v.1.0 User Guide
Central Admin Menu
The Central Admin screen is accessed by clicking the Central Admin menu tab that is located in the header area of any
KRA screen. In KRA release 1.0, it is identical to the Unit menu. In future releases of KRA, it will be uniquely
different than the Unit menu to provide access to functionality commonly used by central administrators.
For more information, see Unit Menu.
Kuali Research Administration v.1.0 User Guide Maintenance Menu 97
Maintenance Menu
The Maintenance screen is accessed by clicking the Maintenance menu tab that is located in the header area of any KRA
screen. Its general purpose is to provide access to maintenance documents (also referred to as Reference Documents
or Maintenance E-Docs), which are electronic documents that provide a user interface into reference tables that allows
you to create and maintain information that is referenced by other e-docs in KRA.
The Maintenance menu screen is comprised of the following menu groups:
98 Maintenance Menu Kuali Research Administration v.1.0 User Guide
Figure 53 Maintenance Menu Screen
Table 14 Maintenance Menu Group Descriptions
Shared Links to maintenance documents that contain reference table information that is shared by more than one e-
doc.
Miscellaneous Certain unrelated maintenance documents that defy easy grouping into the other menu boxes on this menu
screen. While they dont logically fit into other categories, they may still be used in more than one place
within the application and by existing modules.
Proposals Conveniently groups together links to maintenance documents used by the Proposal document and/or Budget
document in the Proposal Development module.
Awards Future release functionality.
Compliance
Conflict of
Interest
Future release functionality.
Compliance Future release functionality.
Shared Menu Group
The Shared menu group is a box with a bullet list of links that take you to maintenance document lookup screens for
maintenance documents that are shared by more than one document and/or module in the system. From those lookup
screens you are able to edit existing or create new maintenance documents for reference information used throughout
KRA.
For basic process information about creating and updating maintenance documents, see Common Maintenance
Document Operations in KRA Overview.
The links appearing in the Shared menu group are:
Activity Type
Approval Type
Budget Category
Budget Category Mapping
Budget Category Maps
Budget Category Type
Cost Element
Custom Attribute
Custom Attribute Document
Institute LA Rate
Institute Rate
Investigator Credit Type
Keywords
Non-employee Lookup
Notice of Opportunity
NSF Science Code
Organization
Object Code
Proposal Type
Rate Class
Rate Class Type
Rate Type
Questions
Special Review
Special Review Approval Type
Unit Administrator
Valid Special Review Approval
Valid Calculation Type
Valid Cost Element Rate Type
Miscellaneous Menu Group
The Miscellaneous menu group is just that, a menu where links to maintenance documents that dont logically fit into
other groups are located.
Links appearing in this group are:
Country
Current Locks
Sponsor
Sponsor Forms
Sponsor Form Templates
Sponsor Type
State
Unit Hierarchy
Proposals Menu Group
The Proposals menu group conveniently consolidates links to maintenance documents that are specifically used in the
maintenance of reference table information used by Proposal and Budget documents in the Proposal Development
module.
Abstract Type
Budget Status
Cost Element
Deadline Type
Degree Type
Mail By
Mail Type_D2HLink_784
Narrative Status
Narrative Types
Person Document Type
Person Table Editable Columns
Proposal Columns To Alter
Rate Class
Rate Type
S2S Submission Type
S2S Revision Type
Valid Calculation Type
Valid Cost Element Rate Type
Kuali Research Administration v.1.0 User Guide System Admin Menu 105
System Admin Menu
The System Admin screen is accessed by clicking the System Admin menu tab that is located in the header area of any
KRA screen. Its general purpose is to provide links to screens and functions related to technical configuration and
monitoring of the KRA system, including system parameters & services, batch schedules, and workflow functions.
Figure 54 System Admin Menu Screen
Table 15 System Admin Screen Menu Group Descriptions
System Provides access to functions related to the configuration and operation of the KRA software application.
Batch Link to functionality related to the configuration and scheduling of automated processing of large quantities
of data. You are able to search for and monitor batches that are named and grouped. The batch processes are
scheduled by a job, which is a logical grouping of various steps required to accomplish a task in a batch
process.
Service Bus Houses items pertaining to a middleware architecture construct that allows for integrating enterprise
applications in an implementation-independent fashion. The Kuali Service Bus (KSB) specifically provides a
messaging fabric as well as allowing acquisition of services on the bus using a service registry and invocation
of those services using various protocols (java serialization over HTTP and SOAP).
Workflow Provides access to functions related to the configuration of document routing and approval services.
106 System Admin Menu Kuali Research Administration v.1.0 User Guide
System Menu Group
The System menu group provides access to functions related to the configuration and operation of the KRA software
application. It is comprised of the following links:
Current Locks
Parameter
Person
Person-Role
Role
Role-Permission
Workflow Menu Group
The Workflow menu group provides access to functions related to the configuration of document routing and approval
services. It is comprised of the following links:
Application Constants
Document Operation
Document Type
Rule Attribute
Kuali Research Administration v.1.0 User Guide System Admin Menu 107
Rule Template
Statistics Report
Workgroup Type
XML Ingester
108 Proposal Development Document Kuali Research Administration v.1.0 User Guide
Proposal Development Document
This topic explains how to create, maintain, route and submit Proposal documents. Proposal documents are electronic
documents that are part of the KRA Proposal Development module and are linked to Budget documents in the system.
A Proposal in KRA can be developed by an individual or a group. It provides detailed technical and business
information pertaining to a proposed project that is presented to potential outside sponsor organizations, either in
response to a specific funding announcements, or unsolicited. Ideas for possible projects are submitted to
agencies/sponsors for their review and consideration. If the ideas proposed to the agency/sponsor are favorable to both
parties involved, the successful outcome of the proposal submission is that an award agreement to the institution is
initiated that grants the researcher a designated dollar amount for use in their outlined mission.
Overview
The Proposal Development Document e-doc screen is comprised of a document header, ten pages, with action buttons
appearing at the bottom (some of which are unique to specific pages). The proposal development document represents a
series of pages that enable the user to create an electronic version of the proposal, but it also includes access to
functionality to the Budget Document, which is a separate e-doc that is meant to be used in conjunction with the
proposal. These pages will accommodate all the information required by the sponsor and the institution for a full
proposal submission.
When the new Proposal Development Document appears, the document type is displayed in the upper, left corner of the
screen just under the header area.
Kuali Research Administration v.1.0 User Guide Proposal Development Document 109
Access
Here are some of the various ways you can access a Proposal document:
Researcher menu > Proposals menu group > Create Proposal link
Unit menu > Pre-Award menu group > Proposal Development add button
Central Admin menu > Pre-Award menu group > Proposal Development add button
Action List screen > Document Id column > link
Doc Search screen > Search Results table > Document Id column > link
Budget document > return to proposal button
For more information about accessing Proposal documents from Budget documents, see Return To Proposal
Navigation in Budget Document.
User Interface Labeling Differences:
Proposal Development Document, Proposal Document, Proposal E-Doc and Proposal refer to the same thing in
KRA and are user interface terms that may be used interchangeably, both within the KRA user interface screens
themselves, and throughout the various types of KRA documentation when referencing them.
The Create Proposal link and Proposal Development add button accomplish the same thing: the creation (or
initiation) of a new, blank Proposal document with a unique document number.
Document Number, Doc Nbr, and Document ID refer to the same thing in KRA and are user interface terms
that may be used interchangeably.
Document ID links from Action List or Doc Search workflow screen tables both access existing (as opposed to
new) Proposal documents.
For more information about accessing existing documents from action list or search result tables, see Kuali
Enterprise Workflow.
Document Header Proposal
The document header in the Proposal document (top, right corner of screen) displays six fields of identifying information
about the proposal.
Figure 55 Proposal Document Header (different than standard)
The new Proposal Development Document is automatically assigned a Document Number (Doc Nbr) by the system with
a status of In Progress. This information is displayed in the upper, right corner of the screen.
Table 16 Document Header Definition Proposal Document
Field Description
Doc Nbr This is a number that uniquely identifies the proposal that is currently accessed and displayed.
Initiator The user name of the person who first added (or created) this proposal.
Sponsor
Name
The textual name that uniquely represents the primary sponsor associated with this proposal (required entry by
Initiator during add process).
Status The state this document is currently in as it relates to the completion of the document (not its routing or
submission).
Created The time and date this document was created.
PI The textual name of the Principal Investigator as specified on the Key Personnel page. The individual bearing
primary responsibility for all essential aspects of the project or protocol, including programmatic work,
compliance with government, sponsor and university policies and regulations, fiscal stewardship of sponsored
funds, and all administrative requirements of the project. The Principal Investigator/Project Director/Program
Director (PI/PD) is the individual designated by the grantee, and approved by the sponsoring agency, who will be
responsible for the scientific or technical direction of the project. If more than one, the first one listed will have
primary responsibility for the project and the submission of reports. All others listed are considered co-PI/PD,
and share in the responsibility of the scientific or technical direction of the project. The term "Principal
Investigator" generally is used in research projects, while the term "Project Director/Program Director" generally
is used in education, and service projects.
It is important to note that the document headers in KRA are not always the same regardless of document type (for
example, the Budget documents is slightly different than other e-docs).
For more about the information displayed in this area of the screen, see the Document Header topic in KRA
Overview.
Pages Overview
Proposal documents are made up of the following ten pages, each of which contain one or more tabbed sections:
Figure 56 Proposal Document Page Menu
Each clickable folder tab represents a different page within the larger Proposal Development Document. The
currently-displayed pages tab has a white background, while the others have a grey background. The Proposal tab is by
default the first tab to be displayed. In general, the pages are ordered in such a way as to facilitate completion from left
to right.
Table 17 Brief Descriptions of Proposal Document Pages
Page Description
Proposal Record basic proposal information, including a minimum amount to save a work-in-progress document.
Budget Versions View information about the different potential budgets that are works in progress in addition to the one
currently accessed. One of these candidates will eventually be selected to be the final version associated with
a Proposal document. This is the page that is displayed by default when the Budget document is first
accessed.
Key Personnel The role in which each Key Person will be assigned for the proposed sponsored project. A named contributor
(other than the PI) who is integral to the proposed sponsored project, or who makes a significant contribution
to the scientific development or execution of the project, including Consultants (if applicable) and mentors on
Career awards. This includes Key Personnel and Other Significant Contributors as defined by NIH and
Grants.gov. All individuals who contribute in a substantive, measurable way to the scientific development or
execution of the project or protocol, whether or not salaries are requested (NIH definition).
Special Review A special review refers to a grant proposal that requires additional review by an institutional committee or
official (e.g. proposals that include the use of human participants in research).
Custom Data A set of additional data elements needed that are not available out of the box from the application.
Questions Collect institution-specific data by question groups. In the Proposal module, the Questions page is also used
to collect answers to specific grants.gov questions.
Permissions Identify which users are permitted to perform which actions to which areas of the document.
Abstracts &
Attachments
The abstract, or project summary, is a concise, clear, and brief description of the project. It should outline the
problem, the objectives, expected outcomes, including significance of the project to the field being studied.
The abstract is usually written in less technical language than the proposal narrative.
Grants.gov Submit federal proposals directly to the Grants.gov on-line system for certain funding opportunities, based on
eligibility requirements specified by each sponsoring agency.
Proposal Actions This page allows you to validate the document against predefined rules, fix errors, print, copy & route the
Proposal document for approval.
Proposal Page
The Proposal page of the Proposal Development Document serves the purpose of recording the basics of a proposal. It is
designed to require a minimum amount of general information to constitute a proposal-in-progress worthy of saving to
complete and submit at a later time. This information includes describing the nature of the proposal; specifying the type
of proposal; identifying the potential sponsor and the target start and end dates involved; and entering the relevant
sponsor, program and organization contact information. It is the first page displayed by default after clicking the
Proposal Development option on the Pre-Award menu. Populating, at a minimum, the required fields on this page
allows you to save the document as a working draft and proceed to the other pages.
Figure 57 Proposal Page Tabs
Document Overview Tab
For more information about the Document Overview tab, see Document Overview in Common E-Doc Tabs.
Required Fields for Saving Document Tab
The Required Fields panel is critical to the Proposal and Budget Development module because it collects information
that is required to start a proposal or budget document. Having all the required fields completed in a proposal
development document allows the development record to be saved and recorded in the KRA system.
Figure 58 Required Fields for Saving Document Tab
Table 18 Required Fields for Saving Document Tab Definition
Field Description
Required Fields for Saving Document section
Proposal ID The unique proposal number identifying a proposal. This is a system generated, sequential number.
Proposal Type
Click the down arrow to display the list and click on an item in the list to highlight and select it to
populate the box with your selection.
Lead Unit The proposal's fixed home unit that will be used for routing and business rule purposes. AKA Owned by
Unit. The designated unit responsible for the application and administration of the proposed sponsored
project. Click the down arrow to display the list and click on an item in the list to highlight and
select it to populate the box with your selection.
Activity Type Select from the list to specify the type of activity proposed, (for example, organized research or
instruction). Activity type refers to the major functions of an institution based on OMB Circular A-21.
Per OMB Circular A-21, the major functions of a "university" are instruction, sponsored instruction and
teaching, departmental research, organized research, sponsored research, university research, other
sponsored activities, and other institutional activities. Each account in an institution's financial system
must be identified by its activity type. Click the down arrow to display the list and click on an item
in the list to highlight and select it to populate the box with your selection.
Project Title The proposed title of the project.
Sponsor ID The identification number of the organization or agency that is providing support for the sponsored
project. What you enter or select for this field will appear on the Document Header after you save the
document. Type the value if known in the box, otherwise, search for and select it and populate the box
automatically by using either the lookup or direct inquiry functions.
Project Start Date In the Proposal Module, this is the requested project start date for the project in the proposal. These two
fields may not be the same. Enter the date in mm/dd/yyyy format or select it using the date selector by
Field Description
clicking on the calendar icon .
Project End Date The date the project period will terminate. The expiration date of the currently proposed/funded period,
plus unfunded periods (this may include possible option years). The expiration date of the currently
proposed/funded period, plus unfunded periods (this may include possible option years). Enter the date
in mm/dd/yyyy format or select it using the date selector by clicking on the calendar icon .
Institutional Fields Conditionally Required section
Award ID A unique institutionally assigned number of a previously funded application. A unique ID automatically
assigned by the system (based on institution specifications) to identify an award. An award is defined
as: To grant or declare as merited or due. If, after consideration, an outside agency/sponsor decides a
proposal has merit and worth, an agreement is drawn between the funding agency and Institution for
services. This agreement is called an award. An award is a legal, binding document for services in lieu of
funds to perform the original outline of the proposal submitted.
Original Proposal ID The number assigned by KRA Proposal Development module for the previously submitted proposal
record currently being revised. A unique institutionally assigned proposal number of a previously
submitted proposal. This is applicable when submitting a revised (changed/corrected) application.
Sponsor & Program Information Tab
Some of the information collected in the Sponsor & Program Information tab is used by partner schools in sponsored
programs reporting, and further, some of it maps to the Grants.gov submission portion of this module and is critical to
the successful electronic submission of the proposal.
The Sponsor & Program Information tab collects data that is used throughout the entire life of the project, from proposal
development and submission to award close-out. Some of the data elements are used in financial systems and can be
used for both hard copy and online proposal submissions.
Figure 59 Sponsor & Program Information Tab
Table 19 Sponsor & Program Information Tab Definition
Field Description
Sponsor Deadline Date The date in which the proposal is due to the sponsoring agency. Additional deadlines may be set by the
Field Description
office authorized to submit proposals on behalf of the institution (for example, sponsored programs).
Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on the calendar
icon .
Sponsor Deadline Type
Indicates the type of proposal deadline. Click the down arrow to display the list and click on an
item in the list to highlight and select it to populate the box with your selection.
Sponsor Name Required. The name of the sponsoring agency.
Prime Sponsor ID The sponsor that provides the original source of project funding. The internal reference ID of the
organization that funds the sponsored project, and is the original source of funds. Type the value if
known in the box, otherwise, search for and select it and populate the box automatically by using either
the lookup or direct inquiry functions.
NSF Science Code A number used to indicate the type of research activity as defined by the National Science Foundation.
NSF codes are not specific for NSF proposals and/or awards. A numeric code that is used by the
institution to indicate a field of research activity, as defined by the National Science Foundation. For
example, the NSF science code for Chemical Engineering is 012. These codes are important when an
institution compiles data for the NSF Annual Survey, and for other annual reporting exercises. The
NSF is a federal agency that sponsors fundamental research in science and engineering and also
supports science education. Click the down arrow to display the list and click on an item in the
list to highlight and select it to populate the box with your selection.
Sponsor Div Code A code that is unique to each NSF division and required for NSF proposals. Currently this code is
specific to the NSF only.
Opportunity Title The Opportunity Title is a sponsor assigned brief descriptive heading of the program solicitation or
funding opportunity. Not all programs have Opportunity Titles. (AKA Program Title or Program
Announcement) The title of a publicly available document, announcing a federal agency's intentions to
award discretionary grants or cooperative agreements, usually as a result of competition for funds.
AKA Funding opportunity announcements, notices of funding availability, or solicitations.
Notice of Opportunity Indicates if the proposal was in response to a solicitation, the type of solicitation or if it is unsolicited.
The mechanism used to communicate information about the funding opportunity for this project.
Examples include federal solicitations (e.g. RFP, RFA, PA), nonfederal solicitations, unsolicited
proposal, verbal request, etc. Click the down arrow to display the list and click on an item in the
list to highlight and select it to populate the box with your selection.
CDFA Number A unique identifier for the sponsor and the funding opportunity announcement. AKA "Catalogue of
Federal Domestic Assistance Number"
Opportunity ID The unique identifier associated with each sponsor's grant funding opportunity or solicitation
announcement. Equivalent to Funding Opportunity Announcement (FOA). Also sometimes referred to
as "Funding Opportunity Announcement number" or "FOA number."
Sponsor Proposal ID The unique identifier assigned by the sponsor when the proposal was submitted. The sponsor assigned
identifier for a proposal.
Does this proposal
include subaward(s)?
The proposal will include a sub award with another institution. A subaward is a financial assistance
agreement, which transfers a substantive effort of the project, issued to a sub-recipient when the prime
award mechanism is a GRANT or COOPERATIVE AGREEMENT. Generally subject to prime agency
flow-through terms & Conditions and OMB circular regulations. This applies to awards underneath
contracts (subcontracts), but if a proposal for a contract includes a sub, you still need to check this box.
Click within the checkbox to select the item. A green check mark appears within the checkbox to
indicate the item is selected. Click within the checkbox again to clear the mark and deselect the item.
Sponsor Program Code A specific code that is unique to each NSF program only and required for NSF proposals.
Opportunity Title The Opportunity Title is a sponsor assigned brief descriptive heading of the program solicitation or
funding opportunity. Not all programs have Opportunity Titles. (AKA Program Title or Program
Announcement) The title of a publicly available document, announcing a federal agency's intentions to
award discretionary grants or cooperative agreements, usually as a result of competition for funds.
AKA Funding opportunity announcements, notices of funding availability, or solicitations.
Organization/Location Tab
The Organization/Location tab is where you will find the official Universitys authorization address for the proposal, as
well as most of the sponsor-requested organizational data. This information does not require edits for most proposals,
but allows for entry of additional performance sites, including subcontractor locations where the proposed sponsored
project will occur.
Figure 60 Organization/Location Tab
Table 20 Organization/Location Tab Definition
Field Description
Organization section
Applicant Organization This field is the Name of the official authorized applicant institution/unit. The applicant organization,
or grantee, is the organization or other entity that submits the proposal and receives the award assuming
legal and financial responsibility and accountability both for the awarded funds and for the performance
of the grant-supported activity. Type the value if known in the box, otherwise, search for and select it
and populate the box automatically by using either the lookup or direct inquiry functions.
Authorized
Representative Name
& Address
The administrative official who, on behalf of the proposing organization, is empowered to make
certifications and assurances and can commit the organization to the conduct of a project that the
sponsor is being asked to support as well as adhere to various sponsor policies and grant or contract
requirements. The address is the institution contact information for the administrative official.
Congressional District This field represents the "applicant" congressional district. The U.S. Congressional district number of
the applicant organizational contact and the performing organizational contact. Each Congressional
district is an area within a state from which a member of the U.S. House of Representatives is elected.
There are 435 U.S. Congressional districts, each with a unique code.
Performing
Organization
This field is the name of the institution(s) in which the main project effort will take place. The
organization where the majority of the proposed sponsored project will take place. Type the value if
known in the box, otherwise, search for and select it and populate the box automatically by using either
the lookup or direct inquiry functions.
Performance Site Locations section
Location Name Required. This field is synonymous with "project site" or "performing site." It is used to identify all
performance locations, as well as subcontractor locations. The name of performing sites and
subcontract locations where the proposed sponsored project will occur.
Address Use the lookup to select the desired address.
Actions After Location name and address are entered, click:
to command the system to record a new Location line item
Field Description
to delete current address selected and select a different one using the lookup
to remove an existing Location
Delivery Info Tab
The Delivery Info Tab is where the PI enters delivery instructions to the OSP.
Figure 61 Delivery Info Tab
Table 21 Delivery Info Tab Definition
Field Description
Mail By This field determines whether the Sponsored Programs Office or the department will be mailing the
proposal to the agency/sponsor. Click the down arrow to display the list and click on an item
in the list to highlight and select it to populate the box with your selection.
Mail Account ID The internal school account number that should be charged the mailing costs.
Mailing Name & Address The name and address to whom the proposal will be mailed.
Type The method by which the proposal will be delivered to the agency/sponsor. Click the down arrow
to display the list and click on an item in the list to highlight and select it to populate the box
with your selection.
Number of Copies The number of paper copies of the proposal that should be mailed to the agency/sponsor.
Mail Description Any information that will assist in the delivery of the proposal.
Keywords Tab
A keyword is a term that describes the discipline of a sponsored project (for example, sustainable agriculture or
children's literature).
Keywords are associated with a specific sponsored project proposal and they help to identify the type of research project
being conducted. Knowing the topic of a proposal may provide reports about an institutions research and sponsored
projects enterprise.
In proposal development, the Keywords lookup goes against the Keywords Table. These values can be institution-
specific. Selecting the "Add" button opens the Select Keyword Code table window.
Figure 62 Keywords Tab
Table 22 Keywords Tab Definition
Field Description
Description Select from the lookup a term that describes the discipline of a sponsored project. The actual keyword(s) specific
to the proposal that can be used in database lookups and reports. Click within the checkbox to select the item.
A green check mark appears within the checkbox to indicate the item is selected. Click within the checkbox again
to clear the mark and deselect the item.
Actions
The system will add a checkmark in each row that has a check box displayed.
The system will delete any row that has a checkbox marked.
Keywords Tab Process
1. Click the lookup icon in the Add row, Description column to the right of where is says (select).
The Keyword Lookup screen appears:
2. Enter criteria in the Code and/or Description fields as desired (or leave blank to retrieve all) and click search.
The results are displayed below the search criteria area in a table format:
3. Click to place a check mark in the check box of each Keyword row for which you want to add in the Select? column.
4. Click the return selected button under the criteria area.
You are returned to the Proposal page where the Keywords Tab displays your selections in numbered line rows:
When a proposal development record is submitted to the sponsor, the values entered on the Keywords tab are carried
forward into the Institute Proposal record.
For more process information about standard actions available from buttons at the bottom of this page, see
Common E-Doc Operations in KRA Overview.
Budget Versions Page
The Budget Versions page appears in both the Proposal and Budget e-docs and acts as the navigational mechanism to get
you back and forth between those key functional areas of the Proposal Development and Budget module. This is the
page that you use to initially create a new budget as well as modify or copy existing budget versions.
After at least one budget version has been created, the system displays summary information about that budget; including
budget name and version number, direct cost, indirect cost, total, and status. Additional details can be viewed by
expanding hidden sections; which include residual funds, cost sharing, overhead rate type, unrecovered F&A, last
updated by, and comments. These details are pulled from various pages, tabs and sections in the budget module, but
are represented here so you can easily differentiate between budget versions without having to open the budget or
navigate to other pages and tabs.
After you are in the budget portion of the module, you can use the button on the Budget
Versions page to navigate back to the proposal pages.
Budget Versions Tab
Figure 63 Budget Versions Tab
Table 23 Budget Versions Tab Definition
Field or Button Description
Name Type up to 40 characters of text to designate each budget.
Budget Version
Number
Numeric, sequential, system-assigned number that further distinguishes the various budgets that a user may
create.
Direct Cost System-generated value brought forth from the direct cost value within the budget you create. Costs that
can be identified specifically with a particular sponsored project, an instructional activity, or any other
institutional activity, or that can be directly assigned to such activities relatively easily with a high degree
of accuracy.
F&A Total Indirect Cost. Facilities and Administration. Costs that are incurred for common or joint objectives
and, therefore, cannot be identified readily and specifically with a particular sponsored project, an
instructional activity, or any other institutional activity. F&A costs are synonymous with indirect costs and
overhead costs.
Total System-generated numeric value; taken from the total cost line of the created budget.
Budget Status
Select Complete or Incomplete from the drop-down list as appropriate to specify
the status of this version.
Final
Final version flag. Click to select the radio button option if this version is to be flagged as the final
version to be used with the proposal.
Click add to create a new budget version (basically saves the name and creates the open and copy
buttons so you can either continue to create or open the budget version.
Click open to open the budget creation module, and either create a new budget version or open a
previously-created budget version to view and/or modify. This causes the Summary Tab to appear, which
displays both the Overview and Periods & Totals tabs.
Click copy to open a dialog box and select to copy only one period of the previously-created budget or all
budget periods for this particular budget version. The copy will become the basis for a subsequent budget
version (the next available sequential budget version).
Individual Budget Version Subsection (when shown)
Residual Funds Remaining funds from a prior award; pulled from the Residual Funds field on the Budget Overview tab,
Summary section.
Cost Sharing The project costs which are not being funded by the sponsor; populated from the Totals: Cost Sharing field
in the Budget Periods & Totals page on the Summary tab.
Unrecovered F&A F&A costs which are not requested or provided by the sponsor. The F&A costs that will be incurred as a
result of the project, but will not be paid for by the sponsor.
Comments Type any internal notations you want to include (comments are not printed on forms or transmitted to the
sponsor in an S2S submission).
OH Rate Type The type of overhead rate applicable to the project.
Last Updated Timestamp of last update.
Last Updated By User ID of person who saved a modification most recently.
For more information about Budget Versions, see the Budget Document topic.
Key Personnel Page
The Key Personnel page is where you identify the faculty member or senior researcher who is the Principal Investigator
(PI) of the proposal, any additional Co-Investigators (Co-I), and project Key Persons (other Key Personnel).
The role in which each Key Person will be assigned for the proposed sponsored project. A named contributor (other than
the PI) who is integral to the proposed sponsored project, or who makes a significant contribution to the scientific
development or execution of the project, including Consultants (if applicable) and mentors on Career awards. This
includes Key Personnel and Other Significant Contributors as defined by NIH and Grants.gov. All individuals who
contribute in a substantive, measurable way to the scientific development or execution of the project or protocol, whether
or not salaries are requested (NIH definition).
Add Key Personnel
The Add Key Personnel search/selection area at the top of the page allows you to search for and select employees and
non-employees, specify proposal roles for each and add them as personnel that will be involved in the project work.
Figure 64 Add Key Personnel Selection Box
Table 24 Add Key Personnel Selection Box Definition
Field Description
Person box (marked as required because in order to add personnel, you must make at least one selection from either an employee or
non-employee search).
Employee Search Allows you to lookup from the Person table the individuals who are actively employed with
the applicant institution. Information is stored in a Person Table that is linked to an HR
database.
Non-employee Search Allows you to lookup from the Rolodex table to identify individuals who are
associated/affiliated with the applicant institution, but who are not employed with it.
Individuals are maintained in Rolodex ID entries.
Proposal Role box
Proposal Role
Click the down arrow to display the list, and then click on an
item to select it. Select either PI, Co-I or Key P.
Action buttons area
Click to remove selection from Add Key Personnel section.
Click to record the selected name and proposal role.
Person Name Tab
This tab displays the details associated with the person selected, and provides information from either the HR feed for
employees or Rolodex database for non-employees, allowing for further modification to fields that are either editable or
selectable.
Figure 65 "Person Name" Tab
Table 25 "Person's Name" Tab Field Definition
Field Description
Tab Label Area
Check box: Used for deletion. Click to select this
person and then click the button at the bottom of the
page to delete the person.
Name display: The persons first and last names appear as text within the
tab.
Role display: The persons research role for the proposal is displayed in
lighter gray text in the middle of the tab.
Hide/Show button: Used to open/close details from display within the
tabbed section of the page. Click to cause subsections
appear or disappear from view.
Field Description
Person Name section
Person Details subsection Click showto display identifying and contact information about the individual stored in the
system. Fields allow for modification.
Degrees subsection Click showto display detailed information about the degree(s) held by the person. Actions
include ability to add or delete degree lines.
Person Details Section
Figure 66 Person Details Section
Table 26 Person Details Section Field Definition
Field Description
Proposal Person Role Id This field identifies one of the following title/roles for each key person working on the project:
Principal Investigator, Co-Investigator, or Key Person. Display-only. Identifies the role in which
this key person is assigned for the proposed project.
Full Name First and last name of the user as recorded in the system database table.
Email Address The e-mail address of the person.
Primary Title The persons job title.
Home Unit The main unit in the Human Resources (HR) system associated with an individual's position or
institutional appointment.
eRA Commons User Name The unique username (from 6 to 20 characters) associated with a personal user account needed to
log in to the National Institute of Health electronic Research Administration system for biomedical
research proposal submissions to grantor sponsor agencies. The unique identifier (User ID) given
to each individual registered with the NIH eRA Commons.
Page Number The number of a paging device.
Office Location The location of the work office.
Address Line 1 This is the physical location information for each performing site. The information is maintained in
the Rolodex.
Address Line 3 Additional line for address information
County The county in which the person works.
Postal Code The zip code for the work address.
Percentage Effort The time/effort that the Investigators, and/or other personnel, are committing to the sponsored
project. This must be the proportion of time in relation to all institutional commitments and
Field Description
obligations. The total effort cannot exceed 100% for all sponsored projects and work-related duties.
User Name The KRA user ID.
Office Phone The primary office telephone number with area code first.
Directory Title The job title as recorded in the employee directory maintained by HR dept.
School The school within the institution this person works.
Fax Number The persons fax number with area code first.
Mobile Phone Number The persons cellular telephone number with area code first.
Secondary Office Location If there is a location where the person sometimes works, but not most of the time, it is displayed
here.
Address Line 2 The section line of the official work address, physical or mailing.
City The city in which the person works
State
The state where the institution is located. Click the down arrow to display the list and click
on an item in the list to highlight and select it to populate the box with your selection.
Country Code
The country where the institution is located. Click the down arrow to display the list and
click on an item in the list to highlight and select it to populate the box with your selection.
Faculty
Checked indicates the person is a faculty member. Click within the checkbox to select the
item. A green check mark appears within the checkbox to indicate the item is selected. Click
within the checkbox again to clear the mark and deselect the item.
Degrees Section
The Degrees section allows you to add degree information for each person contributing to the proposed research project,
including the Type, Description, Year and School.
Figure 67 Degrees Section
Table 27 Degrees Section
Field Description
Add The line where you make entries and selections to specify and add the line item.
Degree Type
Required. Select from the list each degree held by this contributor. Click the down arrow to display
the list and click on an item in the list to highlight and select it to populate the box with your selection.
Degree Description Required. Type to enter up to 80 characters of text to explain the type of degree.
Graduation Year Required. Enter a year in yyyy format.
School Enter the official name of the degree-granting institution.
Actions
a line item as a numbered row in the table.
remove an existing line item from the table.
Unit Details Section
This section allows you to select a Unit Name from a lookup and enter a Unit Number and then add this information as a
line item to the section table to specify the unit associated with the person who will be contributing to the proposed
project.
Figure 68 Unit Details Section
Table 28 Unit Details Section Definition
Field Description
Add The line where you make entries and selections to specify and add the line item.
Unit Name The familiar, official name of the unit.
Unit Number A numeric value associated with the unit name to uniquely identify it.
Actions
a line item as a numbered row in the table.
remove an existing line item from the table.
Certify Section
The Certify section of the Key Personnel page person tab identifies the main institutional and sponsor-specific
verifications and disclosure statements required prior to conducting institutional research. For example, lobbying
activity, accuracy of information provided, conflict of interest disclosure, debarments, & procurement integrity act
certification. The default values are to be set as a system parameters or code tables at implementation by your
institution.
Figure 69 Three Certify Example Questions with Yes, No and/or N/A Answer Options
When you are the Aggregator, a button appears in the Certify section that allows you to remove certification questions
for a key person.
Combined Credit Split Tab
The Combined Credit Split tab provides fields for entry of percentages for Recognition, Responsibility, Space, and
Financial for either the person (Investigator) or unit that must add up to one hundred with a recalculate button for totals.
Figure 70 Combined Credit Split Tab
Table 29 Combined Credit Split Tab Definition
Field Description
Recognition Enter a percentage. Cannot exceed 1.0 or 100%
Responsibility Enter a percentage. Cannot exceed 1.0 or 100%
Space Enter a percentage. Cannot exceed 1.0 or 100%
Financial Enter a percentage. Cannot exceed 1.0 or 100%
Totals Automatically calculated by the system. When null, not defined, or deleted, system resets to 0.00. Must
add up to 100% for Unit and Investigator.
Sums the totals based on modifications made in the four entry fields.
Key Personnel Page Actions
To delete a person from the Key Personnel page, select the person(s) and click the delete
selected button.
To view a version of the Key Personnel page that is formatted for the National Institute of Health,
click the View HIH Version link..
Special Review Page
A special review refers to a grant proposal that requires additional review by an institutional committee or official (e.g.
proposals that include the use of human participants in research). The Special Review page is where you input relevant
research compliance-related information and other special permissions that may be relevant to the specific project. You
have the ability to select which special review items apply, the approval status for each review, and additional data
related to each special review. The special review types are determined by each implementing institution based on local
needs.
Types of users of the Special Review page: For proposal development and protocol submission the user
will be a PI, PI assistant, or departmental administrator. However, during award or protocol management, the
user may be a central office staff member.
Special Review Tab
The Special Review page has a single tabbed section also labeled Special Review that provides the standard add line
item functionality described in the Common E-Doc Operations section of KRA Overview.
Figure 71 Special Review Tab
Table 30 Special Review Tab Definition
Column Field Description
Add The line where you make your entries and selections and click the add button, which adds them as numbered
line items below.
Type Required. The type indicates which special review, if any, is relevant to the document (proposal/award/irb).
Type selections include use of animal usage, biohazard materials, foundation relations, human participants,
international relations, radioactive isotopes, recombinant DNA, space changes, TLO PR-Previously
Reviewed, TLO Review no conflict (A), TLO Review potential conflict (B2), TLO Reviewed no
conflict (B1).Click the down arrow to display the list and click on an item in the list to highlight and
Column Field Description
Approval Status
Required. Select from the list to indicate if the special review relevant to the
document (proposal/award/irb) is pending approval, or already approved.
Protocol ID The protocol # is the number assigned to the protocol submitted by the PI to the institution's relevant
committee (e.g. IACUC, IRB, etc.). A unique number assigned by the institution and/or compliance
committee to a specific research Protocol. Type the value if known in the box, otherwise, search for and
select it and populate the box automatically by using either the lookup or direct inquiry functions.
Application Date The application date is the date the PI submitted a protocol/request for permission to the relevant
institutional committee/person for special Review. Enter the date in mm/dd/yyyy format or select it using
the date selector by clicking on the calendar icon .
Approval Date The approval date is the date the protocol/request for permission was approved by the relevant institutional
committee/person. Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on
the calendar icon .
Expiration Date Enter the date in mm/dd/yyyy format or select it from the calendar selector to specify the date this special
review will expire. Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on
the calendar icon .
Exemption # One of six categories of exempt research specified by the Common Rule (45 CFR 46.101(b). If the
proposed project is exempt, as defined by the different institutional committees, an exemption number is
generally issued, and is entered into this field. Scroll the spin box to view the list items from which to
select.
Comments Enter comments relevant to special review.
Actions After line items have been added, they may be removed by clicking the delete button.
For more process information about standard actions available from buttons at the bottom of this page, and for
instruction about using the add line feature within this page, see Common E-Doc Operations in KRA Overview.
Custom Data Page
The Custom Data page is used to display the Custom Attributes defined by each institution to collect data not captured
by baseline KRA. Attributes are displayed in tabs and sections within tabs as specified when the custom attributes are
created. The term custom data refers to a set of additional data elements needed by your institution that are not delivered
with the KRA system out of the box.
In the event your institution requires additional attributes for reporting purposes, they can be added as custom text fields
or have associated reference tables to supply valid values. Your technical staff may configure the data dictionary to
make the field required or optional, make them available as search criteria and/or appear in search results of lookups, and
include security and encryption as necessary.
Tabbed Page Section Examples
Figure 72 Custom Data Page > Budget Tab Example
Figure 73 Custom Data Page > Personnel Items for Review Tab Example
Figure 74 Custom Data Page > Project Details Tab Example
Required Fields
Custom attributes can be made required or optional.
Figure 75 Custom Data Page Fields May Be Required for Route/Sumbit, but Not Required for Save/Navigate
Depending on your institutions implementation of custom data, some fields may be required to
pass validation, but will never be marked as required with an asterisk.
Custom Data Page Process
For more information about how to configure and use Custom Data, see KRA Technical Documentation
available online at https://test.kuali.org/confluence/display/KRADOC/Home.
Questions Page
The Questions page is used to display specific questions defined by your institution to collect data not captured by
baseline KRA. It is a shared feature that appears in all KRA modules (for example, Proposal, Award and IRB).
Questions and data entry fields are displayed in tabs as defined by question groups. Groups of questions are collected
into questionnaires which can be associated with one or more KRA modules. In the Proposal module, the Questions
page is also used to collect answers to specific grants.gov questions. The administration of questions, groups and
questionnaires is accomplished through a separate set of maintenance documents.
Figure 76 Separate tabbed sections house questions grouped by common subject matter or functional area.
Tabbed Page Section Examples
Figure 77 Questions Page > General Questions Tab Example
Figure 78 Questions Page > Organization Verification Questions Tab Example
Figure 79 Questions Page > Financial Questions Tab Example
Table 31 Questions Page > Tabbed Section Field Examples and Definition
Field Description
Question
The question itself is displayed here, based
on what is maintained in a separate maintenance document. Questions may display
conditional logic information details under them in light gray text
Answer Required. Click to select the radio button option for yes, no, or n/a. In KRA Release v.1.0
the Questions tab will be limited to Yes/No functionality (based on Coeus v.4.2). In future
releases additional question types and structure will be supported.
Date Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on the
calendar icon to specify the review date.
Explanation Type to enter up to 400 characters of text to explain the answer to the question, and use the
expand text area icon as needed.
Actions Click the details button to view additional details related to each numbered question line.
Questions Page Process
Complete the Answer column for each question by selecting from the available options.
Optionally, complete the Date and Explanation columns for each question as desired.
Click the save button at the bottom of the page.
Permissions Page
The Aggregator navigates to the Permissions page when they need to add/delete users or modify permissions of current
users of the proposal. Other users (Budget Creator, Narrative Writer and Viewer) may navigate to this page in a view-
only mode to see the different permissions associated with this proposal.
The Permissions page is critical to the Proposal and Budget Development module because it allows the Initiator
(Aggregator) to select additional users that will have permissions for the following roles: Aggregator, Budget Creator,
Narrative Writer and Viewer. The Aggregator can grant, edit, clear or delete the role(s) granted to an individual.
Figure 80 Permissions Page Tabs
Assigned Roles Tab
Figure 81 Assigned Roles Tab
Table 32 Assigned Roles Tab
Field Description
Click to view rights associated with each role
Aggregator Displays full names (in Last, First I format) of users who have had this role assigned to them and who have also
been added on the Users tab. The Aggregator is an assigned role in KRA that allows the user to make changes
to any part of the proposal.
Budget
Creator
Displays full names (in Last, First I format) of users who have had this role assigned to them and who have also
been added on the Users tab. Edit proposal details and budget; view narratives and attachments.
Narrative
Writer
Displays full names (in Last, First I format) of users who have had this role assigned to them and who
have also been added on the Users tab. Edit proposal details, narratives and attachments; view budget.
Viewer Displays full names (in Last, First I format) of users who have had this role assigned to them and who have also
been added on the Users tab. View any part of this proposal.
Assigned Roles Tab Actions
To view rights for assigned roles:
1. Click the view rights button located to the right of the Assigned Roles section heading.
A pop-up window appears that displays the rights associated with each role:
2. Click the close button at center, bottom or the browser windows [X] button at top, right to close
the pop-up window.
Users Tab
Figure 82 Users Tab
Table 33 Users Tab Definition
Field Description
Field Description
Add Column displays sequential numbers for each line item. Row provides a User Name lookup, a Role selection list,
and an add button. Use this first row of the table to enter/select user/role combinations and add them as line items
that appear in the numbered rows below.
User Name Required. The User Id in the system.
Full Name Last name, First name, Middle initial order.
Unit # Numeric value associated with the unique unit
Unit Name The textual moniker of the unit as it is familiarly known
Role Select from the drop-down list in the Add row to specify the Proposal Development Research Project Role. Click
the down arrow to display the list and click on an item in the list to highlight and select it to populate the box
with your selection.
Actions
adds the selected individual and assigned role to the list of users
modify and/or add a role to the user selected
remove the selected user and their assigned roles
Users Tab Actions
To edit a role:
1. Click the edit role button located to the right of the numbered line item row in the Users table
for the user whose role you want to edit.
A Roles pop-up window appears for the user whose roles you selected to edit:
2. Click within the box to the right of the corresponding role name you want to assign to this user.
A green check mark appears within the check box to indicate your selection:
3. Click the save button on the pop-up window.
The pop-up window closes and your saved selection change is reflected in the Role column
display on the Users tab table.
Abstracts and Attachments Page
The Abstract & Attachments page allows you to upload any documents or add any notes/comments for this proposal
within this page. Attachments can be of various types; Proposal, Personnel or Internal documentation related to the
proposal but not necessary to send to the sponsor. You can also provide notes for subsequent reviewers on the Notes and
Attachments tab.
While the Proposal and Personnel attachments can be viewed by the sponsor agency, the notes are internal to your
institution. Institutional Attachments are also internal documents which include information related to the proposal, but
are for the internal record keeping only (for example, a cost share funding agreement from ones department or college).
In addition, you can enter any text-formatted abstract types in the Abstracts tab. For any S2S submission that requires
certain Abstract components to be in text format (such as certain NSF application information), this tab should be used.
For either a non-S2S application or for a S2S application that is able to accommodate either text fields or attachments,
you have the option to use the Abstracts tab or to upload the equivalent information as Other attachment documents
via the Notes and Attachments tab.
Figure 83 Abstracts & Attachments Page Tabs
Proposal Attachments Tab
Figure 84 Proposal Attachments Tab - Add Proposal Attachments Section
Figure 85 Proposal Attachments Tab - Shown Added Attachment Section
Table 34 Proposal Attachments Tab Definition
Field Description
Attachment Type Required. The type of proposal document to be attached and sent (transmitted) to the sponsor. Click the
down arrow to display the list and click on an item in the list to highlight and select it to populate the
box with your selection.
Status
Required. Select Incomplete or Complete from the list to specify the status of the
document as assigned by the user.
Uploaded By Display-only. The name of the individual who added the attachment.
Posted Timestamp The exact date/time the attachment was uploaded to the system.
Comments Type in this free-form text box to add notations relating to a specific attachment. Use the add note feature
as necessary to expand the text area .
File Name The name of the file that has been attached appears within the box after it has been browsed for and
uploaded using the [Browse] button.
Click the download or
replace links that appear to the right of the name as needed.
Contact Name The name of the individual to be contacted if subsequent viewers/approvers have questions regarding the
document.
Email Address The e-mail address of the individual named in the Contact Name field.
Phone Number The phone number of the individual named in the Contact Name field.
Description Type a brief summary of the attachment that is being uploaded. Use the add note feature as necessary to
expand the text area .
Click add to add the attachment, or delete to remove it as desired.
Click to see or modify the rights users have for a particular proposal or internal attachment. The window
displays those individuals who have already been assigned [any] role within the Permissions page. Special
rights can be given or removed for documents within the proposal and internal attachments panels through
this function. Rights include read, modify, and none (which removes the ability to view/edit a particular
document, regardless of the role assigned on the Permissions page).
Personnel Attachments Tab
Figure 86 Personnel Attachments Tab
Table 35 Personnel Attachments Tab
Column/Field/Button Description
Posted Timestamp The exact date/time that the attachment was uploaded to the system.
Uploaded By The name of the individual who added the document.
Person Automatically populated with the names of the individuals listed on the Key Personnel page.
Click the down arrow to display the list and click on an item in the list to highlight and
Attachment Type Select from the list the type of personnel document to be attached and sent (transmitted) to the
sponsor.
Description Enter a brief summary of the attachment you are uploading.
File Name The file name and path appears within the box after you browse for and select the file to upload.
Click add to add your entry so that it appears as a numbered line item. From the line item, use
the view or delete action buttons as appropriate.
To view/save an attachment:
1. Click view in the Actions column to the right of the numbered attachment line item.
A dialog box appears, prompting you to either open with the default application or save the file to
your local disk:
2. Select either open or save as desired and click OK.
Depending on your browser type, browser settings, and default download manager application,
this screen or behavior may differ. In general, save will place the file in a default download
location, such as My Documents or your operating systems Desktop; while opening will use
whatever application program is set in your registry to open the file type, like Word for a .doc file.
Internal Attachments Tab
Figure 87 Internal Attachments Tab
Table 36 Internal Attachments Tab Definition
Column Description
Uploaded By The name of the individual who added the document.
Attachment Type
Select from the list.
Description Name the attachment you are uploading beyond merely the type.
File Name The file name and path of the file you are uploading. Click [browse] to locate and select the file.
Click add to add your entry so that it appears as a numbered line item. From the line item, use the
view or delete action buttons as appropriate.
Abstracts Tab
The abstract, or project summary, is a concise, clear, and brief description of the project. It should outline the problem,
the objectives, expected outcomes, including significance of the project to the field being studied. The abstract is usually
written in less technical language than the proposal narrative.
Figure 88 Abstracts Tab
Figure 89 Abstract Types List
Figure 90 Abstract Line Item
Table 37 Abstracts Tab Definition
Field Description
Author The name of the individual who entered the Abstract Details.
The Author is the person who did the data-entry, not necessarily the person who completed it,
or authored it.
Abstract Type The abstract, or project summary, is a concise, clear, and brief description of the project. It should outline
the problem, the objectives, expected outcomes, including significance of the project to the field being
studied. The abstract is usually written in less technical language than the proposal narrative.
Abstract Details Describe and justify the individual abstract type.
Actions Add or delete the attachment line as desired.
Notes and Attachments Tab
Figure 91 Notes and Attachments Tab
Table 38 Notes and Attachments Tab Definition
Field Description
Author The name of the individual who entered the Abstract Details.
The Author is the person who did the data-entry, not necessarily the person who completed it,
or authored it.
Note Topic This field is a free-text field that allows you to type in a brief description of the note topic
Note Text This field is a free-form text field in which the user are able to enter a notation.
Attached File Click browse to locate, select and upload the file as an attachment or click [cancel].
Actions Click add to add the file you selected as a line item, or delete after it has been added to remove it.
For more information about the Notes and Attachments Tab, see Common E-Doc Tabs in KRA Overview > E-
Doc Fundamentals.
Grants.gov Page
The Grants.gov page facilitates submission of certain federal proposals created in Proposal Development directly to the
Grants.gov on-line system. This system-to-system (S2S) application transmittal is only available for certain federal
funding opportunities. The eligibility requirements are specified by each sponsoring agency.
The Grants.gov page allows you to:
Search for and select the applicable funding opportunity
Read the Opportunity schema to know which data elements and forms are required
Create XML images of Grants.gov forms
Review the application for errors by performing a data validation check against Grants.gov and sponsor-specific
requirements
Submit the application electronically to Grants.gov (S2S)
Retrieve the agency tracking ID and submittal status of the application after institutional submission has been
completed
Grants.gov Tab
Figure 92 Grants.gov Tab
Table 39 Grants.gov Tab Definition
Section Description
Opportunity Search Search eligible Grants.gov application opportunities either by entering a CFDA Number or specific
Opportunity ID & selecting grants.gov verification button.
Opportunity Additional proposal details associated with the Opportunity ID selected
Submission Details Displays the current grants.gov submission status of the proposal, derived from the Grants.gov website
upon clicking refresh.
Forms Displays all mandatory & optional forms for the selected opportunity. The following form types will be
identified/displayed by line:
RR SF 424 V1-0
RR Budget V1-0
Section Description
RR Other Projects V1-0
RR Performance Site V1-0
RR Key Person V1-0
PHS398 Checklist V1-0
PHS398 Cover Page Supplement V1-0
PHS398 Research Plan V1-0
PHS398 Cover Letter V1-0
RR SubAward Budget V1.1
SF424 R&R Forms
Agency-Specific Forms
Opportunity Search Section
Figure 93 Opportunity Search Section
Table 40 Opportunity Search Section Definition
Field Description
Opportunity Search www.grants.gov link Section heading bar contains direct link to www.grants.gov and section-level
online help.
Grants.gov Lookup Search eligible Grants.gov application opportunities either by entering a CFDA
Number or specific Opportunity ID & selecting grants.gov verification button.
Post-Selection: The Sponsor & Program Information tab on the Proposal page becomes populated
automatically after selecting an opportunity.
Opportunity Section
Figure 94 Opportunity Section
Table 41 Opportunity Section Definition
Field Description
Opportunity ID The unique identifier associated with each sponsor's funding opportunity. Equivalent to Funding
Opportunity Announcement (FOA).
Opportunity Title The Opportunity Title is a sponsor assigned brief descriptive heading of the program solicitation or funding
opportunity. Not all programs have Opportunity Titles. (a.k.a. Program Title or Program Announcement)
Submission Type The type of grant application package/proposal submitted. For example, types of submissions include: (1)
Pre-application (2) Application (3) Changed/Corrected Application. Click the down arrow to display
the list and click on an item in the list to highlight and select it to populate the box with your selection.
Revision Select an option from the available radio buttons, or select Other and enter the revision reason in the box
provided under the Other option.
CFDA Number A unique identifier for the sponsor and the funding opportunity announcement (FOA). The first 2 digits of
the number identify the Federal agency. The last 3 digits of the number identify the specific Federal
program. A Funding Opportunity Announcement (FOA) is a notice or solicitation of a grant funding
opportunity.
Competition ID This identifies the version of federal forms required by the sponsoring agency and Grants.gov for the
specific grant application package.
Opening Date The date a user may begin submitting grant application packages, under a specific funding
opportunity/program.
Closing Date The last day and time (deadline date) in which a user may submit an application under a specific
opportunity/program. The date the opportunity expires.
Schema URL A way to define the structure, content and, to some extent, the semantics of XML documents. The URL
address that links to the program's federally funded schema provided by the sponsor and available for
download from the Grants.gov link. Defines the required and optional forms for each funding opportunity.
Form schemas are included by reference in the opportunity schema.
Instruction Page The URL address that links to the program's complete grant application package instructions. Provided by
the sponsor and available for download from the Grants.gov link.
Submission Details Section
Figure 95 Submission Details Section
Table 42 Submission Details Section
Section Description
Submission Details Click the refresh button to display the current grants.gov submission status of the proposal,
derived from the Grants.gov website.
After the opportunity has been selected, a remove opportunity button appears in the Opportunity Search
section. Additionally, a Submission History section appears.
Forms Section
Figure 96 Forms Section
Table 43 Forms Section Definition
Column Description
Column Description
Form Name The official title of the form document
Mandatory Yes no or n/a for not applicable is displayed. Read-only display.
Include Yes no or n/a for not applicable is displayed. Read-only display or checkbox.
Desc Description of the forms availability.
Select to Print
Select the checkbox to include all or clear to include none. Click within the checkbox to select the
item. A green check mark appears within the checkbox to indicate the item is selected. Click within the
checkbox again to clear the mark and deselect the item.
print selected forms Click to print the forms that are checked in the Select to Print column.
Proposal Actions Page
The Proposal Actions page of the Proposal document is comprised of the following tabbed sections:
Figure 97 Proposal Actions Page Tabs
Data Validation Tab
KRA validates data youve entered into a proposal document for completeness and accuracy and displays errors on the
Data Validation tab that you can not only view, but easily navigate to the relevant page, tab or section to fix them. Each
type of validation is displayed categorically by type, and further categorized by page where the errors have occurred. In
general, hard errors can prevent the Proposal document from being routed and/or submitted to Grants.gov (when
applicable), whereas soft warning errors alert you to possible problems, but do not prevent submission.
The two types of validation in KRA are:
Save/Navigation Errors: page or tab-specific hard or soft errors you encounter while navigating or saving.
Validation Errors: hard or soft errors you encounter only in validation mode (which can be turned off on this
tab).
The three types of system checks are:
Validation Errors: hard-coded errors that prevent routing
Warnings: soft errors that serve as alerts to possible data issues but will not prevent routing or submission
Grants.gov Errors: errors that prevent submission to grants.gov
The two methods by which validations are generated are:
Manual: You can activate the validation process upon command (on an as-needed basis) by clicking the turn
on/off validation button in the Data Validation section of the Data Validation tab prior to submission and while
navigating throughout the pages of the proposal.
Automatic: The validation process will also run automatically upon the action of final submission/routing.
Figure 98 Data Validation Tab
Table 44 Data Validation Tab Definition
Section/Button Description
Data Validation Houses on-screen instructions regarding validations and a button to activate/deactivate the audit mode.
The button label text changes from on to off and serves as a toggle.
Validation Errors Hard coded system errors that identify missing data required prior to proposal submission/routing.
Warnings Soft errors that serve as cautionary reminders to you, but do not prevent proposal submission/routing.
Grants.gov Errors Proposal validations that check data against the opportunity schema. The schema downloaded from
Grants.gov will contain the fields required to be populated. KRA will check that the data is present in the
KRA proposal record. Not having the data will cause a validation error.
Click to navigate to the applicable proposal development page where error occurred. Message(s) will re-
display in red text within each applicable page or tabbed section. Invalid fields will be outlined in red.
Figure 99 Validation Errors Section Example
Figure 100Warnings Section Example
Figure 101 Grants.gov Errors Section Example
Fix Process
1. Click turn on validation.
Error sections appear as hidden on the Data Validation tab.
2. Click show.
Each error is displayed as a line item with a corresponding fix button.
3. Click fix to the right of an error.
You are taken to the relevant page where error messages are displayed and fields are outlined
in red:

4. Fix the error and click save.
The error no longer appears on the Data Validation tab.
Print Forms Tab
The Print Forms tab on the Proposal Actions page allows you to print any agency or budget forms associated with the
proposal. You are able to select a specific form to print, or you can select to print all forms in the given category. In
addition, you can select either Sponsor Form Packages, which can include forms not associated directly with Grants.Gov
(older versions of NIH forms, or those forms not included directly with the Grants.Gov bundle), and Grants.Gov forms
(as populated from the Grants.Gov page.)
Figure 102 Print Forms Tab
Table 45 Print Forms Tab Definition
Element Description
Click the checkbox in the right column for each line item form you want to print. Click within the
checkbox to select the item. A green check mark appears within the checkbox to indicate the
item is selected. Click within the checkbox again to clear the mark and deselect the item.
Click the all link to select all of the checkboxes in this section to denote the printing of all forms.
Click the none link to clear all previously checked boxes
Clicking print selected generates the .pdf form(s) that you have selected.
Copy to New Document Tab
The Copy to New Document Tab allows you to copy an existing Proposal document into a new Proposal document for
the purposes of starting a new (and very similar) proposal or resubmitting a previously-submitted proposal. You can
elect to copy the proposal with or without the attachments and/or with or without all versions or merely the final version
of the budget. The copy function also provides you with a mechanism to change the Lead Unit by way of copying an
existing proposal and selecting an alternate lead unit for that new proposal document.
Figure 103 Copy to New Document Tab
Table 46 Copy to New Document Tab
Field Description
Proposal Display-only. Yes or no?
Lead Unit The designated unit responsible for the application and administration of the proposed sponsored project.
Budget?
Select the checkbox if you want to copy the budget(s) or clear if you do not. Click
the down arrow to display the list of valid values and click on an option to select it. Click within the
checkbox to select the item. A green check mark appears within the checkbox to indicate the item is
selected. Click within the checkbox again to clear the mark and deselect the item.
Attachments?
Select the checkbox if you want to copy the attachments. Click within the checkbox to select the
item. A green check mark appears within the checkbox to indicate the item is selected. Click within the
checkbox again to clear the mark and deselect the item.
Lead Unit The designated unit responsible for the application and administration of the proposed sponsored project.
Click the down arrow to display the list of valid values and click on an option to select a
different lead unit for the new proposal.
Click to copy the budget(s) and/or attachments into a new Proposal document.
Ad Hoc Recipients Tab
For more information about how to view and use the Ad Hoc Recipients tab, see Common E-Doc Tabs in KRA
Overview > E-Doc Fundamentals.
Route Log Tab
For more information about how to view and use the Route Log tab, see Common E-Doc Tabs in KRA
Overview > E-Doc Fundamentals. For even greater technical detail, see Route Log in Kuali Enterprise
Workflow.
Proposal Actions Page Action
One non-standard button, route, appears on the Proposal Actions page of the Proposal document. It is a workflow action
command button located near the other action buttons at the bottom, center of the page.
Table 47 Route Button Description
Button Description
Click to initiate the workflow process, based either on predefined workgroup routing or ad hoc routing specified on
the document, for review and approvals.
Proposal Document Routing
Figure 104 Proposal Development Document Workflow
Kuali Research Administration v.1.0 User Guide Budget Document 157
Budget Document
This topic explains how to create and maintain Budget documents. Budget documents are electronic documents that are
part of the KRA Proposal Development module and are attached to Proposal documents in the system. A Budget is an
estimate of expenditures proposed to be incurred in the performance of a proposed sponsored research project.
Overview
The Budget e-doc screen is comprised of a document header, nine pages, and a button that allows you to return to the
associated Proposal document. The Budget document includes pre-populated information such as key data elements and
default values that are brought forth from the associated Proposal document. There is a specific right/role for budget
creation, however, multiple users can be working in different functional areas simultaneously. Institutional rates like
F&A and fringe benefits are applied automatically. Multiple budget versions can be created. Functionality includes
calculation of the total cost of research and period cost limits. Budget detail maps to Grants.gov, and also flows through
to the KRA Awards module.
Access
The Budget document is primarily accessed via the Budget Versions page of Proposal e-docs (a page both e-docs share).
After opening a budget version from that page (or adding & opening one if one did not already exist), you are taken to
the Budget e-doc (with the shared Budget Versions page initially displayed by default).
Certain workgroup members with certain roles and rights may be able to access Budget e-docs directly from the
Action List screen. For more information, see Action List in Kuali Enterprise Workflow.
To open a Budget document:
1. Open a Proposal document.
2. Select the Budget Versions page.
158 Budget Document Kuali Research Administration v.1.0 User Guide
3. Click open in the Actions column of the Budget Versions tab to the right of the desired budget version line.
The document changes from Proposal to Budget with the Budget Versions page displayed:
You are able to return at any time to the Proposal document. For more information about proposal/budget
navigation, see Return To Proposal.
Document Header
The document header is slightly different for a Budget document than for other e-docs in KRA. It displays the following
six fields of identifying information about the budget version:
Field Description
Document ID This is a number that identifies the budget version that is currently accessed and displayed (not the budget name).
Initiator The user name of the person who first added this budget version.
Budget Name The textual name that uniquely represents this budget version (required entry by Initiator during add process).
Status The state this document is currently in as it relates to the completion of the document (not its routing or
submission).
Last Updated The time and date this document was last updated by any user.
Version A numeric identifier of an individual instance or copy of a budget. Since budget versions may share a common
name, this, along with the Document ID, differentiates one from another.
Pages Overview
Budget documents are made up of the following nine pages, each of which contains one or more tabbed sections:
Figure 105 Budget Document Pages Bar
Table 48 Brief Descriptions of Budget Document Pages
Page Description
Budget Versions View information about the different potential budgets that are works in progress in addition to the one
currently accessed. One of these candidates will eventually be selected to be the final version associated with
a Proposal document. This is the page that is displayed by default when the Budget document is first
accessed.
Summary View basic information about the Budget document including its status, relevant dates, costs, rates and period
totals.
Rates Select and add types of rates related to a Budget document, specify or adjust their values as necessary,
calculate totals and then synchronize them throughout.
Project Personnel Search for and select employees and non-employees that are to participate in the activities associated with the
proposed research work so that their salaries can be figured in with the costs associated with the project being
proposed.
Expenses View, add, modify and recalculate details of expenses associated with the proposed project by budget period.
Details include the ability to add object lines for things like equipment and travel, and then specify things like
the descriptions, quantities, and costs for each.
Totals View expenses, calculated expenses and total expenses entered in the Budget document.
Distribution &
Income
View cost sharing and unrecovered F&A distribution lists, add income amount lines by period, calculate
summary totals and synchronize.
Modular Budget Select modular budgets by period; view basic, direct cost and F&A information about each, modify that
information, and synchronize it.
Budget Actions Select and print forms that sort and summarize information entered into the Budget document; and enter text
that justifies the necessity of the document.
Return To Proposal Navigation
No matter where you are in a Budget document, you can always go back to the Proposal document by clicking the
<return to proposal button.
Figure 106 Return To Proposal Button
Table 49 Return To Proposal Button
Button Description
This navigation button appears under the horizontal page navigation tab bar to the left of the site
index, expand all & collapse all buttons on all Budget pages. It returns you to the Proposal
document this Budget document is linked to.
Budget Versions Page
The Budget Versions page of the Budget document has a single tabbed section that allows you to add a new version
(create a new Budget document); and view, open or copy existing budget versions. Subsections within the tab have
show/hide buttons that allow you to expand or collapse the display for each budget version. Within each shown version
subsection, you are able to view general information, change the versions status, and take further action.
Figure 107 Budget Versions Tab
Table 50 Budget Versions Tab Definition
Tab Label Text To the right of the tab heading text that reads Budget Versions, the start and end dates are displayed in
parentheses. For example, (7/23/07 7/23/09).
Name Type up to 40 characters of text to designate each budget.
Budget Version
Number
Numeric, sequential, system-assigned number that further distinguishes the various budgets that a user may
create.
Direct Cost Costs that can be identified specifically with a particular sponsored project, an instructional activity, or any
other institutional activity, or that can be directly assigned to such activities relatively easily with a high
degree of accuracy. System-generated value brought forth from the direct cost value within the budget
you create. Costs that can be identified specifically with a particular sponsored project, an instructional
activity, or any other institutional activity, or that can be directly assigned to such activities relatively easily
with a high degree of accuracy.
F&A Total Indirect Cost. Facilities and Administration. Costs that are incurred for common or joint objectives
and, therefore, cannot be identified readily and specifically with a particular sponsored project, an
instructional activity, or any other institutional activity. F&A costs are synonymous with indirect costs and
overhead costs.
Total System-generated numeric value; taken from the total cost line of the created budget.
Budget Status
Select Complete or Incomplete from the drop-down list as appropriate to specify
the status of this version.
Final
Final version flag. Click to select the radio button option if this version is to be flagged as the final
version to be used with the proposal.
Click add to create a new budget version (basically saves the name and creates the open and copy
buttons so you can either continue to create or open the budget version.
Click open to open the budget creation module, and either create a new budget version or open a
previously-created budget version to view and/or modify. This causes the Summary Tab to appear, which
displays both the Overview and Periods & Totals tabs.
Click copy to open a dialog box and select to copy only one period of the previously-created budget or all
budget periods for this particular budget version. The copy will become the basis for a subsequent budget
version (the next available sequential budget version).
Individual Budget Version Subsection (when shown)
Residual Funds Remaining funds from a prior award; pulled from the Residual Funds field on the Budget Overview tab,
Summary section.
Cost Sharing The project costs which are not being funded by the sponsor; populated from the Totals: Cost Sharing field
in the Budget Periods & Totals page on the Summary tab.
Unrecovered F&A F&A costs which are not requested or provided by the sponsor. The F&A costs that will be incurred as a
result of the project, but will not be paid for by the sponsor.
Comments Type any internal notations you want to include (comments are not printed on forms or transmitted to the
sponsor in an S2S submission).
OH Rate Type The type of overhead rate applicable to the project.
Last Updated Timestamp of last update.
Last Updated By User ID of person who saved a modification most recently.
Summary Page
The Summary page of the Budget document displays from top to bottom the following two tabbed sections and unique
action buttons:
Figure 108 Summary Page Tabs and Buttons
Tabbed Sections: Budget Overview displays the project start/end dates, and allows you to change the status,
specify whether final or modular, enter comments, enter total cost limit and residual fund amounts, and select
rate types. Budget Periods & Totals allows you to add period lines and specify start/end dates for each period,
as well as enter dollar amounts for various associated costs, then calculate and display totals for all periods.
Action Buttons: Unique to the Summary page are action buttons at the bottom of the page that allow you to
command the system to either generate or calculate all periods. Standard e-doc buttons also appear.
Budget Overview Tab
The Budget Overview tab displays pertinent information about the selected budget version to you at a glance. This tab is
accessed by clicking the add or open buttons on the Budget Versions page of a Proposal document.
The Project Start Date and Project End Date fields on the Budget Overview tab are pre-populated from the Required
Fields for Saving Document tab on the Proposal page of the Proposal document.
From this tab, you are able to specify the Budget Status, whether this is the Final version of the budget, whether this is a
Modular Budget, enter a Total Cost Limit, enter any Residual Funds, select the Unrecovered F&A Rate Type and the
F&A Rate Type for this budget, if applicable. Additionally, you are able to enter any pertinent internal notes in the
Comments field.
Figure 109 Budget Overview Tab
Table 51 Budget Overview Tab Definition
Field Description
Project Start Date The date the project will begin is prepopulated and display-only. The start date of a budget period as
reflected in the fiscal period in which the rates apply. In the Proposal Module, this is the requested project
start date for the project in the proposal. These two fields may not be the same.
Project End Date The date the project will end is prepopulated and display-only. The expiration date of the currently
proposed/funded period, plus unfunded periods (this may include possible option years).
Budget Status
Select from the list the term that indicates the current condition of the budget. The status of the final
budget version for this Proposal Development Document. Click the down arrow to select either
Complete or Incomplete from the list.
Final?
Select the checkbox to set the Final Version Flag and indicate this budget version is the final one.
Comments The Comments for this budget.
Modular Budget?
Select to set the Modular Budget Flag, which is a system indication that this is a modular budget format
that is applicable to certain NIH proposals only.
Total Cost Limit Fixed Point. The maximum cost (including indirect costs) to be covered by the sponsor. Exceeding will
produce a warning message.
Residual Funds Fixed Point. Remaining funds, if any, from a previous award.
Unrecovered F&A
Rate Type
Select from the list the type of rate used for the F&A that is applicable to the project, but not recovered
from the sponsor if applicable. Ur Rate Class Code F&A costs
which are not requested or provided by the sponsor.
F&A Rate Type
This is the type of overhead rate that is applicable to the project. Click the down arrow to display the
list and click on an item in the list to highlight and select it to populate the box with your selection.
On/Off Campus
Select All On or All Off as necessary from the drop-down list to set for all calculations and avoid
having to change line-by-line.
Budget Periods & Totals Tab
Typically, the Start Date field on the Budget Periods tab is pre-populated from the Budget Overview panel. The End
Date field, of the first period, on the Budget Periods tab is automatically calculated to one year out. Subsequent periods
are automatically generated in one year increments, if the project is longer than one year. The final period will be less
than one year if the project is not in twelve month increments. The end date of the final period is auto-populated by the
end date on the Budget Overview tab.
You are able to adjust the budget periods as needed on this tab. The start date of period one cannot be set at an earlier
date than the Project Start Date, nor can the end date of the final period exceed the Project End Date. You have the
ability to generate as many periods and adjust the period lengths as long as they are within the Project Start and End
Dates.
The Total Requested Cost, Direct Cost, Indirect Cost, Unrecovered F&A and Cost Sharing fields for each Budget Period
are set to zero initially. You can either enter values into these fields or these values will pre-populate from the respective
fields on the Overview tab on the Expenses page if you begin a detailed budget by entering line items.
You must select to either do a detailed budget (by way of entering expenses on the Expenses page) or a summary budget
(by way of entering values directly into the Summary tab) but may not use a combination of these features. After
summary values are manually entered, no data can be entered into the Expenses tab. Likewise, after you have initiated a
detailed budget (by way of entering expenses on the Expenses tab), you can no longer enter values into the summary tab.
After you have entered all necessary expenses into Budget Period 1, you can load future periods by clicking the Generate
All Periods button. The system will automatically populate the Direct Costs, Cost Sharing, Indirect Costs, Unrecovered
F&A and Total Requested Cost into future budget periods. The system will apply the set inflationary rate to the
expenses you have entered for budget period 1, if you indicated it on the Expenses page.
All fields in the totals section will automatically populate and/or calculate. The Total Requested Cost, Direct Cost,
Indirect Cost, Unrecovered F&A, and Cost Sharing fields will be the sum of the budget periods above.
Figure 110 Budget Periods & Totals Tab
Table 52 Budget Periods & Totals Tab Definition
Budget Periods section
Start Date
The start date is pre-populated from the Project Start Date field on the Budget Overview panel.
The start date of a budget period as reflected in the fiscal period in which the rates apply. In the KRA
budget module, this is the date for which a rate becomes effective.
End Date
System auto-generates in annual increments from the budget period X Start Date
Total Requested Cost Pre-populated from the respective fields on the Overview tab on the Expenses page. If nothing is
entered on the Expenses tab, this value defaults to 0. You may also enter a value directly into this
field; however, any entered data will be overwritten if the use populates the expenses tab or enters in
direct or indirect costs directly in the budget periods & totals tab.
Direct Cost Pre-populated from the respective fields on the Overview tab on the Expenses page, if you are doing a
detailed budget; otherwise if completing a summary budget, enter the value as appropriate. Costs that
can be identified specifically with a particular sponsored project, an instructional activity, or any other
institutional activity, or that can be directly assigned to such activities relatively easily with a high
degree of accuracy.
Indirect Cost Enter a value when completing a summary budget, otherwise, this is prepopulated from the respective
fields on the Overview tab of the Expenses page.
Unrecovered F&A Enter a value when completing a summary budget, otherwise, this is prepopulated from the respective
fields on the Overview tab of the Expenses page. F&A costs which are not requested or provided by
the sponsor.
Cost Sharing Enter a value when completing a summary budget, otherwise, this is prepopulated from the respective
fields on the Overview tab of the Expenses page.
Actions
add the information youve entered/selected as a numbered line item below
remove the numbered line item row from the table list
Totals section
Totals line content is display-only and represents sums of all budget periods. Click recalculate after
making modifications to individual line cost fields to update the totals. System recalculates values
entered into the summary panel of the Budget periods & totals tab. (Useful after a change is made to
the budget, i.e. rates, etc.)
Summary Page Actions
Table 53 Action Buttons Unique to the Summary Page
Button Description
System calculates all periods between Proposal Start Date and End Date based on the budgetary
line items entered in the Expenses tab for Period 1, including any indirect or inflationary factors, if
applicable.
System calculates all periods, either from expenses entered into the Expenses tab or in summary on
the Budget Periods & Totals Tab. (Useful after a change is made to the budget, i.e. rates, etc.)
Rates Page
Table 54 Key Rate Terminology
Term Description
Rate Class A Rate class is composed of one or more rate types.
Rate Type A rate type is a subset of a rate class.
Activity Type Defines which rates can be applied to the proposal budget for the various rate types. Activity Type most often
impacts F&A rates, but can also impact Employee Benefit and Inflationary rates as well. Default
Implementation Values: Organized Research, Instruction, Fellowship, Public Service, Student Services,
Clinical Trial, Construction, and Other.
Object Code Also referred to as a Cost Element. This is a classification of expenditures according to the nature of expense
such as salaries, supplies and services, etc., which identifies the object of expenditure out of appropriation
funds.
Page Layout
The Rates page is made up of the following three primary areas from top to bottom:
Selection Area: Allows you to select from location and budget version options to update the data that is
displayed in the tabbed sections.
Tabbed Sections: Display rates associated with items in the various categories, which include Public
Service F&A, Fringe Benefits, Inflation, and Vacation.
Action Buttons: In addition to the standard e-doc buttons, you are also able to click unique buttons to
command either the reset or synchronization of all rates.
Select View
Figure 111 Select View Area
Table 55 Select View Area Definition
Field or
Button
Description
Location
Click the down arrow and then click either View All , On Campus or Off Campus to select it
from the list. View All is selected by default. This allows you to refine the line items appearing in the
tabbed sections on the page. The name of performing sites and subcontract locations where the proposed
sponsored project will occur.
Budget Period
Click the down arrow to display the list and select one budget (numbered and displayed as date ranges-for
example, 1: 06/05/2008 06/04/2009 ). View All is selected by default. This allows you to
refine the line items appearing in the tabbed sections on the page.
Click the update view button to reduce the data displayed in the tabs below the Select View area based on
your selections in the Location and Budget Period fields. The associated line items in each tab on the Rates
page are refined by your view selections as opposed to the default View All display.
Research F&A Tab
This tab identifies which indirect cost rates will be applied to each proposal budget version.
The applicable rates are pre-populated with the default institute rates which are pulled in from an institutional rate
table located within the Unit Hierarchy.
You may override the established/defaulted F&A rates (on a proposal and/or proposal version basis) by editing the
Applicable Rates column. You can enter a different rate for each fiscal year.
Clicking the sync rates button ensures rates are up-to-date, which is particularly important when a proposal has been
copied from an earlier proposal that may have utilized old rates.
All applicable rates will be applied to line item costs within the Expenses page. Calculations will be performed
automatically, based on the following criteria: Object code (cost element) type, Unrecovered F&A Rate Type,
OverHead Rate Type, & Activity Type.
Figure 112 Public Service F&A Tab
Table 56 Public Service F&A Tab Definition
Description Display-only. Shows a textual name that represents a type of rate that falls within the tabbed category.
The type of rate that the system applies to specific cost elements (for example, fringe benefits, F&A or
inflation). Pre-populated from institute rate type section of the institute rate table located on the unit
hierarchy.
On Off Campus Flag Display-only. Either On or Off indicates whether this rate type is used on or off campus.
Fiscal Year Display-only 4-digit numeric year field shows the fiscal year associated with the rate being displayed.
Identifies the institutional fiscal year for which a rate is effective.
Start Date Display-only numeric date field in mm/dd/yyyy format. The start date of a budget period as reflected in
the fiscal period in which the rates apply. In the KRA budget module, this is the date for which a rate
becomes effective.
Institute Rate Numeric percentage field with fixed decimal point. Institutional rate associated with the rate type, on/off
campus and fiscal year.
Applicable Rate Editable. Numeric percentage field with fixed decimal point. In the budget module this is the rate that is
automatically applied to object codes within each budget version, where applicable.
This rate may be different from Institute Rates for a number of reasons (for example,
sponsor stipulations).
Clicking the sync rates button ensures rates are up-to-date, which is particularly important when a
proposal has been copied from an earlier proposal that may have utilized old rates.
Returns Applicable Rate field values to what they were originally displaying prior to you making
changes to them.
Fringe Benefits Tab
The Fringe Benefits tab identifies which fringe benefit rates will be applied to each proposal budget version.
The Applicable Rate field values are pre-populated with the default institute rates, which are pulled in from the
institutional rate tables located within the Unit Hierarchy. You can open the Fringe Benefits tab to see which default
fringe benefit rates have been itemized, and to see if current institutional rates are reflected. You may override the
established/defaulted fringe benefit rates (on a proposal and/or budget version basis) by editing the Applicable Rate
column, where you are also able to enter a different rate for each fiscal year.
Clicking the sync rates button to ensure rates are up-to-date is of particular importance if a proposal has been copied
from an earlier proposal that may have utilized old rates.
All applicable rates will be applied to line item costs within the Expenses page. Calculations will be performed
automatically, based on object code (also known as a cost element).
Figure 113 Fringe Benefits Tab
Table 57 Fringe Benefits Tab Definition
Rate Type The type of rate that the system applies to specific cost elements (for example, fringe benefits, F&A or
inflation). This is by default prepopulated with values from the institute rate type section of the
institute rate table located on the unit hierarchy.
Campus On or Off is displayed to indicate whether the rate applies to on-campus use or off-campus use. The
campus checkbox on Institute Rate is where this is set.
Fiscal Year Identifies the institutional fiscal year for which a rate is effective.
Affected Budget Period This value is automatically generated based on the budget period dates. It indicates the budget period
that will utilize the applicable rate for the identified fiscal year.
Start Date The start date of a budget period as reflected in the fiscal period in which the rates apply. In the KRA
Institute Rate Institutional rate associated with the rate type, on/off campus and fiscal year. Prepopulated from the
rate field within the institute rate tab on the institute rate table located on the unit hierarchy.
Applicable Rate Required. In the budget module this is the rate that is automatically applied to object codes within each
budget version, where applicable.
System populates data in the institute rate and applicable rate fields with the current rates from the
Unit Hierarchy rate table within the specific panel in which the button appears. (The sync rates button
should only appear at the bottom of each panel and not at the bottom of the Rates tab.)
The system resets all values within the applicable rate fields to match the rates listed within the
institute rate fields (whether or not the institute rates are current) within the specific panel in which
the button appears. (The sync panel rates button should only appear at the bottom of each panel and not
at the bottom of the Rates tab.)
Inflation Tab
The Inflation tab identifies what inflation rates will be applied to each object code within a budget version.
The applicable rates are pre-populated with the default institute rates which are initially pulled in from an
institutional rate table (located within the Unit Hierarchy) upon each budget version creation. You can open the Inflation
tab within the Budget Rates tab to see what default inflation rates have been itemized, and to see if current institutional
rates are reflected. You may override the established/defaulted inflation rates (on a proposal and/or proposal version
basis) by editing the Applicable Rates column. You can enter a different rate for each fiscal year.
You can click the sync rates button to ensure rates are up-to-date; this is of particular importance if a proposal has been
copied from an earlier proposal that may have utilized old rates.
Applicable rates will be applied to applicable line item costs within the Expenses page. Calculations will be performed
automatically, based on object code (cost element) table mapping. Inflation rates can be set by each institution, but
generally map to the following rate types on an object code level: employee salaries (of various types), student wages,
tuition, and materials and services. The object code tables will list which object codes falls into each various rate type
as well as which object codes are inflation-bearing.
Figure 114 Inflation Tab
Table 58 Inflation Tab Definition
Rate Type The type of rate that the system applies to specific cost elements (i.e. fringe benefits, F&A, inflation,
etc)
Campus On or Off is displayed to indicate whether the rate applies to on-campus use or off-campus use. The
campus checkbox on Institute Rate is where this is set.
Fiscal Year Identifies the institutional fiscal year for which a rate is effective.
Affected Budget Period The budget period that will utilize the applicable rate for the identified fiscal year.
Start Date The start date of a budget period as reflected in the fiscal period in which the rates apply. In the KRA
Institute Rate Institutional rate associated with the rate type, on/off campus and fiscal year.
Applicable Rate In the budget module this is the rate that is automatically applied to object codes within each budget
version, where applicable.
System populates data in the institute rate and applicable rate fields with the current rates from the
Unit Hierarchy rate table within the specific panel in which the button appears. (The sync rates button
should only appear at the bottom of each panel and not at the bottom of the Rates tab.)
The system resets all values within the applicable rate fields to match the rates listed within the
institute rate fields (whether or not the institute rates are current) within the specific panel in which
the button appears. (The sync panel rates button should only appear at the bottom of each panel and not
at the bottom of the Rates tab.)
Vacation Tab
This is an optional tab that may be implemented at the discretion of your institution based on need. The Vacation tab
identifies the vacation rates that will be applied to each proposal budget version.
Figure 115 Vacation Tab
Lab Allocation Salaries Tab
Lab Allocation - Other
Other Tab
This is an optional tab that may be implemented at the discretion of your institution based on need. The Other tab
identifies what other rates will be applied to each proposal budget version. This tab allows for individual institutions to
populate rates which may be outside of those rate class/types included in the base product.
Figure 116 Other Tab
Unique Page Actions
Table 59 Rates Page - Unique Action Buttons
Button Description
System populates data in the institute rate and applicable rate fields with the current rates
from the Unit Hierarchy rate table within all the rates panels. (The sync all rates button should
only appear at the bottom of the Rates tab.)
The system resets all values within the applicable rate fields to match the rates listed within
the institute rate fields (whether or not the institute rates are current) within all the rates
panels. (The sync all rates button should only appear at the bottom of the Rates tab.)
Project Personnel
Use the Project Personnel page to add or delete personnel who will participate in the project. Any investigators added on
the Key Personnel Tab on the Proposal document will automatically populate the Project Personnel page. You can also
use this page to add additional personnel as necessary (employees, non-employees, and to-be-named individuals).
The Project Personnel page can be thought of as a shopping list of personnel, whereby for each person, you can insert
appointment type and salary information, from which you will select and add to the appropriate budget line items on the
Personnel tab of the Expenses page. KRA will inflate the salaries for annual salary increases, using the salary effective
date, and then calculate direct and indirect costs based on the dates of performance and percentage of effort.
Finally, you can delete any name added to the Project Personnel page if it is later determined the individual will not be
part of the project.
Adding or deleting entries on the Project Personnel page will have no effect on the Key Personnel. Deleting is not
possible if expenses have already been entered.
Page Overview
The Project Personnel page is made up of the following three primary areas from top to bottom:
Selection Area: You are able to add personnel to the budget by using the lookup icons in the Person box to
search, select and return the desired personnel. Each takes you to a lookup screen that allows you to search for
either employees or non-employees. Selecting them and returning them simply closes the lookup screen and
takes you back to the Project Personnel page where the Budget Personnel tab is populated with your selections.
Tabbed Section: The Budget Personnel section displays a numbered list of your selections. Each line item
displays the persons name, job code, appointment type, base salary, and salary effective date; while providing
you with the ability to modify any of these or delete the row from the table entirely.
Action Buttons: In addition to the standard e-doc buttons, you are also able to click the unique synch to
proposal button to synchronize your selections with the associated proposal document.
Add Project Personnel
Figure 117 Add Project Personnel Selection Area
Table 60 Add Project Personnel Selection Area Definition
Field Description
Add Project Personnel section, Person box
Employee Search
Use the lookup to search for and return the desired employees from the HR
database.
Non-employee Search
Use the lookup to search for and return the desired non-employees from
the Rolodex database.
To be named
Use the employee table lookup and button as necessary to specify
positions to be hired or identified once the award is made. For example, returns values such as TBA
Research Assistant or TBA Res. Scientist.
Budget Personnel Tab
Figure 118 Budget Personnel Tab
Table 61 Budget Personnel Tab Definition
Field Description
Person Display-only. The specific individual identified as part of the proposal. Names are fed from the Key
Personnel in the Proposal document.
Job Code Enter the 6-digit alphanumeric value for the Human Resources position identifier directly associated with
the individual named in the Person column.
Appointment Type
Required.
Select from the list the Type of employee or duration of the appointment for the individual names in
the Person column.
Base Salary Required. Calculation base. The individual's current salary less any special pays (administrative
supplements)
Salary Effective
Date
Required. Use the calendar function to locate and select a date, or enter one in mm/dd/yyyy format.
This represents the date of the employee's annual increase.
Actions
Click to remove an individual.
The system brings forth the information associated with any individuals added to the Key Personnel panel
after a budget version (and therefore Project Personnel panel) has already been created. The sync button
only adds information; it does not delete any. Therefore, if a user deleted an individual from the Key
Personnel panel, pressing sync on the Project Personnel panel would not delete the corresponding entry on
the Project Personnel panel.
Sync to proposal?
Synchronize information entered with the corresponding fields in the associated proposal
document.
Expenses Page
The Expenses page itemizes the overall budget information for each budget period. It includes an Overview tab (with
summary information), and the following detailed cost categories broken up into individual tabs for Personnel,
Equipment, Travel, Participant Support and Other Direct.
These cost categories are based on the detailed (non-modular) Research & Related Budget form that is available in the
PureEdge forms submitted to Grants.gov.
You can add budget details to the tabs on this page by assigning object codes/cost elements (and their associated object
code categories) with Total Cost dollar amounts. Each object code/line item entry can also include Descriptions,
Unrecovered F&A, Cost Sharing, and Quantity. Additional attributes for each object code entry can also be added
within the Line Item Details section, and they include Start Date, End Date, Inflation indicator, On/off Campus indicator,
applicable Rate Classes, and budget Justification.
The individual expense line items are summarized automatically by the system and the cumulative totals are reflected in
the Budget Overview tab at the top of the Expenses page.
Page Layout
The Expenses page is made up of the following three primary areas from top to bottom:
Figure 119 Budget Document - Expenses Page Layout
Selection Area: Allows you to select options from two lists and click a button to update the data that is
displayed in the tabbed sections. Refinements include the ability to specify a single budget period and limiting
the view to either simple or full details.
Tabbed Sections: Give you the ability to view critical identifying information in the Budget Overview tab,
and then the remaining tabs allow you to select and add line items for object codes related to categories such as
personnel, equipment, travel or participant support. After adding lines, you are then able to specify simple
things like descriptions, costs and quantities for each. Additionally, you can display more details that allow you
to refine them further, like apply various associated rate costs.
Action Buttons: In addition to the standard e-doc buttons, you are also able to click buttons unique to this
page that perform current period calculation and allow you to view personnel salaries.
Select Budget Period & Item Type
Figure 120 Select Budget Period & Item Type Section
Table 62 Select Budget Period & Item Type Section Definition
Field Description
Select Budget Period & Item (View) Type:
Budget Period
The period of time covering the information you want to view in the Overview tab. Select the
budget period you want to view from the date range options in the list. Click the down arrow to
display the list and click on an item in the list to highlight and select it to populate the box with your
selection.
View
The type of view of the expense information you want displayed. Select either Simple Detail
or Full Detail from the drop-down menu. Click the down arrow to display the list and
click on an item in the list to highlight and select it to populate the box with your selection.
If you selected a different budget period than the one that was initially displayed by default, you must click
this button to revise the information seen on the tab. The budget period and/or view selected will cause that
periods data to appear in the Overview tab.
Budget Overview Tab
Figure 121 Budget Overview Tab
Table 63 Budget Overview Tab Definition
Field Description
Period 1 Start Date Display-only. The beginning date of the time period you want to see in the Overview tab. This value is
automatically populated based on the budget period selected. The system defaults to the period 1
information unless prompted by earlier action in the selection area. The start date of a budget period as
reflected in the fiscal period in which the rates apply. In the KRA budget module, this is the date for which
a rate becomes effective.
Period 1 End Date Display-only. The ending date of the time period you wan to see in this tab. This value is automatically
populated based on the budget period selected. The system defaults to the period 1 information unless
prompted by earlier action in the selection area of the page.
Direct Cost The total amount of the direct personnel, equipment, travel, participant and other costs that will be incurred
Field Description
for the project. Displayed value = sum (direct costs entered into the personnel, equipment, travel,
participant costs, and other tabs). Costs that can be identified specifically with a particular sponsored
project, an instructional activity, or any other institutional activity, or that can be directly assigned to such
activities relatively easily with a high degree of accuracy.
Indirect Cost The total amount of F&A costs that will be incurred for the project. Displayed value = sum (Direct cost
expenses entered into the personnel, equipment, travel, participant costs, and other tabs which are subject
to indirect costs) * the applicable F&A rate. Prepopulated from the data entered and calculated from the
Items tab.
Total Requested
Cost
The sum of the direct and indirect costs that will be incurred for the project. Displayed value = sum (Total
cost fields calculated or entered into the personnel, equipment, travel, participant costs, and other tabs).
Prepopulated from the data entered and calculated from the Items tab.
Period Cost Limit The dollar value, as set by you, which a particular budget period should not exceed. Editable field. Enter a
value if the data is pertinent to the budget period in particular or the proposal in general. See cautionary
note below!
Total Cost Limit The dollar value, as set by you, which the budget should not exceed. Prepopulated from the data entered
and calculated from the Summary tab.
Unrecovered F&A The F&A costs that will be incurred as a result of the project, but will not be paid for by the sponsor.
Prepopulated from the data entered and calculated from the Summary tab. F&A costs which are not
requested or provided by the sponsor.
Cost Sharing The direct costs that will be incurred as a result of the project, but will not be paid for by the sponsor.
Displayed value = sum (Cost Sharing fields calculated in the personnel tab or entered into the equipment,
travel, participant costs, and other tabs). Prepopulated from the data entered and calculated from the Items
tab.
Exceeding the Period Cost Limit: A warning is not generated upon the save action, page navigation, update
view or during validation for exceeding the Period Cost Limit due to the way the database is updated. Use caution
when making your entries so that the calculation and totals are within limits, otherwise, close and reopen the
budget to verify prior to submission for approval.
Personnel Tab
Use the Personnel tab to view budgetary details for all individuals entered into the budget, regardless of cost category.
Items displayed within the report include the object code name, individuals name, and calculated salary amount by
period. Also included within each period are the consolidated amounts for each rate type (for example, calculated F&A
or employee benefits).
When you want to add personnel detail into your budget (rather than merely completing a summary budget), you can use
the personnel budget action. After you have selected an Object Code Name and added a line item, a personnel budget
button appears in the Actions column. Clicking it causes a new screen to appear that allows you to select the individual
and the dates of work, compensation schedule, the percent of effort they will work on the project as well as the percent of
effort that will be charged to the sponsor. After you have entered in the above information and clicked add (or
calculate), the system calculates the salary amount that will be charged to the sponsor and enters the amount in the
calculated salary field. The system, based upon the calculated salary, also performs the secondary calculations such as
cost sharing, unrecovered F&A, cost sharing percentage, and the applicable rate calculations.
In addition, the system completes the Overview tab with the respective cumulative amounts for all persons entered for a
given object code including direct cost, unrecovered F&A costs, and cost share. Also included in the overview are
details such as the object code number and name, start and end date, and the description all brought from entries made in
the Personnel Expenses panel. Finally, the system counts the number of persons entered for a given object code and
enters the total number in the quantity field.
Figure 122 Personnel Tab click show to display Line Item Details
Personnel Budget
Click the personnel budget button from the Personnel tab Action column for the desire personnel line item.
The Line Item Overview and Personnel Budget tabs appear on a new screen:
Figure 123 Line Item Personnel Budget Screen
Table 64 Line Item Personnel Budget Screen Definition
Button Description
Opens the Personnel Budget area which allows you to associate individuals in their
budget.
Recalculates values associated to a given line, in this instance, associated to a selected
individual. This recalculates values in the Personnel Budget area as well as the values
in the associated Personnel Budget Details area.
Closes the Personnel Budget Window and returns you to the Expenses: Personnel
panel.
Object Code Name
A unique descriptor and corresponding identification number within a financial
system, used to identify the type of cost. (AKA Cost Element.) Default
Implementation Values: As defined by the object code table.
Total Base Cost
The sum of the calculated salary values for each individual entered into the
Personnel Budget panel. Default Implementation Values: None
Start Date
Required. Display-only. The earliest date upon which an individual in the given
object code class will expend effort on the project in this period; this is likely to be
consistent with the period start date.
Unrecovered F&A
Facilities and Administrative costs (for example, Overhead, Indirect Costs), incurred
by the applicant organization, that are not requested or provided by the sponsor.
End Date
The latest date upon which an individual in the given object code class will expend
effort on the project in this period; this is likely to be consistent with the period end
date.
Cost Sharing
The sum of the cost sharing values for each individual as calculated in the Personnel
Budget Details sub-panel.
Button Description
Description
The line item description entered by you on the Personnel Expenses Panel at the
summary level.
Quantity
The system-calculated number of unique individuals associated with (added under) the
applicable object code.
Person
The individual for which you are entering budgetary information for and their
associated Job Code. Default Implementation Values: Individuals are brought
forward, in whole or part, from the Project Personnel Panel (see system integration
section.)
Calculated Salary
The amount of an individuals salary that will be charged to the sponsor.
Actions
Standard add, delete for line items.
Expenses Page Tabs
Figure 124 Equipment Tab Example
Figure 125 Travel Tab Example
Figure 126 Participant Support Tab Example
Figure 127 Other Direct Tab Example
Table 65 Budget Expenses Tabs Definition
Column Description
Object Code Name A unique descriptor and corresponding identification number within a financial system used to
identify the type of cost. Also known as Cost Element Name. The cost category description
for the personnel cost elements.
Description Enter up to 200 alphanumeric characters for a detailed explanation for each cost line item,
using the expand text area icon as necessary.
Unrecovered F&A Facilities and Administrative costs like overhead and indirect costs that are incurred by the
applicant organization that are not requested or provided by the sponsor. F&A costs which
are not requested or provided by the sponsor. This is a display-only dollar amount field that is
automatically calculated by the system.
Cost Sharing The portion of the total project costs (direct or indirect) of a sponsored agreement, not
covered/reimbursed by the sponsor. Numeric dollar amount to the tenth decimal point.
Qty The amount of purchasable items within each Expense line item/object code.
Total Base Cost The amount being requested for each Expense line item. This value represents the overall
Column Description
value for all Quantities listed within each line item.
Actions Click add or delete as necessary for line item specification.
view personnel salaries button Prints the list of salaries into a form in portable document format.
Line Item Details Section
Figure 128 Line Item Details Section
Table 66 Line Item Details Section Definition
Field Description
Start Date The beginning date in which each Expense line item becomes applicable or will be incurred. The
start date of a budget period as reflected in the fiscal period in which the rates apply. In the KRA
End Date The last date in which each Expense line item is applicable, or the last date of incurrence.
Category The institutional or applied rate associated with Facilities & Administrative (overhead) costs.
Apply Inflation? An indicator that determines whether the Expense line item will have inflation applied to it,
whenever its copied/applied into future budget periods.
On Campus? An indicator that determines whether the Expense line item will get on campus or off campus rates
applied to it. Determined by the on/off campus flag (attribute within the object code table) for each
object code.
Rate Classes subsection
Rate Class column The institutional or applied rate associated with Facilities & Administrative (overhead) costs.
Rate Type column The type of rate that the system applies to specific cost elements (i.e. fringe benefits, F&A,
inflation, etc)
Apply? column An indicator that determines whether the specified rate class/rate type will be applied to the
Expense line item. A checkmark (yes indicator) will apply the applicable rate to the Cost field.
Cost column The direct cost requested from the sponsor associated with the specified rate class/rate type for each
Expense line item.
Cost Sharing column The portion of the total rate cost not covered/reimbursed by the sponsor. This amount is applied
whenever the applicable rate is lower than the institute rate.
Justification subsection
Apply to later periods
button
System uses the current values/attributes & does takes one of the following actions: 1) creates new
line items within future budget periods by copying the current line item budget
information/attributes, 2) if future budget line items have already been created/copied forward
(linked), the changed &/or current value/attributes will be applied into future budget periods.
If Budget Personnel details for the same object code/line item exist in future budget periods,
Field Description
and you make a change to an interim personnel line item attribute (such as a change to the Apply?
checkbox), this button cannot be used, and will produce an error message.
This feature doesnt work the same way with Personnel fields as with Travel fields
(when new travel lines do not have periods specified). Specifically, it wont apply info to
Personnel because budget lines already exist.
Sync to cost limit button The system will deflate the current line item amounts (including Direct Costs, associated rates, etc.)
to match the Period Cost Limit specified. Cannot be used on Personnel line items that have detailed
budget personnel data associated with them.
Unique Actions
Table 67 Expenses Page - Unique Action Buttons
Button Description
The system will re-calculate all line itemamounts within the specified budget period -- based
on current/changed values, rates &/or line item attributes (such as Rates, inflation, on/off
campus).
Prints the list of salaries into a form in portable document format.
Totals Page
The Totals page displays the totals of each expense object code for each budget period, the calculated expenses for each
period, and the budget period total. The grand total for each expense object code, calculated expense, and budget period
totals are also included.
The Totals page has one tabbed section, also called Totals. Within the Totals tab are the following three sections:
Expenses: Display-only listing of fixed expenses by object code with period amounts and totals.
Calculated Expenses: Display-only listing of expenses that involved rates prone to fluctuation.
Totals: Display-only column totals by period and a grand total of expenses and calculated expenses.
If it immediately appears that the period values do not add up to the line total, it is because some may not be
currently displayed even though they are part of the equation. The screen area limits the display to only five
periods, but when more than five exist, navigation buttons allow you to view them. Use the <back and next>
buttons located above the period column headings to scroll and customize the display as desired.
Totals Tab
Figure 129 Totals Tab
Table 68 Totals Tab Definition
Field Description
Expenses section
Object Code Number The object code value for the displayed budget line item.
Object Code Name Description of the displayed Object Code line item.
Period navigation
<back/next>
Click to scroll through the display of the budget periods (only 5 columns are displayed at a given
time due to screen real estate)
Period # columns Display of the dollar amount for the Object Code line item in the displayed Budget Period. This
column will replicate for each additional Budget Period.
Total The total dollar amount for the Object Code line item for all budget periods. This column is the last
column displayed on the right.
Calculated Expenses section
Period # columns Display of the dollar amount for the Object Code line item in the displayed Budget Period. This
column will replicate for each additional Budget Period.
Total The total dollar amount for the Object Code line item for all budget periods. This column is the last
column displayed on the right.
Totals section
Period # columns Column totals. Display of the dollar amount for the Object Code line item in the displayed Budget
Period. This column will replicate for each additional Budget Period.
Total Column totals. The total dollar amount for the Object Code line item for all budget periods. This
column is the last column displayed on the right.
Distribution & Income Page
The Distribution & Income page is made up of the following three primary areas from top to bottom:
Selection Area: Allows you to select a budget period option from a list and then click a button to update the
first two tabbed sections to only include information related to that budget period. All periods are displayed by
default.
Tabbed Sections: Display distribution lists for cost sharing and unrecovered F&A; and also enable you to
add lines for income details and amounts by period, as well as calculate and view a summary of those line item
totals.
Action Buttons: In addition to the standard e-doc buttons, you are also able to click buttons unique to this
page that synchronize or reset all of the rates.
Select Budget Period
Figure 130 Select Budget Period Section
Figure 131 Budget Period Field List
Table 69 Select Budget Period Section Usage
Field Description
Budget Period Click on a numbered date range item in the list to select a Budget Period and then click the
update view button.
Click this to update the data that can be viewed on the Cost Sharing, Unrecovered F&A, and
Project Income tabs for the budget period you selected in the Budget Period field.
Figure 132 Distribution & Income Page Tabs
Cost Sharing Tab
The Cost Sharing Distribution List section of the Cost Sharing tab is used to allocate any cost sharing committed in the
budget to the appropriate source (account). The KRA budget cannot be set to Complete status until cost share amounts
are distributed (if the Force Cost Sharing Distribution parameter is set to YES. A hard data validation error will ask you
to distribute cost share expense if there is any cost sharing in any period for the budget. Distributing cost sharing means
to provide account numbers responsible for incurring the expense. This section allows you to distribute the cost share by
dollar amount to specified source account(s) and specified fiscal years. It also displays a summary of committed cost
share both by individual budget periods and a project total.
Figure 133 Cost Sharing Tab
Cost Sharing Distribution List Section
Field Description
Fiscal Year Enter in yyyy format your institutions financial fiscal year in which the cost share expense will be incurred,
assigned, or allocated. This identifies the institutional fiscal year for which a rate is effective.
Percentage Enter the proportion of total cost sharing to be allocated among various fiscal years and funding sources.
Source Account The account number or funding source description which will provide the funds for the allocated cost share
amount. The source Ledger ID assigned by institution (based on an institution's chart of accounts) to
identify the account in the institution's financial system. The account that details the cash resources that will
be used to cover the expenses that will post in the Destination account.
Amount The dollar amount of budgeted cost share that is assignable to each fiscal year and funding source.
Actions Add a line item by clicking the add button. Delete the line item by clicking the delete button.
Total Allocated Displays the sum total of all allocated amounts entered.
Unallocated Displays the sum total of all unallocated amounts entered.
Cost Sharing Summary Section
Field Description
Period 1 Cost Sharing Cost sharing by period total.
Period 2 Cost Sharing Cost sharing by period 2 total.
Total Cost Sharing Total cost sharing of all periods.
Resets the data you entered by overriding it and extra line items (in addition to defaults, if any) will be
deleted.
Override any existing values with the system-generated default lines/values.
Unrecovered F&A Tab
Facilities and Administrative Costs are real costs incurred by an institution in support of sponsored activities, but cannot
be easily identified with a specific project or sponsored activity. The costs result from shared services or are incurred to
benefit common and joint objectives. F&A costs are synonymous with indirect costs, IDC, and overhead costs.
There are times when a sponsor (federal, foundation, industry, etc), will not pay the full F&A rate established by the
institution. When this occurs, a different F&A rate is applied to the cost base being utilized by the project (Total Direct
Cost, Modified Total Direct Cost or other). When a different rate other than the institutional set rate is applied, the
system generates an amount of Unrecovered F&A, also known as underrecovered funds. Since the full indirect costs
are not recovered by the project sponsored, the institution must provide the remaining expense usually captured with full
IDC.
The Unrecovered F&A tab allows you to specify F&A costs which are not requested or provided by the sponsor.
The system generates an unrecovered amount under the following circumstances:
When the apply box for the overhead rate on the line item expenses is unchecked, the system will apply the
entire Institute rate as Unrecovered F&A.
When the apply box for the overhead rate is checked, if the Applicable Rate is lower than the Institute Rate, the
system will apply the difference as Unrecovered F&A. If the Applicable Rate is over the Institute Rate a
negative, Unrecovered F&A is generated.
The same conditions also apply to Cost Sharing amounts you enter.
When Unrecovered F&A is generated on a budget, you need to identify the funding source(s) for the budget. The
sources of funding are identified in the Unrecovered F&A Distribution Panel on the Distribution & Income Tab.
This is configurable (as with cost share) by institution because not all schools require this commitment for reduced
F&A.
Figure 134 Unrecovered F&A Tab
Unrecovered F&A Distribution List Section
Field Description
Fiscal Year Enter the year in yyyy format that the funds will be expended. Identifies the institutional fiscal year for which
a rate is effective.
Applicable Rate The Rate of Unrecovered F&A set on budget summary. In the budget module this is the rate that is
automatically applied to object codes within each budget version, where applicable.
This rate may be different from Institute Rates for a number of reasons (for example, sponsor
stipulations).
On Campus
Select yes or no from the drop-down list. to indicate whether the activity is on or off campus.
Source Account Enter the number of the account that unrecovered F&A will be paid from. Ledger ID assigned by institution
(based on an institution's chart of accounts) to identify the account in the institution's financial system. The
account that details the cash resources that will be used to cover the expenses that will post in the Destination
account.
Amount Enter the dollar amount in dollars and cents.
Actions
to add your entry as a numbered line item below
to remove a numbered line item from the calculation table
Total Allocated The sum total of all allocated funds entered.
Unallocated The sum total of all unallocated funds entered.
Unrecovered F&A Summary Section
Field Description
Period 1 Unrecovered F&A totals by period are generated and displayed
Period 2 Unrecovered F&A totals by period are generated and displayed
Total Sum total from all periods unrecovered F&A
Resets the data you entered by overriding it and extra line items (in addition to defaults, if any) will be
deleted.
Project Income Tab
Project income is gross income earned by the University that is directly generated by a sponsored activity or earned as a
result of an award. In cases where income is anticipated, it must be reported to the sponsor. Sometimes, the sponsor will
reduce the award based on the anticipated project income. At other times, the project income will be used as additional
support for the project. (The exact disposition of these funds is usually stipulated in the sponsors program
announcement and/or award guidelines.)
The Project Income tab allows you to detail how much income is anticipated by the project by period, and the source of
the income.
Figure 135 Project Income Tab Example
Table 70 Project Income Tab Definition
Field Description
Income Details section
Period A list of periods defined for the current Budget Version
Income Amount of income anticipated during the budget period
Description Description of where the Project Income is coming from
Amount
Actions
Project Income information will be added to the database
Field Description
Project Income will be deleted from the database
Income Summary section
Period # Income Sum of the income from each period
Total Income Total the income for all periods
Unique Actions
Table 71 Distribution & Income Page Action Buttons
Button Description
System populates data in the institute rate and applicable rate fields with the current rates
from the Unit Hierarchy rate table within all the rates panels. (The sync all rates button should
only appear at the bottom of the Rates tab.)
The system resets all values within the applicable rate fields to match the rates listed within
the institute rate fields (whether or not the institute rates are current) within all the rates
panels. (The sync all rates button should only appear at the bottom of the Rates tab.)
Modular Budget Page
The KRA Budget document allows you to create a Modular budget for submission with Proposals to the National
Institutes of Health (NIH). Most NIH proposals using the modular format will be submitted via Grants.gov.
The Modular Budget page of the Budget document is used to fulfill NIH requirements for applications that require use of
the modular format. The hallmarks of the modular format are:
The sponsor is an NIH institute or center. The NIH is the only sponsor that uses the modular format.
One module equals $25,000 (direct costs).
Typically, the direct costs in any single year (not including consortium F&A costs) do not exceed $250,000,
although certain NIH programs allow the direct cost threshold to be higher.
A detailed budget is not submitted to the sponsor.
The modular budget format page contains the direct cost amount per year, expressed as modules, consortium
F&A costs (if any), and text description for personnel, variance in the number of modules requested from year
to year (if any), and subawards/consortium (if any).
The modular budget can be created directly from the modular budget page. A detailed budget is not required.
Page Layout
The Modular Budget page is made up of the following three primary areas from top to bottom:
Figure 136 Modular Budget Page Overview
Selection Area: Allows you to select a budget period option from a list and then click a button to update the
first two tabbed sections to only include information related to that budget period. All periods are displayed by
default.
Tabbed Sections: Include an overview of the basic identifying information about the modular budget, and
tabs for both direct costs and F&A funds requested.
Action Buttons: In addition to the standard e-doc buttons, you are also able to click a button that is unique to
this page that allows you to synchronize modifications made on this page with other pages that display this
information.
Select Modular Budget Period
This section of the Modular Budget page provides a means for budget period selection via a drop-down list, and a means
for customizing the information displayed in the tabbed sections that follow this section to include only that which is
pertinent to the selected budget period via an update view button.
Figure 137 Modular Budget Period Selection Section
Table 72 Select Modular Budget Period Usage
Field & Button Description
Budget Period Select a date range from the Budget Period list by clicking the down arrow to display the list and clicking
on a range item to highlight and display it in the box. Note: you must then click the update view button
for the selection to take effect and populate the Modular Budget Overview tab with information from this
budget period.
Click this after making your selection (if other than the default selection of Period 1) in the Budget Period
field to display information from the selected period in the Modular Budget Overview tab.
Modular Budget Overview Tab
Figure 138 Modular Budget Overview Tab
Table 73 Modular Budget Overview Tab Definition
Field Description
Period # Start Date The start date of the specific budget period being viewed.
Period Total Requested Cost Total requested amount for the displayed period, including direct costs, F&A costs, and
Consortium F&A Costs.
Period # End Date The end date for the displayed period.
Project Total Requested Cost Sum of all period total requested costs from each budget period view. Total requested amount
for the entire project period, including direct costs, F&A costs, and Consortium F&A Costs.
Direct Cost Tab
Costs that can be identified specifically with a particular sponsored project, an instructional activity, or any other
institutional activity, or that can be directly assigned to such activities relatively easily with a high degree of accuracy.
Figure 139 Direct Cost Tab
Table 74 Direct Cost Tab Definition
Field Description
Direct Cost Less Consortium F&A The direct costs from the detailed budget, less any direct costs that are associated with a
consortiums F&A costs this value is then converted into module increments of
$25,000. Sync button converts to nearest 25K increment (rounding up only). Consortium
is also known as a sub-award or subcontract. Direct costs requested for the period, not
including any amounts budgeted for Consortium F&A.
Consortium F&A The direct costs requested in the budget that are associated with a subcontracts F&A (if
any). Sync button pulls the actual direct cost amount (associated with the subcontracts
F&A) from the detailed budget. Costs budgeted for Consortium F&A (indirect costs on
budgeted subawards).
Total Direct Cost Direct Costs plus Consortium F&A Costs (excluding the institutions F&A costs) being
requested to the sponsor for the period. The sum of the Direct Cost Less Consortium
F&A field & the Consortium F&A field.
F&A Tab
Facilities and Administration. Costs that are incurred for common or joint objectives and, therefore, cannot be identified
readily and specifically with a particular sponsored project, an instructional activity, or any other institutional activity.
F&A costs are synonymous with indirect costs and overhead costs.
Figure 140 F&A Tab
F&A Section
Figure 141 F&A Section
Table 75 F&A Section Definition
Field Description
Add The entries/selection you make in fields provided in this row are added as numbered line items under
this row after clicking the add button in the right column.
F&A Rate Type Select the Rate Type (MTDC, TDC, etc) from the drop-down menu for the overhead rate (base)
specified in the proposal. Note: the initial default is based on the F&A Rate Type setting field from
the Summary page.
IDC Rate The applicable indirect cost rate being charged/requested from the sponsor.
IDC Base The detailed budgets indirect cost base.
F&A Funds Requested The total F&A costs being requested to the sponsor (F&A Rate x F&A Base), which equals F&A Rate
* F&A Base. After clicking the sync button, the F&A Rate is multiplies by the F&A Base to get a
value that is later editable and does not have to sum across.
Actions Add or delete line items as desired.
Totals Section
Table 76 Recalculate Totals Section
Field & Button Description
Total Totals are displayed in this field and may be updated to reflect recent changes by clicking the associated
recalculate button.
Totals are updated based on recent modifications and/or entries/selections.
Unique Action
Table 77 Sync Button - Modular Budget Page
Button Description
Synchronizes the detailed budget to the modular budget.
Budget Actions Page
The Budget Actions page consists of the following two tabbed sections:
Print Forms: Enables selection and printing of forms including Budget Summary by Period, Cost Sharing
Summary by Period, Cumulative Budget, and Industrial Budget by Period.
Budget Justification: Allows you to view who last updated this budget and when; while also providing a
box for you to enter text to explain the reason the budget is needed, and a button that lets you consolidate
expense justifications.
Figure 142 Budget Actions Page Tabs
Print Forms Tab
Use the Print Forms tab when you want to view or print generic budget forms included with the application. (Sponsor-
specific forms such as the Grants.gov budget forms are viewed/printed in the Proposal area of the module in the Forms
section of the Grants.Gov page, or the Print Forms tab on the Proposal Actions page). You are then able to select to
view/print all of the generic budget forms, or select to view/print each form individually.
The generic forms included are: Budget Summary by Period; Cost Sharing Summary by Period; Cumulative Budget;
and Industrial Budget by Period.
Figure 143 Print Forms Tab
Table 78 Print Forms Tab Definition
Field Description
Budget Summary by Period
Click within the checkbox to select this line item. The green check mark indicates the
line is selected. Click again to clear the mark and deselect.
Cost Sharing Summary by Period
Field Description
Cumulative Budget
Industrial Budget by Period
Select (all | none) Click the all link to check all boxes at once, so that when print selected is clicked, all
forms will be printed. Click the none link to deselect any previously-selected checkboxes
so that none have the green check mark.
Click to print all forms that are selected (green check mark appearing within the line item
check box in the right column).
Budget Justification Tab
Most funding agencies want justifications as to why an item is needed for the sponsored project associated with the
proposal, when it is needed and how it will be utilized to benefit the project. The justification provides explanation for
the budget created. Justifications provide explanations for the auditors, sponsor accountants and accountants at your
institution. If one does not provide a justification for an item, they are at greater risk of having their requested line item
eliminated by the sponsor if they do not feel it is necessary. Items that are normally covered under F&A need to be
justified as to why they are included on the budget request vs. being covered by F&A.
The Budget Justification tab provides an efficient means for consolidating the individual justifications that you may have
entered for each expense line item. It is not required that you use this functionality, however, it serves as a tool to help
you write the budget justification that you will attach (via the Notes and Attachments tab) and send to the sponsor.
The budget justification that is consolidated or entered on this tab does not flow through to the sponsor.
Figure 144 Budget Justification Tab
Table 79 Budget Justification Tab Definition
Field Description
Last Updated Timestamp Date and time that action was taken by last logged in user.
Updated By Name of individual logged in. This allows others to see who put values into budget
justification.
Justification Text Type to enter the justification that provides explanation for the budget created.
Click to command the system to take the line item budget justifications and consolidate them
into one article.
You must have the Proposal role of Aggregator or Budget Creator to use this feature.
Budget Actions Page Process Overview
To consolidate expense justifications:
1. Type to enter text in the Justification Text box as necessary and click the consolidate expense
justifications button.
The system displays the line item justifications consolidated by period.
2. Make Modifications as desired to the Justification Text.
3. Click save at the bottom of the page.
The system saves the data and records you as the individual who last updated the data.
Kuali Research Administration v.1.0 User Guide Proposal & Budget Completion Process 205
Proposal & Budget Completion
Process
Scope
This procedure covers an example the navigation and completion sequence for preparation and submission of Proposal
and Budget documents in the Proposal Development module of KRA.
This procedure does not cover what occurs after routing or after an approved Proposal has been submitted.
Policy
The tasks that comprise this procedure may be completed in a different sequence, depending on your unique
customization and/or configuration of the software to suit your institutions policies and business rules.
Responsibility
The Principal Investigator is responsible for ensuring this procedure is accurate, necessary, and reflects actual practice at
your institution.
Activity Preface
This activity is performed whenever there is a need for development of electronic proposal and budget documentation for
a proposed research project at a higher education institution that will be submitted to a potential sponsor agency for
consideration.
This is intended to serve as an example of a likely KRA Proposal and Budget Development module completion
sequence. KRAs flexibility allows for electronic proposal and budget document preparation to suit the personnel
and business processes involved at your institution.
The Generic Actor associated with the tasks in this procedure may refer to any the following equivalent, applicable job
titles:
Researcher
Unit
Central Admin
Principal Investigator
Initiator
Proposal Creator
206 Proposal & Budget Completion Process Kuali Research Administration v.1.0 User Guide
This is merely a sample scenario. One individual could theoretically perform all of the following, however, it is
likely that more than one is involved at most institutions.
Aggregator
1. Click Create Proposal link or Proposal Development add button from main user menu.
This creates a new, blank Proposal document.
2. Log in to the systemas necessary.
Enter your user name and password in corresponding fields and click login button.
3. Make entries and selections for required fields on the Proposal page.
These include Description in Document Overview tab and Required Fields for
Saving Document tab.
4. Click save.
This prevents loss of work and need to start over.
If stay on Proposal page, go to task #5. Otherwise, go to task #6.
5. Complete the remaining, optional fields on the Proposal page tabs.
Click show as necessary to view hidden tab fields for the Sponsor & Program
Information, Organization/Location, Delivery Info and Keywords tabs.
6. Add users and assign roles to them on the Permissions page.
Use the person lookup to add users and select from Aggregator, Narrative Writer,
Budget Creator and Viewer for each.
7. Select people and assign them proposal roles on the Key Personnel page.
Use the search feature to locate employees and non-employees.
Select from Principal Investigator, Co-Investigator & Key Person for each person.
If proposal a Grants.gov opportunity, go to task #8. Otherwise, go to task #10.
8. Use the opportunity search on the Grants.gov page to select the opportunity.
Some of the fields on the Grants.gov page tabs are populated automatically where possible
based on the opportunity you selected.
9. Complete the remaining Opportunity, Submission Details, and Forms tab fields as
needed.
Budget Creator
10. Enter a name for the budget version and click add on the Budget Versions page.
11. Click open to navigate to the Budget document.
12. Make necessary adjustments to the Summary page information, including the budget period
dates.
13. Make necessary adjustments to the Project Personnel page information.
The name list display is based on selections made on the Key Personnel page of the Proposal
document.
You may remove, use search to add, or add to-be-named positions.
14. Verify the rates utilized for this budget version on the Rates page, and make corrections as
necessary.
15. Change the view or period on the Expenses page as desired to verify the dates.
16. Set a cost limit for the period as necessary.
17. Complete all remaining tabs as necessary for all budget periods.
Personnel, Equipment, Travel, Participant Support and Other Direct.
If proposal a modular budget submission, go to task #18. Otherwise, go to task #19.
18. Complete all tabs on the Modular Budget page.
19. Check the Totals page for accuracy.
20. Use the Distribution & Income page to distribute any cost share, project income or
unrecovered F&A, if applicable.
21. Print budget forms and consolidate budget justifications as necessary on the Budget Actions
page.
22. Click save.
23. Click return to proposal to complete remaining tabs.
Narrative Writer
24. Enter all required information on the Abstracts & Attachments page.
Proposal Abstract, Personnel Attachments and Proposal Narrative tabs.
25. Click save.
Aggregator
26. Enter all required information on the Special Review page.
27. Enter all required information on the Custom Data page.
28. Enter all required information on the Questions page.
29. Validate all levels on the Data Validation tab of the Proposal Actions page.
If errors, go to task #30. Otherwise, go to task #31.
30. Click the associated fix button for each error, save changes, and run validator again.
31. Verify the workflow on the Route Log tab, adding approvers or viewers as desired.
32. Click save.
33. Click route.
End of activity.
Figure 145 - Proposal & Budget Development Completion Example Process Flowchart
Figure 146 - Proposal and Budget Development Page Completion Sequence Example
Kuali Research Administration v.1.0 User Guide Maintenance Documents 211
Maintenance Documents
This topic includes subtopics for all maintenance documents, and each is arranged alphabetically. Where possible,
unique fields are defined and graphics of test environment screen captures are provided to enhance your understanding of
each maintenance documents purpose.
About the screen shot example data: KRA Maintenance Documents are for the most part configurable by
implementing institution. Some are delivered with pre-populated, generic or bootstrap data that can be used as-is or
modified to suit your institutions unique needs. When possible, the screen shots in this user documentation show
populated fields that demonstrate acceptable input. Additionally, the Example subtopic sections for each maintenance
document topic section include lookup result values from the demonstration data used in test environments. It does not
necessarily reflect actual practice at any particular institution, and is provided merely to give you an idea of how each
maintenance document might be used.
212 Maintenance Documents Kuali Research Administration v.1.0 User Guide
Abstract Type Maintenance Document
written in less technical language than the proposal narrative.
Document Layout
The Abstract Type Maintenance Document includes the unique Edit Abstract Type(s) tab in addition to the standard tabs.
This maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Cross-reference to usage instructions
Document Header
For more about the document header information, see E-Doc Header in the E-Doc
Fundamentals section of KRA Overview.
For information, see Common E-Doc Tabs in the E-Doc Fundamentals section of KRA
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
For more information about options appearing in the action button area of maintenance
documents, see Common Maintenance Document Operations in KRA Overview.
Edit Abstract Types Tab
Unique to this maintenance document, this tabbed section allows you to specify the details associated with the reference
table, including a textual description of the abstract type.
Field Description
Abstract Type Required. Enter the alphanumeric code value that is to be used to identify and reference this individual type of
abstract.
Description Required. Enter a textual name for the abstract type that uniquely represents a summarized explanation of its
meaning and/or purpose (for example, a title, several words separated by spaces, or a short phrase). The
abstract, or project summary, is a concise, clear, and brief description of the project. It should outline the
problem, the objectives, expected outcomes, including significance of the project to the field being studied. The
abstract is usually written in less technical language than the proposal narrative.
Process
For information about creating a new maintenance document, see Initiating A Maintenance Document in
Common Maintenance Document Operations.
For information about modifying an existing maintenance document, see Editing A Maintenance Document in
For information about routing a maintenance document, see Submitting A Maintenance Document in Common
Maintenance Document Operations.
Examples
Activity Type Maintenance Document
The Activity Type Maintenance Document allows you to specify the list of activities from which to select to specify the
type of activity proposed, (for example, organized research or instruction) in Proposal documents. Activity type refers to
the major functions of an institution based on OMB Circular A-21. Per OMB Circular A-21, the major functions of a
"university" are instruction, sponsored instruction and teaching, departmental research, organized research, sponsored
research, university research, other sponsored activities, and other institutional activities. Each account in an institution's
financial system must be identified by its activity type.
Document Layout
The Activity Type Maintenance Document includes the unique Edit Activity Types tab in addition to the standard tabs.
The Activity Type Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Activity Types Tab
The Edit Activity Types tab has two required fields used to maintain the reference table, Activity Type, and Description.
Field Definition
Activity Type Required. Enter up to 3 alphanumeric characters for this single type of activity (or a value or code that can
include numeric digits or letter/digit combinations) that will be used to identify and reference this information
object.
Description Required. Enter a textual name for this type of activity that uniquely represents a summarized explanation of its
meaning and/or purpose (for example, a title, several words separated by spaces, or a short phrase). This
represents the familiar name of the OMB Circular A-21 major university function (for example, Instruction or
Research). Each account in an institution's financial system must be identified by its activity type.
Process
Example
Budget Category Maintenance Document
The Budget Category maintenance document is used to establish and maintain a reference table used in proposal budget
development.
Document Layout
The Budget Category Maintenance Document includes the unique Edit Budget Category tab in addition to the standard
tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Budget Category Tab
The Edit Budget Category tab has two required fields and one optional field to maintain each table record item, including
Budget Category Code, Category Type, and Description.
Field Definition
Budget Category Code Required. The unique value used for identification of this budget category in the system as an
abbreviated version of its full name in the Description.
Category Type A classification of budget category that is an abbreviated version of the complete name. Use the
Lookup or Direct Inquiry icons as desired to search for and select the type.
Description Required. Enter a textual name for this budget category that uniquely represents a summarized
explanation of its meaning and/or purpose (for example, a title, several words separated by spaces, or
a short phrase).
Process
Example
Budget Category Mapping Maintenance Document
The Budget Category Mapping maintenance document allows you to map Coeus category codes with KRA codes and
save them as individual maps that can be reused throughout the system.
Document Layout
The Budget Category Mapping Maintenance Document includes the unique Edit Budget Category Mapping tab in
addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Budget Category Mapping Tab
The Budget Category Mapping tab has three required fields used to define and modify budget category mappings.
Field Definition
Coeus Category Code
Required. A numeric value that uniquely identifies the Coeus category.
Mapping Name
Required. The name of the mapping used to map the Coeus category code to the target
category code.
Target Category Code
Required. The unique category code in KRA that the Coeus Category Code is being mapped
to.
Process
Examples
Budget Category Maps Maintenance Document
Budget Category Maps are used to categorize existing mappings of budget map codes for use in proposal & budget
development.
Document Layout
The Budget Category Maps Maintenance Document includes the unique Edit Budget Category Maps tab in addition to
the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Budget Category Maps Tab
The Edit Budget Category Maps tab has four fields, three of which are required to establish and maintain the table record
entry.
Field Definition
Mapping Name
Required. The name of the mapping used to map the Coeus category code to the target category
code.
Target Category
Code
Required. The unique category code in KRA that the Coeus Category Code is being mapped to.
Category Type
Required. Enter a value that uniquely identifies the type of category.
Description Required. Enter a textual name for this budget category map that uniquely represents a summarized
explanation of its meaning and/or purpose (for example, a title, several words separated by spaces, or a
short phrase).
Process
Examples
Budget Category Type Maintenance Document
The Budget Category Type maintenance document enables you to establish and edit types of budget categories and
specify the sequential order in which they are sorted when made available for reference/selection in proposal & budget
development.
Document Layout
The Budget Category Type Maintenance Document includes the unique Edit Budget Category Type tab in addition to the
standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Budget Category Types Tab
The Edit Budget Category Types tab consists of three fields, two of which are required, that allow for definition of each
type of budget category.
Field Definition
Budget Category Type Required. Enter up to 3 alphanumeric characters to specify the code that represents this unique type
of budget category and serves as an abbreviated form of its full name or description.
Description Required. Enter text to uniquely identify a type of budget category by name. Whether a single word
or several sentences, this text is used to describe the purpose and meaning of the budget category
type.
Sort Id Enter up to 2 numbers to assign a unique number by which this budget category type may be easily
and logically ordered amongst others.
Process
Examples
Budget Status Maintenance Document
The Budget Status maintenance document provides a means for creating and updating the various states a budget
document (version) can be in, as they related to proposal development.
Document Layout
The Budget Status Maintenance Document includes the unique Edit Budget Status tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Budget Status Tab
The Edit Budget Status tab allows you to specify two required fields of information a numeric code and a textual
description to define each status.
Field Definition
Budget Status Code
Required. Enter the value that uniquely identifies this individual budget status in the system.
Description
Required. Enter the familiar textual name for this budget status that uniquely represents a
summarized explanation of its meaning and/or purpose (for example, a title, several words
separated by spaces, or a short phrase).
Process
Examples
Cost Element Maintenance Document
The Cost Element maintenance document lets you establish and maintain the cost elements to be made available from
which to select in proposal and budget development.
Document Layout
The Cost Element Maintenance Document includes the unique Edit Cost Element tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Cost Element Tab
The Edit Cost Element tab requires three fields be populated to record each entry in the reference table, with the option
of associating each with a particular budget category code.
Field Definition
Cost Element Required. Enter a numeric value for the cost element to uniquely identify it in the system.
Budget Category Code Enter if known or select using the lookup and/or direct inquiry icon tools the budget category code
that you want to associate this cost element with.
Description Required. Type to enter the textual name for the cost element, as it is commonly referred to in your
business process.
On/Off Campus Flag Required. Click to place the green check mark within the check box to indicate that this cost element
should have an On/Off campus selection option whenever this cost element is selected, or click again
to remove the check mark (or leave blank) and clear the check box to indicate that the ability to
select whether this cost element pertains to on or off campus is not going to be used for this cost
element. Indicates whether a rate applies to on campus use or off campus use.
Process
Examples
Country Maintenance Document
The Country maintenance document is a lookup-only screen with hard-coded values that represent each country in the
world. It is accessed via the Country menu link, which displays the Country Code Lookup screen. A search returns
a static two-column result table that displays a three-character code for each country, and a description containing the
full name of the country. The contents of each Country Code column is underlined to indicate it is a drill-down link that
displays a pop-up window with the same information that is displayed in the search result table: the code and the
description.
Search Field Definition
Country Code This is the abbreviation or acronym used to refer to the country (three upper cased letters) in the system.
Description The full textual name of the country in English.
Examples
Current Locks
Current Locks (also referred to as Document Lock or Pessimistic Lock) is a function that allows Administrators to delete
pessimistic locks on transactional documents to enable editing of those documents by a user other than the current lock
owner (typically the documents Initiator). The Current Locks link or Document Lock link in the Other group on the
Administration menu takes you to the Pessimistic Lock Lookup screen. It allows you to search for currently-locked
documents and remove the locks one at a time. The user who is the lock owner needs to be notified in advance of a lock
deletion because when it is no longer locked, another user may edit and save the document first, which not only gives
them the lock instead, but it also could prevent loss of work by the original lock owner. In order to have the ability to
perform document lock delete actions, a user must be a member of the WorkflowAdmin workgroup.
It is recommended practice that after you have been notified that a document you own a lock on will have that lock
removed, you copy data and text you have entered into fields that you have not yet saved and paste it into a text
file (for example, Notepad), so it will not become lost work.
Lock Descriptor is the document number followed by a dash and then the document type (for example, 2185-
PROPOSAL).
Generated Time is the time the lock was generated, which is the time the document was initiated.
For information about conducting a search, see Lookup Help in KRA Overview.
To remove a document lock:
Enter criteria as desired and click search.
Click delete in the Actions column for the document you want to unlock.
You are returned to the Administration Menu.
If you select Document Lock again and click search, you will see that the document you deleted no longer
appears in the result table.
For information about exporting Pessimistic Lock Lookup results, see Export Options
Locked Document Access Attempt When You Do Not Have Permission
When You Need To Edit A Locked Document, You Can Be Added Via the Permissions Page
Notification of Locked Document When You Do Have Permission to Edit By Reloading
For more information about roles and rights, see Access in KRA Overview.
Custom Attribute Maintenance Document
The Custom Attribute Maintenance Document provides a means for adding, modifying, or deactivating custom attributes
not provided with the delivered KRA software download. A custom attribute is a data element needed by an institution
that is not available out of the box from the application. Custom attributes can be defined as Text, Date, or Numeric
fields. Further, you are able to define the size of the field, a default value, whether it is to be required, and whether there
is a lookup for the attribute. A custom attribute can be included in a group to force it to be included with other attributes
with the same group designation. One or more Kuali modules can be assigned to an attribute to indicate that this
attribute is used by them, and also to indicate that the attribute is required for the specified module(s).
Document Layout
The Custom Attribute Maintenance Document includes the unique Edit Custom Attribute tab in addition to the standard
tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Custom Attribute Tab
The Edit Custom Attribute tab includes four required fields that allow you create and maintain the Id, Data Type Code,
Label, and Name, along with optional fields that further define the unique characteristics of each table record entry.
Field Definition
Id Required. Enter a number that will uniquely identify this custom attribute in the system.
Data Length Enter a numeric value to specify the maximum number of characters the attribute can be comprised of.
Data Type Code Required. Select from the drop-down list the type of data you want to use to categorize this attribute code.
Default Value Enter the specific attribute name if you want to preselect an initial value when this attribute is used.
Group Name Enter a textual representation of the category by which this custom attribute is to be associated.
Label Required. The title of the field or text that represents the display of the attribute within the user interface.
Lookup Class Select a classification of existing system lookups to associate this custom attribute with.
Lookup Return Use the drop-down arrow to display the list from which you can click to select an item. Your list selection
appears in the field box to the right of the label.
Name Required. Enter a name for this custom attribute so that it has an identifiable textual name to go with the
numeric identifier.
Process
Examples
Custom Attribute Document Maintenance Document
A custom attribute is a data element needed by an institution that is not available out of the box from the application. A
Custom Attribute Document allows you to set up a document that is used for the maintenance of custom attributes that
can be used elsewhere within the KRA system.
Document Layout
The Custom Attribute Document Maintenance Document includes the unique Edit Custom Attribute Document tab in
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Custom Attribute Document Tab
The Edit Custom Attribute Document tab allows you to assign a number that is to be used for unique identification of a
custom attribute, and further, to associate it with an existing document type code. Optional characteristics can be set by
using the optional fields provided.
Field Definition
Custom Attribute ID
Required. Enter or select from the lookup or direct inquiry an existing custom attribute
identification number to associate with this document.
Document Type Code
Required. Enter or select (using the lookup or direct inquiry icon tools) to specify which
document type code is to be used for this custom attribute document.
Required Select the checkbox to make this custom attribute document required, or clear to make it optional.
Type Name Enter text that identifies this unique custom attribute document type.
Active Select to activate this document, or clear to make it not active.
Process
Examples
Deadline Type Maintenance Document
The Deadline Type maintenance document exists to give you a way of creating deadline type codes used in the
development of proposals.
Document Layout
The Deadline Type Maintenance Document includes the unique Edit Deadline Type Codes tab in addition to the standard
tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Deadline Type Codes Tab
The unique Edit Deadline Type Codes tab enables you to create a new reference table record that specifies the code
(abbreviation) and the description (textual name the associated code refers to).
Field Definition
Deadline Type Code
Required. Enter a deadline type code that the system will use for reference and
identification of this deadline type. This may be a single or multiple alphabetic or numeric
character(s).
Description
Required. Enter text that is the commonly-used name of this deadline type.
Process
Examples
Degree Type Maintenance Document
The Degree Type maintenance document exists for the purpose of establishing and maintaining information used for
reference and selection on other KRA documents and screens pertaining to types of degrees held by project personnel.
Document Layout
The Degree Type Maintenance Document includes the unique Edit Degree Type tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Degree Type Tab
The Edit Degree Type tab allows you to enter or maintain an abbreviated code used for quick reference, as well as the
description that is associated with it (typically the full name of the type of degree).
Field Definition
Degree Code Required. Enter the alphanumeric characters that are to serve as the abbreviated version of the name
of this specific, individual degree type that the system will use as the value for reference and
identification.
Description Although not required, a good use for this field would be to explain the acronyms and/or
abbreviations that represent the degree type in the Degree Code for those degrees that are less-
commonly known or used for reference purposes.
Process
Examples
Exemption Type Maintenance Document
One of six categories of exempt research specified by the Common Rule (45 CFR 46.101(b). Categories of research
(primarily educational, behavioral, social science and research involving existing data, medical records, and pathological
specimens) that present little or no risk to the research participants. Research that qualifies for "Exemption from IRB
Review" must meet one of six categories outlined in the Common Rule (e.g. 45 CFR 46.101(b) and should not involve
vulnerable research participants except under unique situations.
Document Layout
The Exemption Type Maintenance Document includes the unique Edit Exemption Type Codes tab in addition to the
standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Exemption Type Codes Tab
The Edit Exemption Type Codes tab displays two required fields and one optional field that let you specify each type of
exemption to be used for reference and selection in the system.
Field Definition
Exemption Type
Required. Enter the code value that uniquely defines this particular type of exemption in the
system for reference and identification. One of six categories of exempt research specified
by the Common Rule (45 CFR 46.101(b).
Exempt #
Required. Enter the alphanumeric characters that serve as the unique number of this
individual exemption. One of six categories of exempt research specified by the Common
Rule (45 CFR 46.101(b).
Detailed Description Enter text that thoroughly explains the purpose and meaning of the exemption type code.
Process
Examples
Institute LA Rate Maintenance Document
LA is an abbreviation for Lab Allocation. The rates associated with F&A facility costs based on a particular type of
lab and its related equipment are recorded for your institution here to aid in applying these costs to a proposal in order to
meet submission requirements for particular types of research work that involves particular types of laboratories. It may
be helpful to think of lab allocation rates as "taxes" that are levied on some project accounts to cover various costs. It is
basically a tax assessed for the usage of certain research space and equipment.
Document Layout
The Institute LA Rates Maintenance Document includes the unique Edit Institute LA Rates tab in addition to the
standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Institute LA Rates Tab
The Edit Institute LA Rates tab is made up of 7 required fields used to maintain each institute LA rate.
Field Definition
Fiscal Year Required. Enter a 4-digit value in yyyy format that is to be associated with this Institute LA Rate.
On/Off Campus Flag Required. Select if you want to require that there be a selectable option for specification of whether or not
this rate is to be used on or off campus. Indicates whether a rate applies to on campus use or off campus
use.
Rate Class Code Required. Enter or select by clicking the lookup or direct inquiry icons the rate class code that is to be
associated with this Institute LA Rate.
Rate Type Code Required. Specify the rate type code by using the lookup or direct inquiry functions or by entering the
code in the field provided. The type of rate that the system applies to specific cost elements (i.e. fringe
benefits, F&A, inflation, etc)
Start Date Required. Enter a date in mm/dd/yyyy format to specify the date the Institute LA Rate is to be instituted
or become effective in the system, or locate and select one by clicking the calendar icon. In the KRA
Unit Number Required. Enter a number for the unit at your institution that is applicable, or select it by using the lookup
or direct inquiry functions.
Rate Required. Enter the numeric rate with a decimal point and hundredths.
Process
Examples
Institute Rate Maintenance Document
The Institute Rate maintenance document is used to create new and maintain existing Institutional rates associated with
the rate type, on/off campus and fiscal year. These table records may be referenced by multiple modules and/or e-docs
within the KRA system.
Document Layout
The Institute Rates Maintenance Document includes the unique Edit Institute Rates tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Institute Rates Tab
The Edit Institute Rates tab has 8 required fields for maintaining institute rates used by your institution in research
administration.
Field Definition
Activity Type Code Required. Enter the code if known or look it up using the icons provided. This is the number in the
KRA system that is associated with the name of a major university function.
Fiscal Year Required. Enter the fiscal year for the accounting period in yyyy format. Identifies the institutional
fiscal year for which a rate is effective.
On/Off Campus Flag Required. Indicates whether a rate applies to on campus use or off campus use.
Rate Class Code Required. Enter the value that uniquely identifies the rate class that is to be associated with the
Institute, or locate and select it by using the lookup or direct inquiry tools.
Rate Type Code Required. The code value associated with the type of rate that the system applies to specific cost
elements (i.e. fringe benefits, F&A, inflation, etc)
Start Date Required. In the KRA budget module, this is the date for which a rate becomes effective.
Unit Number Required. Enter the unique number associated with the unit, or look it up and select it using the
provided tools.
Rate Required. Enter the rate value with a decimal point.
Process
Examples
Investigator Credit Type maintenance document
The Investigator Credit Type screen, which is a maintenance document, but isnt labeled with the words
Maintenance Document at the end like others. Another unique feature is that what would on most maintenance
documents be an Edit tab, instead, is labeled a Specify the Credit Type tab that allows you to enter and select the
detailed data of the reference table entry.
Document Layout
The Investigator Credit Type Maintenance Document includes the unique Specify the Credit Type tab in addition to the
standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Specify the Credit Type Tab
The Specify the Credit Type tab provides you with one required field for creating the numeric code value, and three
additional, optional fields to further define its unique characteristics.
Field Definition
Investigator Credit Type Code Required. This is the Numeric value you want to assign to uniquely identify this particular
credit type in KRA. The value that uniquely identifies this investigator credit type in the
system and serves as an abbreviated reference for the actual name appears in the Description
field.
Is Active Select to make active this credit type in the system, clear to deactivate it and save it for future
use.
Description The text that explains the purpose or meaning of the credit type as it is commonly referred to.
Enter the text that names the credit type as it is known in your institution.
Adds to Hundred Select the checkbox to make this credit type add to hundred, clear to prevent it from adding to
hundred. Check to require line item values add up to 100%.
Process
Examples
Keyword Maintenance Document
The Keyword maintenance document provides a means for maintaining the science keywords used for reference and
selection in proposal preparation. Keyword is a term that describes the discipline of a sponsored project (e.g. sustainable
agriculture, children's literature, etc.). These are shared reference tables that may be used by other modules and/or e-
docs in the system.
Document Layout
The Keyword Maintenance Document includes the unique Edit Science Keywords tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Science Keywords Tab
The Edit Science Keywords tab allows you to specify a single keyword reference table entry at a time by defining the
numeric value and associated textual word.
Field Definition
Keyword Code
Required. A numeric value associated with the term that describes the discipline of a
sponsored project (e.g. sustainable agriculture, children's literature, etc.).
Description
Required. Enter the text that expresses what the science keyword code refers to. A term that
describes the discipline of a sponsored project (e.g. sustainable agriculture, children's
literature, etc.).
Process
Examples
Mail By Maintenance Document
The Mail By maintenance document allows you to establish and maintain Mail By values and associated descriptions for
use in proposal development.
Document Layout
The Mail By Maintenance Document includes the unique Edit Mail Bys tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Mail Bys Tab
The Edit Mail Bys tab enables you to specify a single mail by code with associated description as one reference table
entry per maintenance document.
Field Definition
Mail By
Required. Enter the numeric value that uniquely identifies this individual location
responsible for sending the mailing in the system.?
Description
Required. The textual name that is associated with the Mail By number (for example, OSP
or Department).
Process
Examples
Mail Type Maintenance Document
The Mail Type maintenance document is used to define mail types available for lookup and selection in proposal
development.
Document Layout
The Mail Type Maintenance Document includes the unique Edit Mail Types tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Mail Types Tab
Use the Edit Mail Types tab to create or modify types of mail used in proposal submission.
Field Definition
Mail Type The number that uniquely identifies the method of postal delivery.
Description The textual name for the type of mail (for example, Electronic or Regular).
Examples
Narrative Status Maintenance Document
The Narrative Status maintenance document allows you to create table records for states a narrative can be in as they
relate to proposal development.
Document Layout
The Narrative Status Maintenance Document includes the unique Edit Narrative Status tab in addition to the standard
tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Narrative Status Tab
The Edit Narrative Status tab has two required fields, one for specification of the abbreviated value, and the second for
the associated textual name that describes the value.
Field Definition
Narrative Status Code
Required. Enter the value that uniquely represents the single status in the system that can be
selected for a particular narrative.
Description
Required. The textual representation of this single state that a narrative can be in. The
status name that is commonly used to refer to this status in written or verbal language.
Process
Examples
Narrative Type Maintenance Document
The Narrative Type maintenance document is used to have records available for selection and specification of different
types of narratives to be used in proposal development.
Document Layout
The Narrative Type Maintenance Document includes the unique Edit Narrative Types tab in addition to the standard
tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Narrative Types Tab
The Edit Narrative Types tab is used to enter the five required fields of information necessary to establish each reference
table record entry.
Field Definition
Narrative Type
Required. Enter the numeric value that identifies this particular kind of narrative.
Description
Required. This is the short name of the narrative type that is used for written/verbal
reference. Enter as few words as possible to convey the purpose and meaning of the type.
Any character is allowed, such as underscores.
System Generated
Required. Enter Y for Yes or N for No.?
Allow Multiple
Required. Enter Y for Yes or N for No.?
Narrative Type Group
Required. The group that this narrative type is a member of (for example, P).
Process
Examples
Notice of Opportunity Maintenance Document
The mechanism used to communicate information about the funding opportunity for this project. Examples include
federal solicitations (e.g. RFP, RFA, PA), nonfederal solicitations, unsolicited proposal, verbal request, etc.
Document Layout
The Notice of Opportunity Maintenance Document includes the unique Edit Notice of Opportunity tab in addition to the
standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Notice of Opportunity Tab
The Edit Notice of Opportunity tab is where you create new or edit existing reference table records for each notice of
opportunity, which include the numeric value and the associated textual name used to describe the value.
Field Definition
Required. Enter the alphanumeric value the system will use to reference and uniquely
identify the mechanism used to communicate information about the funding opportunity for
this project.
Description
Required. The familiar way the notice is referred to in speech that uniquely identifies it in as
few words as possible. The mechanism used to communicate information about the funding
opportunity for this project. Examples include federal solicitations (e.g. RFP, RFA, PA),
nonfederal solicitations, unsolicited proposal, verbal request, etc.
Process
Examples
NSF Science Code Maintenance Document
A numeric code that is used by the institution to indicate a field of research activity, as defined by the National Science
Foundation. For example, the NSF science code for Chemical Engineering is 012. These codes are important when an
institution compiles data for the NSF Annual Survey, and for other annual reporting exercises. The NSF is a federal
agency that sponsors fundamental research in science and engineering and also supports science education.
Document Layout
The NSF Code Maintenance Document includes the unique Edit NSF Codes tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit NSF Codes Tab
The Edit NSF Codes tab has two required fields, one for you to enter the abbreviated code value, the other for the full
textual name associated with the code that describes it. Together, these two fields make up the reference table record
used
Field Definition
NSF Science
Code
Required. A numeric code that is used by the institution to indicate a field of research activity, as
defined by the National Science Foundation. For example, the NSF science code for Chemical
Engineering is 012. These codes are important when an institution compiles data for the NSF
Annual Survey, and for other annual reporting exercises. The NSF is a federal agency that sponsors
fundamental research in science and engineering and also supports science education.
Description
Required. The English language version of the code. This should as briefly as possible identify
what the code is, so that its meaning or purpose can easily be discerned from reading the text.
Process
Examples
Object Code Maintenance Document
Use the Object Code maintenance document create and maintain cost elements that are used on proposal development
screens for reference and selection in preparation of research budgets. They allow for specification of expenses by
category.
Document Layout
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Cost Element Tab
The Edit Cost Element tab consists of two required and two optional fields you use to define codes for objects that are
selected as costs in research budgets.
Process
Examples
Organization Maintenance Document
The Organization Maintenance Document contains more information than typical maintenance e-docs. Instead of a
single unique tab, it instead has five. The lookup screen contains many more search criteria fields than most, and
likewise, the result tables display more columns of data than most maintenance e-docs as well. As a result, you must
scroll horizontally in order to view all of the columns, and to get to the Actions column on the far right if you want to
edit or copy an existing document.
Screen Real Estate Issue
Document Layout
The Organization Maintenance Document includes the unique Edit Organization, Organization Type, Organization
Audit, Organization Indirectcost, and Organization Ynq tabs in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Organization Tab
Field Definition
Organization Id Number that uniquely identifies an organization.
Address This is the physical location information for each performing site. The information is maintained in
the Rolodex.
Agency Symbol A number used to symbolically represent an agency that is associated with the organization.
Field Definition
Animal Welfare
Assurance
A value used to specify the assurance of animal welfare referenced by this organization.
Cable Address The address of the associated cable location.
Cage Number A CAGE Code is a five (5) position code that identifies companies doing or wishing to do business
with the Federal Government. The format of the code is the first and fifth position must be numeric.
The second, third and fourth may be any mixture of alpha/numeric excluding I and O. All positions
are non-significant.
Cognizant Auditor The agency the school falls under (usually DHHS or ONR).
Com Gov Entity Code Uniquely identifies the governmental entity associated with this organization.
Congressional District The U.S. Congressional district number of the applicant organizational contact and the performing
organizational contact. Each Congressional district is an area within a state from which a member of
the U.S. House of Representatives is elected. There are 435 U.S. Congressional districts, each with a
unique code.
Contact Address Id Required. Use the lookup to find and select by returning value for specification of a contract address
identification value.
County The county in which the organization is located.
Dodac Number Department of Defense Ammunition Code The DODAC is a nine-position, semi-significant number
(e.g., 1325-f114) consisting of the four-position FSC number, a hyphen, and a four-position DODIC
(Department of Defense Identification code). The last four characters may be one alpha followed by
three numeric positions (e.g., d548), or two alphas followed by two numeric positions (e.g., pa38), or
3 alphas followed by 1 numeric position (e.g., pff1). DLIS does not assign DODACs, containing
"w", "x", "y", or "z" in the seventh position (the second position of the DODIC, e.g., jw40)
Duns Number A D&B D-U-N-S Number is a unique nine-digit sequence recognized as the universal standard
for identifying and keeping track of over 100 million businesses worldwide.
Duns Plus Four Number D-U-N-S Plus Four - The D-U-N-S Plus Four may be necessary if the Jurisdiction has multiple D-U-
N-S numbers.
Federal Employer Id Also known as the Tax ID number or Employer Identification ID (EID); assigned by the IRS.
Human Sub Assurance Also known as the Federalwide Assurance.
Incorporated Date The date in mm/dd/yyyy format in which the organization first became incorporated.
Incorporated In The United State in which the organization is incorporated.
Indirect Cost Rate
Agreement
The approval date of the most recent Indirect Cost Rate Agreement.
Irs Tax Exemption The value that uniquely identifies the tax exemption used by the organization for reporting to the
Internal Revenue Service.
Mass Employee Claim The value used for mass employee claims as it relates to insurance.
Mass Tax Exempt Num The numeric value associated with tax exemption.
Nsf Institutional Code A numeric code that is used by the institution to indicate a field of research activity, as defined by the
National Science Foundation. For example, the NSF science code for Chemical Engineering is 012.
These codes are important when an institution compiles data for the NSF Annual Survey, and for
other annual reporting exercises. The NSF is a federal agency that sponsors fundamental research in
science and engineering and also supports science education.
Number Of Employees The numeric value specifying how many employees the organization has.
Onr Resident Rep Text box field for entry and maintenance of the Onr Resident Rep record value.
Organization Name Required. The official, full, textual name of the organization as it is commonly known or referred to
as.
PHS Account This number (the Tax ID with a PHS-assigned prefix (1) and suffix) is used on proposals to PHS
agencies, and is an identifier for Letter of Credit payments.
Science Misconduct The date of the most recent misconduct in science review.
Field Definition
Compl Date
Telex Number The number used for Telex transmission or communication at the organization.
Vendor Code The numeric value that uniquely represents this organization as a vendor.
Organization Type Tab
The Organization Type tab allows for the addition of a new or maintenance of an existing code used in the system as an
abbreviated form of the textual name of the type of organization.
Field Definition
Organization Type Code Required. Enter the value that uniquely identifies this organization type in the system, or search for
and select it using the lookup or direct inquiry tools as desire. When selected, click the add button to
add it as a line item.
Add Click this button to add the type code to the organization type.
Organization Audit Tab
The Organization Audit tab requires the entry of the applicable fiscal year and optional audit information associated with
the organization.
Field Definition
Fiscal Year Required. Identifies the institutional fiscal year for which a rate is effective.
Audit Accepted Check the checkbox to indicate the audit has been accepted, otherwise clear.
Audit Comment Type to enter textual commentary related to the organization audit.
Add Adds the data you entered in the fields on the Organization Audit tab as an individual record in the
database table (displayed as a line item beneath the entry fields?).
Organization Indirectcost Tab
The Organization Indirect Cost tab contains fields that enable you to specify the indirect cost number that is to be
associated with this organization.
Field Definition
Idc Number Required. An abbreviation for In direct cost?
Applicable Indirectcost
Rate
Enter the rate with decimal point as appropriate.
End Date Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on the
calendar icon .
Idc Comment Text box for entry of comments related to the indirect cost for this organization.
Idc Rate Type Code Enter the code if known for the type of Idc rate.
Requested Date Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on the
calendar icon .
Start Date Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on the
calendar icon . In the KRA budget module, this is the date for which a rate becomes effective.
add Action button used to add the information entered on the tab fields to the reference table record.
Organization Ynq Tab
The Organization Ynq tab facilitates the entry or modification of questions associated with the organization the answers
to which are either yes or no.
Field Definition
Question The actual text of the question itself.
Question Id The alphanumeric value used as an identifier of this particular question in the system.
Answer Required. Yes or No options from which to select (radio buttons).
Process
Example
Organization Type Maintenance Document
The Organization Type maintenance document allows you to assign an abbreviated value to the textual name of the type
of organization for reference and selection use in the system.
Document Layout
The Organization Type List Maintenance Document includes the unique Edit Organization Type List tab in addition to
the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Organization Type List Tab
Use the Edit Organization Type List tab to create new or edit existing values and descriptions that define organization
type records in reference tables.
Field Definition
Organization Type Code
Required. Enter the shortened version of the organization type name, a value used to
reference and identify it uniquely in the system.
Description
Required. Explain what the organization type is using words or phrases you typically use to
refer to this in writing or speech. This unique, familiar name is what will correspond to the
code value.
Process
Examples
Person Degree Maintenance Document
The Person Degree maintenance document is used to edit degree details for individual people in KRA.
Document Layout
The Person Degree Maintenance Document includes the unique Edit Person Degree tab in addition to the standard tabs.
This maintenance document includes the following features that are common to most maintenance documents in KRA:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Person Degree Tab
The Edit Person Degree tab gives you a way to specify details of a degree held by a particular person, such as its
description (required) and school from which it was obtained (optional).
Field Definition
Person Id Required. Enter the identification number that uniquely identifies the person in the system, or search for
and select it by using the lookup or direct inquiry tools.
Degree Description Required. Type the text that explains the title of the degree.
Degree Type Required. Select from the list, lookup, or direct inquiry the type of degree.
Graduation Year Enter the yyyy format.
Field of Study Type the primary field the person studied while obtaining the degree.
Specialization Type the textual name of the academic subject matter area the person specialized in while obtaining the
degree.
School The name of the institution where the degree was issued.
School Id The short name of the institution (abbreviated)
School Id Code The number associated with the institution where the degree was issued.
Process
Person Document Type Maintenance Document
The Person Document Type maintenance document is an e-doc you use to establish a new or maintain an existing
reference table record that associates a person with a type of document. The record includes a value and textual
description of the number.
Document Layout
The Person Document Type Maintenance Document includes the unique Edit Person Document Type tab in addition to
the standard tabs.
This maintenance document includes the following features that are common to many maintenance documents in KRA:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Person Document Type Tab
The Edit Person Document Type tab requires population of two fields that define an entry in the reference table, one a
numeric value, and the other a textual description of the associated value.
Field Definition
Person Document Type
Code
Required. Enter the value that will be used to represent this single piece of information
when referenced.
Description
Required. Enter the familiar name of the person document type you would use to refer to it
verbally or in writing.
Process
Examples
Person-Role Maintenance Document
The Person-Role maintenance document is what you use to assign a unit to a role so that the information is automatically
populated into all new proposals created.
The Person-Role Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Person-Role Tab
The Edit Person-Role tab requires you provide valid values for 5 fields that make up a reference table record used in
proposal development.
Field Description
Person Id Required. Type the value if known in the box, otherwise, search for and select it and populate
the box automatically by using either the lookup or direct inquiry functions to
specify the value that uniquely identifies the person.
Role Id Required. Type the value if known in the box, otherwise, search for and select it and populate
specify the value that uniquely identifies the role.
Unit Number Required. Type the value if known in the box, otherwise, search for and select it and populate
specify the numeric value that uniquely represents the institutional unit.
Descend
Required. Click within the checkbox to select the item to make the person-role record
descend. A green check mark appears within the checkbox to indicate the item is selected.
Click within the checkbox again to clear the mark and deselect the item.
Active
Required. Click within the checkbox to select the item to make it active for use in the
system. A green check mark appears within the checkbox to indicate the item is selected.
Click within the checkbox again to clear the mark and deselect the item.
Examples
Person Table Editable Columns Maintenance Document
The Person Editable Field maintenance document is used to specify the field name used as a column in the person table
that may be edited. When you want to maintain additional information about a person such as unique contact
information this allows for flexible customization of what is standard.
Document Layout
The Person Editable Field Maintenance Document includes the unique Edit Table Person Field tab in addition to the
standard tabs.
This maintenance document includes the following features common to many maintenance documents in KRA:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Specify the Field Name Tab
The Specify the Field Name tab allows you to do just that specify the field name by selecting from the drop-down list
(required) and indicating whether it is to be active or not.
Field Definition
Field Name Required. Specify the name of the field by selecting one from the drop-down list.
Active Select the check box if the field is to be active. Clear the check box if it is inactive.
Process
Examples
Proposal Columns To Alter Maintenance Document
The Proposal Columns To Alter maintenance document allows you to establish and maintain table records for reference
and selection on proposal documents in the form of columns that may be altered. This flexibility allows for
customization of the proposal development document to suit unique functional business requirements.
The Proposal Columns To Alter Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Proposal Columns To Alter Tab
The Proposal Columns To Alter tab has 4 required fields and three optional fields you use to specify proposal columns
that can be altered.
Field Description
Column Name Required. The unique identifier of the proposal column.
Column Label Required. The text that will serve as the user interface label next to the column.
Data Length Enter a numeric value for the maximum amount of characters allowed to be entered.
Data Type
Required. Click the down arrow to display the list and click on an item in the list to highlight and
select it to populate the box with your selection. String, Date, Number.
Has Lookup
Required. Click within the checkbox to select the item. A green check mark appears within the
checkbox to indicate the item is selected. Click within the checkbox again to clear the mark and deselect
the item.
Lookup Argument
populate the box with your selection.
Lookup Return
populate the box with your selection. Select.
Examples
Proposal Type Maintenance Document
Use the Proposal Type maintenance document to establish or maintain unique reference table records for types of
proposals.
Some of these items, like Proposal Type, map to Grants.gov submissions, so you should edit with caution.
Document Layout
The Proposal Type Maintenance Document includes the unique Edit Proposal Type Codes tab in addition to the standard
tabs.
This maintenance document includes the following elements that are common to many maintenance e-docs in KRA:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Proposal Type Codes Tab
Populate the two required fields to create or update the record, including a numeric value and its associated textual
description.
Field Definition
Proposal Type Code
Required. Enter the value the system will use to refer to and identify this individual
proposal type.
Description
Required. Enter the text for the word, words, or phrase you use to refer to this proposal type
verbally or in writing. The familiar name or title that corresponds to the unique value
representation.
Process
Examples
Questions Maintenance Document
The Questions menu group link accesses the Ynq (a.k.a. Yes/No Questions) maintenance document, which allows you to
add new or modify existing certification questions for e-docs as business rules at your institution dictate as being
necessary.
Document Layout
The Ynq Maintenance Document includes the unique Edit Ynq and Ynq Explanation tabs in addition to the standard
tabs.
This maintenance document includes the following elements that are commonly found on maintenance documents in
KRA:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Ynq Tab
The Edit Ynq tab is where you specify the identifying information about the question as well as the text of the question
itself.
Field Definition
Question Id Required. The number the system uses to record the individual question record.
Applies To Required. Select from the list the module or document the question applies to.
Status Required. Click to select the radio button option to indicate the appropriate state of the question.
Effective Date Required. Enter the date in mm/dd/yyyy format the question is to become effective or use the
calendar tool to select it.
Question Required. Type the text of the question followed by a question mark.
Valid Answers Required. Select a radio button option for the radio button option (s) you want to be displayed for
you to select from as a valid answer to the question.
Explanation Required For Select an item from the list.
Date Required For Select an item from the list.
Group Name Enter the textual, familiar name of the group that is to be associated with the question.?
Ynq Explanation Tab
The Ynq Explanation tab is what you use to explain the rationale or necessity of requiring the question be answered.
Field Description
Explanation A classification of question related to explanation of the background information necessary to describe the
purpose of the question being asked.
Policy The institutional policy statement(s) that require the question be asked.
Regulation The description of the applicable regulation as it relates to the question.
Process
Examples
Rate Class Maintenance Document
The Rate Class maintenance document exists to facilitate the establishment and updating of rate classes that are to be
made available for lookup and selection from within the proposal development module, more specifically as related to
research project budget preparation.
Document Layout
The Rate Class Maintenance Document includes the unique Edit Rate Class tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Rate Class Tab
The Edit Rate Class tab is comprised of three required fields that collectively make up a single reference table record.
Field Definition
Rate Class Code
Required. The numeric value that the system uses to reference this rate class.
Rate Class Type
Required. Enter the alphanumeric type of rate class this code is a part of, or select it from the
lookup or direct inquiry features.
Description
Required. The name you use to refer to the rate class verbally or in writing that also uniquely
identifies it from others. Enter text as appropriate (any character or spacing is acceptable).
Process
Examples
Rate Class Type Maintenance Document
This maintenance document is available for defining different types of rate classes to be used in proposal and budget
development.
Document Layout
The Rate Class Type Maintenance Document includes the unique Edit Rate Class Type tab in addition to the standard
tabs.
Included are the following standard maintenance document features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Rate Class Types Tab
Field Definition
Rate Class Type
Required. Enter the alphanumeric type of rate class this code is a part of, or select it from the
lookup or direct inquiry features.
Description
Required. The actual familiar name or title of the rate class type that will correspond to the code
value.
Prefix Activity Type
Required. Check to add this rate class type as a prefix to the associated activity type, or clear to
not prefix the activity type. Activity Type is a major institution function.
Sort Id A numeric value used to identify the way in which the rate class type is sorted (sequential order in which it
is displayed in a list) in a database or user interface that displays data in a table format.
Process
Examples
Rate Type Maintenance Document
The type of rate that the system applies to specific cost elements (i.e. fringe benefits, F&A, inflation, etc).
Document Layout
The Rate Type Maintenance Document includes the unique Edit Rate Type tab in addition to the standard tabs.
Included are the following standard maintenance document features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Rate Type Tab
Use the Edit Rate Type tab to create new or edit existing rate class codes by populating or changing the following three
required fields.
Field Definition
Rate Class Code
Required. The numeric value that the system uses to reference this rate class that is associated with
this unique rate type.
Rate Type Code
Required. The value that is associated with the type of rate that the system applies to specific cost
elements (i.e. fringe benefits, F&A, inflation, etc)
Description
Required. Enter text to describe this individual rate type (could be a single word, several words
separated by spaces, a phrase, or number/word combinations that can have most characters, such as
slashes and parentheses). The type of rate that the system applies to specific cost elements (i.e.
fringe benefits, F&A, inflation, etc)
Process
Examples
Role Maintenance Document
The Role Maintenance document enables creation and updating of reference table records of roles users can have for the
completion of various electronic documents in the system, such as proposal preparation.
The Role Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Tabs
The Role maintenance document includes two unique tabs: Edit Role and Edit Role-Permission.
The Edit Role tab allows for specification of a Role Name, Type and Description.
The Edit Role-Permission tab allows for association of Permissions with the specified role.
Process
Examples
Role-Permission Maintenance Document
The Role-Permission maintenance document is a system administration e-doc that allows you to link roles with
permissions as they relate to proposal and budget development.
The Role-Permission Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Role-Permission Tab
The Role-Permission maintenance document contains one unique tab, the Edit Role-Permission tab.
Field Description
Role Id Required. Type the value if known in the box, otherwise, search for and select it and populate the box
automatically by using either the lookup or direct inquiry functions for the proposal development
role.
Permission Id Required. Type the value if known in the box, otherwise, search for and select it and populate the box
automatically by using either the lookup or direct inquiry functions for the permission you want to
associate with the role.
Active
Select to make active, uncheck to deactivate. Click within the checkbox to select the item. A green check
mark appears within the checkbox to indicate the item is selected. Click within the checkbox again to clear the
mark and deselect the item.
Process
Select from the following Roles:
Select from the following Permissions:
Examples
Rolodex Maintenance Document
The Rolodex Maintenance Document has an access link that differs in name from either the lookup or the document. It
is accessed from the Non-Employee Lookup link on the Quicklinks menu group of either the Unit or Central Admin
menus, and then via the [create new] button on the Rolodex Lookup screen.
Document Layout
The Rolodex Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Standard
Maintenance E-Doc
Component
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Rolodex Tab
The Edit Rolodex tab is where you can specify detailed contact information associated with non-employees.
Field Definition
Rolodex Id
Required. The unique number assigned to this individual persons contact information
record.
Address Line 1
This is the physical location information for each performing site. The information is
maintained in the Rolodex.
Address Line 2
Enter the second line of the non-employees address.
Address Line 3
Enter the third line of the non-employees address.
Field Definition
City
Enter the city for the non-employees address.
Comments
Optional text you want to record as miscellaneous notes about the individual.
Country Code
The country code associated with the mailing address.
Country
The full text name of the country.
Delete Flag
Provide the ability to delete this record.
Email Address
The electronic mail address (must include an @ symbol)
Fax Number
Enter a ten-digit fax number with the area code first.
First Name
Type the persons first name, capitalizing the first letter.
Last Name
Type the persons last name, capitalizing the first letter.
Middle Name
Type the persons middle name, not initial.
Organization
Required. The organization the person is associated with (employer or business).
Owned By Unit
Required. Enter your institutions unit that is responsible for the non-employee.
Phone Number
Area code first, followed by 7-digit number.
Postal Code
Also known as the zip code associated with the business mailing address.
Prefix
Enter a prefix for the persons name, for example, Ms.
Sponsor Address Flag
Required. Indicates whether this is a sponsor address or not.
Sponsor Code
The abbreviated value used by the system to uniquely identify this particular sponsor.
State
The state in which the non-employees organization is located.
Suffix
The suffix to the persons name, for example, esq. for a lawyer.
Title
Any official job title or organization title used when referring to this individual.
S2S Revision Type Maintenance Document
A change in a sponsor's financial obligation or contingent liability of an existing award. For example, the NIH uses the
following revision types: (1) Increase award (2) Decrease award (3) Increase duration (4) Decrease duration and (5)
Other.
Document Layout
The S2S Revision Type Maintenance Document includes the unique Edit S2S Revision Type tab in addition to the
standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit S2S Revision Type Tab
Use the Edit tab to specify the unique details of the individual reference table record (by populating the two required
fields with valid information).
Field Definition
S2S Revision Type
Required. Click within a circle to place a green dot within in to indicate your selection of a radio
button option. A change in a sponsor's financial obligation or contingent liability of an existing
award. For example, the NIH uses the following revision types: (1) Increase award (2) Decrease
award (3) Increase duration (4) Decrease duration and (5) Other.
Description
Required. Enter the familiar textual name for this type of S2S revision that uniquely represents a
separated by spaces, or a short phrase).
Process
Examples
S2S Submission Type Maintenance Document
The type of grant application package/proposal submitted. For example, types of submissions include: (1) Pre-
application (2) Application (3) Changed/Corrected Application
Document Layout
The Submission Type Lookup screen has a search criteria section and a results table.
Field Definition
Submission Type The type of grant application package/proposal submitted. For example, types of submissions include: (1)
Pre-application (2) Application (3) Changed/Corrected Application
Description The type of grant application package/proposal submitted. For example, types of submissions include: (1)
Pre-application (2) Application (3) Changed/Corrected Application
Search button Retrieves and displays results of your query in table format below the search criteria area of the lookup
screen.
Examples
NSF Science Code Maintenance Document
The NSF Science Code menu link accesses the NSF Science Code Lookup screen with a create new button that when
clicked, accesses the NSF Code Maintenance Document. A numeric code that is used by the institution to indicate a
field of research activity, as defined by the National Science Foundation. For example, the NSF science code for
Chemical Engineering is 012. These codes are important when an institution compiles data for the NSF Annual Survey,
and for other annual reporting exercises. The NSF is a federal agency that sponsors fundamental research in science and
engineering and also supports science education.
Document Layout
The NSF Science Code Maintenance Document includes the unique Edit NSF Codes tab in addition to the standard tabs.
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit NSF Codes Tab
Use the Edit NSF Codes tab to specify both the abbreviated value, and the associated text to describe it. Together, the
two required fields make up one record.
Field Definition
NSF Science Code Required. A numeric code that is used by the institution to indicate a field of research activity, as defined by
Field Definition
the National Science Foundation.
Description Required. The textual name associated with the numeric code value. For example, the NSF science code
012 stands for Chemical Engineering. These codes are important when an institution compiles data for the
NSF Annual Survey, and for other annual reporting exercises. The NSF is a federal agency that sponsors
fundamental research in science and engineering and also supports science education.
Process
Examples
Special Review Maintenance Document
proposals that include the use of human participants in research).
Document Layout
The Special Review Maintenance Document includes the unique Edit Special Review tab in addition to the standard tabs.
This maintenance document includes the following elements that are common to most maintenance documents:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Special Review Codes Tab
This is the crucial tab containing the two fields that are required for establishment of a reference table record. The
abbreviated code and the textual name associated with it uniquely define the special review entry.
Field Definition
Special Review
Code
Required. Enter the code to refer to and uniquely identify a grant proposal that requires
additional review by an institutional committee or official (e.g. proposals that include the use of
human participants in research).
Description
Required. Enter the familiar textual name for this special review code that uniquely represents a
separated by spaces, or a short phrase). It may contain most characters, such as dashes or
parentheses. A special review refers to a grant proposal that requires additional review by an
institutional committee or official (e.g. proposals that include the use of human participants in
research).
Process
Examples
Special Review Approval Type Maintenance Document
Use this document to maintain types of special review approvals that may be shared my multiple modules and/or e-docs
within KRA. A special review refers to a grant proposal that requires additional review by an institutional committee or
official (for example, proposals that include the use of human participants in research).
Document Layout
The Special Review Approval Type Maintenance Document includes the unique Edit Approval Type Codes tab in
This document includes the following features that are common to many maintenance documents in KRA:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Special Review Approval Type Codes
Use the Edit Special Review Approval Type Codes tab to specify the value and the text required to uniquely identify and
establish a reference table record.
Field Definition
Approval Type Code Required. The unique number assigned to this specific approval type in the system.
Description Required. Enter the familiar textual name for this approval type code that uniquely represents a
summarized explanation of its meaning and/or purpose (for example, a title, several words separated
by spaces, or a short phrase).
Process
Examples
Sponsor Maintenance Document
The Sponsor Maintenance Document has the unique Edit Sponsor Tab.
The Sponsor Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Sponsor Tab
Field Definition
Sponsor Code
Required. Code the uniquely identifies the sponsor.
Acronym
Familiar acronym the sponsor is known by, such as NIH or NASA.
Audit Report Sent For Fy
Enter the fiscal year in mm/dd/yyyy format for which the audit report was sent.
Cage Number
Commercial and Government Entity code is an unique identifier assigned to suppliers to
government agencies and organizations used as a standard to identify a given facility at a
specific location.
Country Code
Select the country from the drop-down list as appropriate.
Dodac Number
Department of Defense Ammunition Code.
Dun And Bradstreet
Number
Also known as DUNS, this is a unique nine-digit sequence used to identify and track a
business.
Duns Plus Four Number
The Dun And Bradstreet Number plus the four-digit number from the Central Contractor
Registration database.
Owned By Unit
Required.
Postal Code
Also known as the ZIP code in the United States.
Rolodex Id
Required. Code number that uniquely identifies the non-employee.
Sponsor Name
Required.
Sponsor Type Code
Required. Use the drop-down list to locate and select.
State
State within the United States of America.
Create User
Required.
Process
Examples
Sponsor Forms Maintenance Document
The Sponsor Forms Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Sponsor Forms Tab
Use the Edit SponsorForms tab to create or maintain a reference table record by specifying the following three required
fields of information:
Field Description
Package Name Required. Enter the alphanumeric text used to refer to the package (may be a familiar abbreviation).
Package Number Required. Enter the numeric value representing the package.
Sponsor Code Required. Type the value if known in the box, otherwise, search for and select it and populate the box
automatically by using either the lookup or direct inquiry functions to specify the number
associated with a particular sponsor.
Process
Examples
Sponsor Form Templates Maintenance Document
The Sponsor Form Templates maintenance document allows for the creation and updating of templates for sponsor forms
that are required for proposal submission.
The Sponsor Form Templates Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Sponsor Form Templates Tab
Edit the reference table record by specifying the four required fields on the Edit SponsorFormTemplates tab and using
the Browse feature to upload and include the form itself in the form of an attachment.
Field Definition
Package Number Required. Type the value if known in the box, otherwise, search for and select it and populate the box
Page Description Required. Type (or paste from virtual clipboard) to enter text in the box as necessary to describe the page.
Page Number Required. Enter the numeral used to mark the relevant sequential page within the form template.
Sponsor Code Required. Type the value if known in the box, otherwise, search for and select it and populate the box
Attachment Browse for and attach the form template document using your computers File Upload functionality (or
operating system equivalent).
Process
Examples
Sponsor Type Maintenance Document
This e-doc allows you to maintain reference table records for types of sponsors that are typically available for receiving
research project proposal submissions.
Document Layout
The Sponsor Type Maintenance Document includes the unique Edit Sponsor Types tab in addition to the standard tabs.
Included in this e-doc are the following features that are common to many maintenance e-docs in KRA:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Sponsor Types Tab
Use the Edit tab to uniquely identify sponsor types by entering a value and textual name in the two required fields.
Field Definition
Sponsor Type
Required. A value that is used for reference table storage and retrieval to uniquely identify this single
type of sponsor.
Description
Required. Enter the familiar textual name for this type of sponsor that uniquely represents a
summarized explanation of its meaning and/or purpose (for example, a title, several words separated
by spaces, or a short phrase).
Process
Examples
State Maintenance Document
The State maintenance document is what youll use in case there are changes to the names or numbers of states in the
United States of America, or if your institutions business rules are such that it renders some states as unnecessary
options from which to select for research administration usage.
Document Layout
The State Maintenance Document includes the unique Edit State tab in addition to the standard tabs.
It includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit State Tab
The Edit State tab actually allows you to modify the following three fields of information should such a rare need arise,
so use with caution:
Field Definition
Country
Code
Required. Abbreviation or acronym for the country of the world. Type the value if known in the box, otherwise,
search for and select it and populate the box automatically by using either the lookup or direct inquiry
functions.
State Code
Required. The U.S.A. State abbreviation (2 capital letters).
Description
Required. Enter the textual name of the state, capitalizing the first letter.
Process
Examples
TBN Person Maintenance Document
The TBN (To Be Named) Person maintenance document allows for the use of the employee table lookup and
button as necessary to specify positions to be hired or identified after the award is made.
Document Layout
The To Be Named Persons Lookup has a search criteria section and a result table on the screen with a create new button.
Field Definition
TBN Id To Be Named Identification number for the person.
Person Name The name of the type of person that will be sought to perform a particular kind of work based on an area of
expertise (job or field title) for this generic research project work.
Job Code Type the value if known in the box, otherwise, search for and select it and populate the box automatically by
using either the lookup or direct inquiry functions to specify the Human Resources position identifier
directly associated with the individual named in the Person column.
Examples
Unit Administrator Maintenance Document
Use the Unit Administrator maintenance document to connect a person with a unit within your institution.
The Unit Administrator Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Unit Administrator Tab
Use the Edit tab to specify the following three required fields that collectively make up a reference table record:
Field Definition
Unit Administrator Type
Code
Required. Type the value if known in the box, otherwise, search for and select it and populate the
box automatically by using either the lookup or direct inquiry functions.
Person Id Required. Type the value if known in the box, otherwise, search for and select it and populate the
box automatically by using either the lookup or direct inquiry functions.
Unit Number Required. The abbreviated short name that uniquely represents this particular unit in the system.
Process
Examples
Unit Maintenance Document
The Unit Maintenance Document has the unique Edit Unit tab, in addition to the standard maintenance document tabs.
The Unit Maintenance document includes the following common features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Unit Tab
Use to uniquely identify a unit within your institution, and subsequently maintain it as needs arise.
Field Definition
Unit Number Required. The abbreviated short name that uniquely represents this particular unit in the system.
Parent Unit Number Required. The number of the unit that this unit is a child of in the hierarchy.
Organization Id Required. The identification number of the larger organization this unit is a part of.
Unit Name Required. The textual, familiar title of the unit.
Process
Examples
Unit Hierarchy
The Unit Hierarchy screen serves as the basis for much of the functionality found in KRA. Setting up the unit hierarchy
correctly for the institution is essential for the proper functioning of proposal routing and submission, applying the
appropriate rates to a budget, associating awards, protocols and proposals to the correct unit, and associating users and
roles to the appropriate unit(s).
The system actually groups units into a hierarchical structure so that a department can be grouped under a college/school,
which can then be grouped under a campus, which will all be under the parent unit (the Institution.) In addition, the
system allows each unit to set its own rates (i.e. F&A rates, employee benefits, etc.) which trickle down to all applicable
child units.
The Unit Hierarchy is critical to the system because it is here where users are granted roles/rights, delegates can be
assigned, rates are established, routing rules and maps are set up, and lab allocation rates are assigned. Quite simply, the
unit hierarchy is the backbone of the system.
Button Definition
Click the plus button to expand/show the tree branches in the hierarchy.
Click the minus button to collapse/hide the units from being displayed.
Takes you to the Unit Maintenance Document, edit mode (w/ Old & New column sections in Edit tab).
Unit names can be changed after they have been added into the unit hierarchy. All pending
documents will take on the new name; the former name will still be present on any fully executed
(fully approved/submitted) documents.
Takes you to Person Lookup search result screen that allows you to click edit link for Person Maintenance
Document.
Takes you to Institute LA Rates Lookup search result screen that allows you to click edit link for Institute LA
Rates Maintenance Document.
Takes you to the Institute Rates Inquiry and Maintenance.
Copies the current Unit Maintenance Document to a new document number, with Original and New Copy
column sections in the Edit Unit tab.
Valid Calculation Type Maintenance Document
The Valid Calculation Type maintenance document allows for the establishment and subsequent maintenance of valid
calculation types that are used in budgets associated with research project proposals.
Document Layout
The Valid Calc Types Maintenance Document includes the unique Edit Valid Calc Types tab in addition to the standard
tabs.
Common to many maintenance documents, this one includes the following standard features:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Valid Calc Types Tab
The Edit tab is where you specify the valid calc type record by specifying valid information in the following three
required and three optional fields:
Field Definition
Calc Type Id Required. Uniquely-assigned identification number for this calculation type
Dependent Seq Number Required. The number used for the ordering of the calc type within sorted lists and data retrieval.
Alphanumeric.
Rate Class Type Required. Type the value if known in the box, otherwise, search for and select it to populate the box
automatically by using either the lookup or direct inquiry tools.
Dependent Rate Class
Type
The value that represents the rate class type that is dependent on this valid calc type
Rate Class Code The value for the rate class that is to be associated with this valid calc type.
Rate Type Code The value associated with the type of rate that the system applies to specific cost elements (i.e. fringe
Process
Examples
Valid Cost Element Rate Type Maintenance Document
The Valid Cost Element Rate Type maintenance document maintains reference table records used in budgets associated
with research project proposals.
Document Layout
The Valid Cost Element Rate Types Maintenance Document includes the unique Edit Valid Cost Element Rate Types
tab in addition to the standard tabs.
The following standard features are included in this maintenance document:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Valid Cost Element Rate Types Tab
Three required fields comprise the Edit Valid Cost Element Rate Types tab, which is used to specify each particular type
of cost element rate.
Field Definition
Cost Element
Required. The cost element or object code that you are associating with this valid rate type.
Rate Class Code
Required. The numeric value that serves as the abbreviated name to identify this individual rate
class.
Rate Type Code
Required. The code for the type of rate that the system applies to specific cost elements (i.e. fringe
Process
Examples
Valid Special Review Approval Maintenance Document
Document Layout
The Valid Special Review Approval Maintenance Document includes the unique Edit Valid Special Review Approval
tab in addition to the standard tabs.
Included are the following features that are common to many KRA maintenance documents:
Standard
Maintenance E-Doc
Component
Document Header
Overview.
Tab
Overview.
Overview.
Route Log Tab
Overview.
Action Buttons
Edit Valid Special Review Approval Tab
Use the two required fields and optional checkboxes to maintain an individual reference table record for shared KRA
use.
Field Definition
Approval Type Code Required. The abbreviated value that serves as a short name by which the system references this
particular type of approval.
Special Review Code Required. The code that uniquely identifies and refers to a particular grant proposal that requires
additional review by an institutional committee or official (e.g. proposals that include the use of
human participants in research).
Application Date Flag The flag the system uses to set this information fields availability in the user interface for user input.
Approval Date Flag Selects the specification of the approval date as a requirement.
Protocol Number Flag Ensures the protocol number will be a field where the user has the ability to select it to activate or
make it inactive.
Exempt Number Flag One of six categories of exempt research specified by the Common Rule (45 CFR 46.101(b).
Process
Examples
Kuali Research Administration v.1.0 User Guide Kuali Enterprise Workflow 353
Kuali Enterprise Workflow
Kuali Enterprise Workflow (KEW) is a general-purpose, content-based electronic routing infrastructure or workflow
engine. It is primarily used to automate the routing of electronic documents (e-docs) to individuals and workgroups for
approval, although it can also be used to orchestrate complex processes between business components and applications.
Approval routing is based on institutional or departmental business rules and policies.
Through the use of a centralized workflow engine, you can access and search for many types of e-docs from various
functional areas through a single interface via your Action List and Doc Search. The Route Log allows you to
follow the progress of given documents through the approval process. Routing Reports allow you to view the
projected routing of a document with a particular set of data or attributes.
For less detailed information that provides condensed procedures for basic e-doc routing actions, see Common E-
Doc Operations in KRA Overview. For more detailed technical information about KEW, see
https://test.kuali.org/confluence/display/KULRICE/KEW+Technical+Guide in the Kuali Rice wiki.
Route Levels
Documents route by progressing through a series of route levels. KRA e-docs support both pre-established Workflow
routing and Ad hoc routing.
Figure 147 Workflow routes a document by matching attributes of a transaction to existing rules.
354 Kuali Enterprise Workflow Kuali Research Administration v.1.0 User Guide
Workflow Routing
In the Workflow routing, a documents type (for example, Proposal) determines what route levels it progresses through,
for example:
OSP Initial: When the Initiator is not the Principal Investigator, the Office of Sponsored Projects approves
first.
Proposal Persons: The PI s and Co-PI s for each participating department may approve in parallel with each
other.
Unit: One approval request is sent to each participating unit (also may occur in parallel and may include
approvals at the Dean, College or Department levels).
OSP Office: The Office of Sponsored Projects has the final approval on the route prior to disposition actions
(such as posting to the General Ledger) or external submissions (such as to Grants.gov).
Custom: Custom approval routing to individuals or workgroups can be established by each organization based
on criteria such as document type, transactional attributes, or unique organizational hierarchies. Special
conditions that might trigger additional administrative approval route levels may be required, and this type of
routing is very flexible and can be customized to be as simple or complex as needed.
Ad Hoc Routing
Ad hoc routing allows a document Initiator or Approver to add additional individuals or workgroups to the routing of a
specific document. Ad hoc Approvers inserted into the routing interrupt the regular routing process. For example, when a
user initiates a Proposal document and ad-hoc routes it to his or her supervisor for approval, it routes to the supervisor
before it initially routes to the OSP.
Ad hoc Acknowledge and FYI routing do not interrupt the regular routing process. Documents with these types of ad
hoc routing still pending can be processed after all other approvals are obtained. They are not held for the
acknowledgement to take place or for the FYI to be cleared.
To add an Ad hoc recipient in the Ad Hoc Recipients tab:
1. Select an action from the Action Requested list (for example, APPROVE).
2. Enter a User ID in the Person input box or a Workgroup ID in the
Workgroup input box, or use the lookup icon to select the appropriate user or
workgroup name as desired.
Figure - Ad-hoc route to a workgroup
3. Click add. The add button verifies that the User ID or Workgroup ID that
you have entered for routing is valid.
Repeat as necessary until all desired people and workgroups have been
added. After a successful addition, the line item appears with a delete button
that can be used as necessary.
4. Click submit.
When you complete the Ad Hoc Recipient tab and submit the document,
the route node shows Adhoc routing and the workflow Status changes to
ENROUTE.
Figure - The Pending Action Requests tab in the Route Log shows the
requested action in the Action column and the user/workgroup IDs in the
Requested Of column.
When you review the Route Log immediately after submitting a
document, you may not see the Pending Action Requests tab within the
Route Log. This is because KRA has not yet received the routing information
from Workflow. In this case, wait for a few seconds and click the Refresh
link at the top of the tab to refresh the content displayed. You may need to
repeat this process a few times until the information appears in the Pending
Action Requests tab.
Viewing Route Levels
The Rule QuickLinks feature allows you to see which route levels are associated with each individual document type, as
well as the ability to drill down into rule details associated with each route level.
To view document route levels and rule details:
1. Click the Rule QuickLinks link from the Workflow menu group on either the Unit or Central
Admin menus.
Tabbed sections appear for each document type:
2. Click show to expand the display for each document.
The document routes through the levels shown in the order from top to bottom:
3. Click the Search link to the right of a route level to view additional details about the types of
routing rules established at a particular route level.
A Rule Lookup screen appears in a new browser window:
4. Specify criteria as desired from the lookup screen and click the search button to retrieve
results.
The lookup results display the route level rule details in the search result table format:
5. Click the report link from the Actions column of the rule lookup result table to view the rule
information.
The rule details are displayed in a tab with General Info and Responsibility sections:
Routing Rules
When a document routes through a particular route level it is evaluated against the rules that exist at that level. A rule
acts like a trigger; if the criteria are met, an action request is sent to a particular user (or group of users).
Sometimes rules are established centrally. Rules may also be established by end-users. Regardless of who adds a
particular rule, the process is the same.
Rules are added by creating a new Rule document. This document must also route and be approved, just like any other
document.
As mentioned in the previous Viewing Route Levels topic, you can use the Search link on the Rules QuickLinks screen
to search for rules for a particular document and at a given level.
You can view the details of the rule that caused the document to route to a certain person or workgroup from the Route
Log. To find this information, click show next to the Action Request in the Route Log.
Route Log
The Route Log tab displays the workflow status details. The Route Log is broken into four tabs: the Document ID,
Actions Taken, Pending Action Requests, and Future Action Request tabs.
Document Id tab
The Route Log tab displays the workflow status details of the document. The fields on the Document Id section of the
Route Log tab are display-only. However, both the Document Type and Initiator field values are displayed as underlined
text to show that you are able to click on them to drill down to more detail about each of them. All fields appearing in
the right column are date fields.
Figure 148 Workflow Document Id tabbed section in the Route Log tab.
Table 80 Document Id Tab Definition
Field Description
Document Title A combination of the document type, description and the Organization document number
Document Type Type of research administration transaction. The full name of the transaction used to identify this
document type in Workflow. Click to drill down and view details.
Initiator The user ID of the person who created the document. Click to drill down and view details.
Route Status Workflow document status.
Field Description
For information about the route status, see the Route Status subtopic within this topic.
Route Node(s) The steps that a document takes through the different levels of routing are also referred to as 'Route
Nodes.' This field shows the current Route Node of the document.
Created Time and date that the document was created
Last Modified Time and date that the document was modified last
Last Approved Time and date that the last action was taken on this document
Finalized Time and date that the document reaches Final, Canceled, or Disapproved status
Actions Taken, Pending Action Requests, Future Action Requests tabs
In addition to the Document Id tab, the Route Log displays the Actions Taken, Pending Action Requests, and Future
Action Requests tabs that enable you to view the documents routing information. Each provide columns of information
related to workflow actions and the users and groups involved. Show buttons allow you to view more information, and
some data displayed in table cells is underlined to indicate it functions as a hyperlink to allow you to drill down to
view even more details.
Figure 149 Additional tabbed sections within the Route Log tab display the actions previously taken, pending and future actions
requested.
Table 81 Route Log Action Tabs Definition
Tab Description
Actions Taken The Actions Taken tab displays the history of workflow actions on the e-doc. The tab shows what
action was taken, who took the action, and the time and date the action was taken.
There may be several layers of information available for a specific action request.
Pending Action
Requests
The Pending Action Requests tab displays the next action to be taken and reveals more detailed routing
information about this request.
Note that the Pending Action Requests tab only shows pending requests for the document
at its current route level (or Route Node). New requests may be added when the document
transitions to a new route level.
Future Action Requests The Future Action Requests tab appears in the Route Log for a document. Once a document is Saved
or ENROUTE this section shows the action requests that Workflow generates in the future based on
the information currently on the document. As a document routes and users take action on it the Future
Action Requests section updates to show only those requests that have not yet been made by Workflow.
Once a document reaches FINAL (or PROCESSED) status in workflow this section becomes blank
as there are no future requests left to display.
Future requests appear in the order in which they are to occur.
Table 82 Route Log Action Tabs Column Definition
Column Description
Click the show button to expand the display and drill down into the action details, and further to view the
requestor details, and again to see the workflow system details.
Action The Action field indicates whether the document is in that user or workgroups action list or if it is pending their
approval. Action requests of 'PENDING APPROVE' mean Workflow has identified other approval actions
needed at this route level, but has not actually sent the document for these requests yet. Workflow routing rules
have a priority attribute that determines the order in which it sends action requests.
Taken By Drilldown link to view user details for the person who took the action.
For Delegator The For Delegator field shows the name of the person on whose behalf the Delegator has acted.
Requested Of The Requested Of field displays the user name or the workgroup based on the business rule set for the document
being routed. Click the workgroup link to identify members of the workgroup. One of the members of this
workgroup must approve the document to route it to the next step.
Time/Date The time and date of the action or request.
Annotation The annotation appears in the Route Log tab. Routing Annotation is a part of Workflow and contains workflow
system generated messages.
Viewing Rules
Rule drilldown links allow you to see the various criteria that make up a rule.
Figure 150 Clicking the Rule link to display its details
Figure 151 Viewing the Rule Details
General Info section: you are able to view basic identifying rule information as well as details about what
makes the rule work.
o Document Type field: Rules are specific to certain documents or groups of documents. For example,
under Document Type you can see that this rule is specific to the ProposalDevelopmentDocument.
o Rule Template field: You create rules using a Template. The template establishes what kind of criteria
(or attributes) the rule can look for. In this case, this rule is based on the OSPInitialApproval. This
template is used to create OSP Initial Approval (also called OSP Initial Review) rules.
Responsibility section: If a document meets the specified criteria then it routes based on information in the
Responsibility section of the rule.
o Type field: Indicates whether you are requesting action from a person or a workgroup. In this example,
the rule indicates a workgroup.
o Reviewer field: The User ID of the person or workgroup the action is being requested from.
o Action Request Code field: Indicates the type of action being requested. Normally requests can be
made for Approval, Acknowledgement or FYI.
o Priority field: Tells Workflow how to order action requests if it needs to generate more than one request
for a specific document at this route level. Priority ranges from 1 to 11 and rules with a lower priority
number assigned requests action before rules with a higher priority number.
Route Status
Route Status tells you where the document is in the routing process. The Route Status appears in the Route Log tab and
also in the document header.
In the Document Id tab of Route Log, the status is displayed in a field labeled Route Status
In the Document Header, the status is displayed in a field labeled Status
The following table summarizes the meaning of the various document route statuses in the KEW:
Table 83 Kuali Enterprise Workflow Document Route Status Definition
Status Description
Approved The document is approved. The document is now a valid business transaction in accordance with
Status Description
institutional needs and policies.
Canceled The document is denoted as void and should be disregarded.
Committed The document has been committed to the database. See note below.
Disapproved The document is disapproved by an approver as a valid research administration transaction.
Enroute The document has pending approval requests.
Exception The document has been routed to an exception queue because workflow has encountered a system error
when trying to process a rule.
Final The document has been routed and has no pending approval or acknowledgement requests. Documents
in Final status are considered approved.
Initiated The document is created.
Processed The document has no pending approval requests but still has one or more pending acknowledgement
requests. Processed documents are considered approved.
Saved The document has been started but not completed or routed yet. The Save action allows the initiator of a
document to save their work and close the document. The document may be retrieved from the initiators
action list for completion and routing at a later time.
You do not normally see the COMMITTED status. The only time it might show is when there is a system error or
performance issue.
Rule Templates and Attributes
Rules are built based on rule templates. Templates represent a route level and a collection of attributes.
Attributes are the building blocks of templates. They identify which components of a transaction can be used to establish
routing rules.
Figure 152 First Approval Routing Rule Template Attributes
About The Need For Rule Flexibility: Because KRA was developed for Higher Education as a whole, it is critical
that Kuali Workflow allow flexibility in the creating of rules. Different institutions may want to route transactions based
on different attributes and have more or fewer route levels.
How Templates Fill That Need: Templates can be designed by combining various Kuali attributes and configuring a
document type (such as a Proposal or Budget document) to use that template as one of its route levels. This gives a great
deal of flexibility and puts routing changes within the grasp of functional users.
Template Maintenance Admin Only: However, because they are critical to Workflow functioning properly, the
creation and maintenance of Templates (and attributes) is restricted to Workflow Administrators (members of the
WorkflowAdmin workgroup).
KEW Operations
This topic explains some of the operations that you need to be familiar with in order to understand and use the KEW
module in your usage of KRA.
Action List
You receive action requests for KRA transactions through your Action List. Summary information about the documents
in your Action List is provided, such as document type, title, route status, the type of action requested of you, who
initiated the document, when it was created and whether or not youve received this request because you are a Delegate
or a member of a workgroup.
1. Click the action list button from the toolbar on any KRA screen.
The workflow system retrieves all of the documents that you have initiated and saved, and
any documents that are routed to you to approve, acknowledge or FYI:
Figure - Documents in the Action List that are pending action.
2. Click the Document ID link to open the document (for example, 2128).
A different set of buttons appears in the bottom of the document depending on your roles
and the requested action:
Figure Workflow action buttons
In the case of multi-page documents (like Proposal, for example), these only appear at
the bottom of an Actions page (for example, Proposal Actions).
3. Click one of the workflow action buttons (for example, approve) to complete your usage
of the action list by taking action on a particular document.
Workflow Action Buttons
When you open a document, you see different workflow action buttons at the bottom of the document depending on your
relationship to the document and the documents current workflow status. Some transactional documents contain a
separate page dedicated to actions, and only display unique, workflow-specific action buttons at the bottom of that page.
These buttons vary depending on what kind of action request you received for the document and on whether or not you
are a special kind of KRA user, such as an Administrator or Superuser.
Table 84 KRA E-Doc Action Command Buttons
Button Description
Sends certain federal proposals created in Proposal Development directly to the Grants.gov on-line
system. This system-to-system (S2S) application transmittal is only available for certain funding
opportunities. The eligibility requirements are specified by each sponsoring agency. This button
only appears on the Proposal Actions page of the Proposal document and is only functional after
full routing and approval.
Moves the document (through workflow) to the next level of approval. Once a document is
submitted, it remains in ENROUTE status until all approvals have taken place.
Denotes that the document is void and should be disregarded. Canceled documents cannot be
modified in any way and do not route for approval. They may be copied, however, to a new
document.
Signifies that the user wishes to exit the document. The system displays a message asking the user
if they want to save the document before closing. No changes to Action Requests, Route Logs or
document status occur as a result of a Close action. If you initiate a document and close it without
saving, it is the same as canceling that document.
Allows the initiator of a document to save their work and close the document. The document may
be retrieved from the initiators Action List for completion and routing at a later time.
Refreshes the screen and displays the most recently saved information. Changes which are made
but not saved prior to reloading a page are not maintained.
Returns the document to its Initiator when the initial OSP reviewer has identified changes that are
required for approval. This action has the effect of remanding the document back to the originator
or preparer for modifications. You will be prompted to enter comments, just as with a
disapproval.
Signifies that the user has responded to the FYI action request. Only available to users to whom a
document has been routed for FYI. The difference between Acknowledgement and FYI is that FYI
requests can be cleared directly from the action list without opening the document. FYI requests
also have a different effect on the document status than Acknowledgements. A document with no
pending approval requests but with pending Acknowledge requests is in Processed status. A
document with no pending approval requests but with pending FYI requests is in Final status.
FYIs do not interrupt the normal Workflow routing of a document either. To signify that you have
responded to the FYI action, you may take one of the two actions: click FYI when you open the
document, or select FYI in the Actions column and click take actions directly from the Action
List. If you wish to clear all of the FYI actions in the Action List at once, you may first set the
default action from NONE to FYI. Click apply default located at the upper right corner and then
click take actions.
Signifies that the user has responded to the Acknowledgement action request. It is only available
to users to whom a document has been routed for acknowledgement. Acknowledgements do not
interrupt the normal Workflow routing of a document. They do not stop a document from routing
on to other individuals or workgroups who need to take approval actions.
Signifies that the document represents a valid business transaction in accordance with institutional
needs and policies in the users judgment. A single document may require approval from several
users, at multiple route levels, before it moves to final status.
Signifies that the document does not represent a valid business transaction in the user's judgment.
A Disapprove action from any single approver prevents a document from ever posting to the GL.
Enter a reason for disapproval, and then click yes to confirm. The reason entered displays in the
Notes and Attachment tab once the disapprove action is completed.
Button Description
Bypasses all subsequent levels of approval and immediately moves a document to final status.
Anyone who would normally have received the document for approval receives an
Acknowledgement request instead. This action may only be taken by an Administrator. If you are
an Administrator, you have the option to blanket approve a document routed to you for your
approval. Click blanket approve to approve the document bypassing all other approvals.
Performs a route report. In other words, clicking this causes a new browser window to pop up that
displays the same information that is contained in the Route Log tab. These include sub-tabs
within the Route Log tab for Document Id, and possibly Actions Taken, Pending Actions, and
Future Actions, depending on the document and route status.
Superusers use this to select an action request, select the recipient type, enter the user ID or
workgroup ID, and ad-hoc route a document.
Superusers click this to return a document to the previous route level, by first selecting a node
name from the route level list.
Preferences
The Preferences link allows you to customize how your Action List screen appears and functions.
You can select options to:
Choose how frequently the page refreshes
Select how many Action Requests appear per page
Select the frequency of (or disable) e-mail notification regarding new requests
Enable or disable individual columns on the Action List page
Selectively color Action Requests based on the Route Status
Limit the list of documents to display in the Action List by setting filters for Delegators or workflow status

The Preferences link appears within the Workflow menu group and also under the toolbar on the Action List page.
Action List Preferences allows you to change the display of your action list.
Table 85 Action List Preferences Definition
Criteria Description
Automatic Refresh Rate Enter a number in whole minutes.
Action List Page Size Enter a number of rows to display per page in the Action List.
Email Notification Select one of the desired email frequencies from the Email Notification list of None,
Daily, Weekly or Immediate.
Delegator Filter In the Delegator Filter list, click Secondary Delegators on Action List or
Secondary Delegators only to specify when to show the secondary delegation
entries in your Action List.
Fields Displayed in Action
List
Click either Yes or No for each of the fields to be displayed in the Action List.
Document Route Status Colors
for Action List Entries
Click one of the color options for each of the Document Route Status. The row
containing the document of the status is displayed in the color of your choice in the
Action List.
Click save to save your preferences.
Click reset to return to the default preferences.
The effect of the color preference change does not take place until you log onto the system the next time.
Figure - The row colors change the next time you log on
Action List Filter
Setting a filter allows you to display a subset of the Action List. Click the Filter hyperlink to go to the Action List Filter
dialog box.
Figure 153 Click Action List Filter hyperlink to go to the Action Filter dialog box.
Figure 154 You may limit the e-docs displayed in your Action List by setting a filter.
Table 86 Action List Filter Definition
Document Title Enter a partial or full character string that you are looking for in the document
description. For example, when you enter 'Test' in the Document Title field, the
Action List displays all documents that contain 'Test' in the document description. This
field is case sensitive.
Document Route Status Select a route status in the Document Route Status list. The list contains the
choices All, Approved, Disapproved, Enroute, Exception, Processed and Saved. Select
the Exclude? check box to exclude documents with the selected status from the list.
Action Requested Select an action in the Actions Requested list. The list contains Acknowledge,
Approve, Disapprove, and FYI. Select the Exclude? check box to exclude documents
with the selected action from the list.
Action Requested Workgroup Enter the name of the Workgroup that is requested to take an action.
Document Type
Select a document type from the Document Type lookup .
Date Created
Enter a date range or select dates from the calendar by clicking the Calendar to
limit the documents based on the date they were created. Select the Exclude? check
box to exclude documents that were created during this given time range.
Date Last Assigned
Enter a date range or select dates from the calendar by clicking the Calendar to
limit the documents based on the date that this action item was generated for you.
Select the Exclude? check box to exclude documents that entered your action list
during this given time range. The acceptable format is mm/dd/yyyy.
To filter your Action List:
1. Click the Filter link from the Action List header area..
The Action List Filter screen appears:
2. Specify the filtering criteria in the Action List Filter dialog box by making entries and
selections as desired, and then click filter.
A system message appears in the notification area (upper left corner) of the Action List:
Changes you made to filter settings are summarized on the Action List screen
To clear your filter:
1. Click the Clear Filter link to remove the filter.
Note that the Clear Filter hyperlink is visible only when you have previously created the
filter.
To refresh the list:
1. Click the Refresh Action List link to display the complete Action List.
To use the Outbox:
1. Click the Outbox link to view documents for which youve completed requested actions.
The Action List result table is refreshed to display your Outbox items:
To remove an item:
1. Check the Delete Itemcolumn for any document you want to remove and click the delete
selected items button.
Document Search
The more advanced and sophisticated e-doc search capabilities are explained in this topic.
For basic information about how to use the doc search feature, see Searching for a Document in KRA Overview
> Common E-Doc Operations.
Basic vs. Detailed Search
The search screen initially defaults to a basic search. You may switch between the basic search and detailed search by
clicking the Basic Search or Detailed Search hyperlinks on the horizontal workflow bar. The detailed search screen
gives you more options for search criteria.
Figure 155 Basic Search
Figure 156 Detailed Search
Superuser Search vs. Non Superuser-Search
The search screen initially defaults to a Non-Superuser search mode. If you have the Superuser role, you may switch
between the Non Superuser search and Superuser search mode by clicking the Superuser Search or Non Superuser
hyperlink.
Figure 157 The Superuser Search mode gives you more search options.
The Superuser search mode gives you more search options and allows you to access documents you want to take
Superuser actions on, such as bypassing an approval or sending a document to another route level. Anyone can search for
documents using Superuser search, but only Superusers can actually take special actions on the documents retrieved
from the Superuser search hyperlink.
Named Search
When you name a set of search criteria, the system saves your search as a named search.
Figure 158 Naming a Search
When you later click search, the system displays a list of all named searches you have created in the Searches drop-down
list.
Figure 159 You may access your named search in the Searches list.
Clearing Searches
Click Clear Saved Searches to clear the named searches from the list.
Click clear to clear your previous search criteria.
Document-Specific Searches
The document-specific searches are designed to assist you with additional search criteria for particular transactional e-
docs. In addition to the standard search criteria available in the basic or advanced search, these searches include unique
fields such as document status, and document-specific reference numbers.
All My Proposals
The All My Proposals link from the Proposals menu group on the Researcher menu is a document-specific search for
only Proposal documents that you have initiated.
All My Proposals Link from Researcher menu > Proposals menu group
Columns Displayed In Results Table for Proposal Document Search Using All My Proposals Link
Setting Up Workflow
While the standard end users of KRA (Researchers) are able to set their own Action List preferences, there are many
more Workflow settings that are configured using the KRA user interface that some Unit and Central Administration
users must be familiar with. On their menu screens, their Workflow menu groups include links for setting up workflow
preferences, running reports and setting up rules and workgroups within the Kuali Enterprise Workflow (KEW).
Whereas individual users can change their own workflow preferences, the institutions system administrators or the super
users within the functional area are responsible for making changes to the workflow rules.
Options in this menu group are used to set up workflow
Table 87 Workflow Menu Group Link Definition
Link Description
Preferences Selects preference option settings that control the appearance of Action List and how automatic e-
mail notifications are handled.
Preferences is available to any user, including Researchers. For more information about
setting Action List preferences, see Preferences in KEW Operations.
Routing Report Accesses and opens a document by Document ID for the purpose of performing operations on the
document.
Rules Searches for routing rules using standard Kuali search tools.
Rule Quick Links Links to current routing rules organized hierarchically by document type. Allows you to view, add
new, or edit existing workflow rules.
Workgroup Searches, creates new, or edit existing workgroups.
For more information about setting Action List preferences, see Preferences in KEW Operations.
Routing Report
The Routing Report generates reports based on routing rule templates.
Step 1: Select A Rule Template
Step 2: Enter Routing Data and click view results
Step 3: Click show to view all details as desired
Rules
Clicking the Rules menu link causes the Rule Lookup workflow screen to appear. The Rule Lookup allows you to
search for routing rules using the standard Kuali search tools.
Rule Lookup Workflow Screen Search Criteria Section
Rule Lookup Workflow Screen Search Results Table Section
Edit Rule Workflow Screen Example
Rules Overview
Rules, within the context of KRA Workflow, allow you to route a document to one or more persons or groups. The
process of creating a new Workflow rule is not complex, but rather requires knowledge of how Workflow operates.
In most cases, it is more convenient to use Rule Quicklinks instead of the Rules link. The only time that Rules
provides any necessary functionality is when creating a rule for a parent document type, that does not have an
associated event
There are two fundamental ideas when creating rules that must be understood: Document Types, and Rule
Templates.
A Document Type is exactly as it soundsit encompasses an entire class of documents. Two examples are
KRA Proposal Development documents, and Workflow Maintenance Documents.
Rule Templates serve as hooks into the document routing system, and are relatively synonymous to events.
Behind the scenes, Workflow has a file that outlines the routing path for each and every document type. This file tells
Workflow where to route the document given certain actionsapprove, deny, and route, for example. Rule Templates
allow you to take action on a document when Workflow is at a specific stage in routing the document.
Rules in Workflow are limited in their functionalitythere are no complex conditional statements or other caveats of
programming. The only action that can be taken is to route a document to a single (or multiple) users, workgroups, or
roles (under Responsibilities). Rules do allow you to mix-and-match the types of responsibilities (for example, two
individual users, and one workgroup).
In addition to selecting whom is responsible for a document, you can also select the Action Request Code and priority for
the document.
Rule QuickLinks
Each Document Type has its own specific Rule Templates. A Rule Template for KRA Proposal Development
documents will not work in conjunction with a Workflow Maintenance Document. The purpose of Rule Quicklinks is to
group the Document Types with their corresponding Rule Templates.
Figure 160 KRA Rule QuickLinks Document Tabs
On the Rule Quicklinks page, each Document Type is listed as an expandable menu. Inside of the expanded area, a list
of Rule Templates is displayed. These specific Rule Templates can be used with the Document Type in question. Links
allow you to add new, modify or search for the existing workflow rules. To search for the workflow rule, click the
Search link for the workflow rule. To create a new workflow rule, click the Add Rule link for the document you want
to define the workflow rule for. When you add or edit the rule, the document is routed to the WorkflowAdmin
workgroup.
Searching For A Rule
Click Search link to the right of the desired rule line from a Rule QuickLinks document tab.
The Rule Lookup screen appears with the Document Type Name and Rule Template already selected based on the rule
whose search link you clicked:
Enter and/or select additional criteria as desired and click search.
The results are displayed in table format:
Viewing A Rule Report
Click the report link from the Actions column of the Rule Lookup result table.
The Rule report tab appears:
Rule Tab
Figure 161 Rule Tab
Table 88 Rule Tab Definition
Field Description
General Info section
Document Id The unique number of a particular e-doc if applicable
Pervious Version If copied from another rule
Rule Id Numeric representation of this unique rule
Rule Name Textual name corresponding to the Rule Id
Active Select Yes to activate the rule, select No to inactivate the rule.
Description Optional. Enter the description of the workflow rule.
From Date Enter the date on which the workflow rule should become effective, or search for it from the
Calendar .
To Date Enter the date on which the workflow rule should become inactive, or search for it from the
Calendar .
Document Type Display-only. The document type for which the rule is defined. Pre-populated from your search
criteria.
Ignore Previous Defines if the document should be routed to the approver multiple times when an approver is
assigned to more than one workflow route levels. Selecting Yes sends one notification to the
approver, No sends multiple notifications to the same approver.
Rule Template Display-only. The rule template for which the rule is defined. Pre-populated from your search
criteria.
Responsibility section
Type Select person if the document should be routed to an individual. Select Workgroup if it should
be routed to a workgroup.
Reviewer Select the user ID or workgroup depending on the Type selection above.
Action Request Code Select the appropriate action that the Reviewer should take from the Action list. The choices are
approve, acknowledge, or FYI.
Priority If routing for this rule occurs sequentially the priority determines the order in which users or
workgroups receive the generated action requests. Rules with lower priority numbers are routed
before rules with higher priority numbers.
Edit Switch to edit mode when viewing display-only report
Copy to new Copy this rules attributes to a new Rule Id that can then be modified
export Export this rule as xml
There might be additional, document-specific workflow rule criteria depending on the document type.
Adding A Rule
Add vs. Edit: Adding a new rule is a similar process as modifying an existing rule. If you want to edit a rule,
clicking the edit link takes you to the Workflow Rule Document which includes two tabs: Create New Rule and
Rule.
Clicking the Create new Rule link from the workflow header link bar allows you to create a new rule by adding an
additional Rule tab on the Rule document.
Otherwise, you may accomplish the same by using the Add Rule link on the Rule QuickLinks tab.
To create a new Workflow Rule with a given Document Type and Rule Template:
1. Click Add Rule underneath the Document Types heading, next to the
Rule Templates name.
2. A new Rule window appears. Enter a description for the rule, in addition
to a From and To date that outline the timeframe for which the rule
will be activated.
3. Select the type of responsibility (user, workgroup, or role).
4. Enter the name for the reviewer (for example, the user name or
workgroup name). You can use the magnifying glass icon to search for
users and workgroups.
5. Select the appropriate Action Request Code and priority for the
responsibility.
6. To add additional responsibilities, click add responsibility at the top or
bottom of the form.
7. You may add an annotation in the space provided.
8. Finally, select an Ad-Hoc route for the approval of your rule. Your rule
may need to be Approved before it is activated, depending on your Role.
9. Click route to recipient. The document is routed to the person or
workgroup that is designated as an Approver in the Rule document rule.
The Initiator may add an ad hoc Approver by entering the recipient type,
network ID or workgroup name, or action request and click the route to
recipient button.
Rule Routing
Figure 162 Rule Maintenance Document Workflow
Workgroup
A workgroup is a group of users designated for e-doc routing that share a common business function. E-docs may be
routed at any point in their approval to individuals or workgroups. Workgroup approvals may require approval of all
workgroup members or any one member.
The Workgroup document creates new KRA system workgroups or to edits existing workgroups. Workgroups are
integrated with the KEW system to manage workflow and document routing. Workgroups also control who can initiate
certain types of restricted KRA transactions. This functionality is used to uniquely define groups that contain members
who are KRA users. Since e-docs can be routed to both individuals and workgroups, existing workgroups can be selected
by users to request action be taken on e-docs by their members. Routing rules facilitate how workgroups are to be used.
The business rules that govern the routing of e-docs to workgroups are configurable by your institution.
You may access a Workgroup document from the Workgroup link in the Workflow menu group of either the Unit or
Central Admin menus and entering criteria to search for it on the Search for a WorkGroup screen that appears.
Searching for a Workgroup
The default start mode for searching for workgroups that fit your search criteria is the Default (or blank) mode. When
you select something other than Default in the Workgroup Type field, additional search criteria fields appear on the
screen, allowing you to search for workgroups of this type by these attributes.
Table 89 Search for a WorkGroup Screen Search Criteria Section Field Definition
Field Description
WorkGroup Name Optional. Enter a full or partial string of the workgroup name for which you are
searching.
You do not need to use * for a wild card search. Upper and lower case insensitive.
WorkGroup Type Optional. Leaving the selection blank defaults to the Default search mode.
WorkGroup Description Optional. Enter a full or partial workgroup description.
You do not need to use * for a wild card search. Upper and lower case insensitive.
WorkGroup Member
Optional. Enter a user ID or select it from the User ID lookup .
WorkGroup ID Optional. Enter the WorkGroup ID of the workgroup you are searching for. This ID is
automatically assigned by workflow when the workgroup is created.
Active Indicator Optional. Select one of the following: Active Retrieve all active workgroups;
Inactive Retrieve all inactive workgroups; Show All Retrieve both active and
inactive workgroups. The default is Show All.
Viewing a Workgroup Report
Unlike financial transaction or maintenance e-docs, the report actions are available in the Search Result for the
workgroup lookup. To access the workgroup report, click the report link in the action column for the desired workgroup
name.
Click the report link from the Actions column of the Workgroup lookup result table.
Workgroup Report
The workgroup report displays the information about the workgroup and allows you to edit, copy, or export the content
of the document.
Table 90 Workgroup Report Definition
Field Description
Document ID Display-only. The unique ID of the workgroup document
Workgroup ID Display-only. The unique ID of the workgroup
Workgroup Name Display-only. Name of the workgroup
Workgroup Type Display-only. Identifier for the types of workflow defined in the system.
Workgroup Active Indicator Display-only. Indicates whether the workgroup is active or inactive
Workgroup Members Display-only, however, it allows you to drill down into the user lookup. Last name,
first name, middle initial of the workgroup member with the user ID in parentheses
Workgroup Description Display-only. A text description intended to describe the purpose of the workgroup
Click edit to edit the workgroup.
Click copy to new to create a new workgroup document with a new ID containing the
same information, allowing you to edit further.
Click export to create an xml file using the data from the workgroup.
Creating a New Workgroup
A new workgroup can be created from the Create new workgroup link one the Search for a WorkGroup screen.
Figure 163 New Workgroup Document
Table 91 Workgroup Document Definition
Field Description
Workgroup Name Required. Enter the name to uniquely identify the workgroup.
Type Optional. Select the workflow type from the list.
Leaving the selection blank defaults to the Default search mode.
Active Indicator Required. Select the Active option to indicate that the Workgroup is active and in use. Select the
Inactive option to indicate the workgroup is inactive and should be ignored by KRA.
Members Required. Select the member type from the list (User or Workgroup) and enter the UserID or
workgroup or search for them from the UserID or Workgroup lookup .
To add a member to the workgroup
Field Description
To remove a member from the workgroup
Description Required. Enter text to explain the purpose of the workgroup.
Annotation Optional. Enter additional special notes or other necessary information associated with the
workgroup that should be recorded. Notes entered here can be viewed in the route log.
Adhoc Route Use this to get required approvals as may be necessary based on your role and business rules. The
Adhoc Route section is optional. The Adhoc Route section becomes required only when you wish
to ad-hoc route the Workgroup document to others.
For more information, see Ad Hoc Routing in Route Levels.
Click route to recipient to add a member or workgroup to the Ad Hoc Recipient list.
Recipient Type Optional. If ad hoc routing the workgroup document to other users for approval, define whether
the recipient type should be a person or workgroup.
Network ID or
Workgroup Name
Optional. Enter the Network ID (for a person) or workgroup name (for a workgroup) identifying
the users you wish to ad hoc route the workgroup document to.
Action Request Optional. The type of action being requested from the group or person you are routing the
workgroup document to -Acknowledge, Approve, FYI, or Complete.
Click remove recipient for the Network ID or Workgroup Name to remove a member or
workgroup from the List of App Specific Route Recipients.
Click route to initiate the routing action of the workgroup document to recipients.
If you already have Administrator or Superuser access associated with your role, you may blanket
approve the new workgroup and bypass other approvals.
Click cancel to stop the routing of the workgroup document from occurring.
Workgroup Business Rules and Routing Process
Anyone can initiate the workgroup documents.
For the Default (or blank) type workgroup, the document does Workflow Document Routing.
Blanket approval is permitted only by a user that belongs to the WorkflowAdmin workgroup.
Figure 164 Workgroup Document Workflow
System Administration
This topic discusses the links in the System menu group that appears on the System Admin menu.
Table 92 System Menu Group (System Admin menu) Definition
Link Description
Current Locks
Link to the Pessimistic Lock Lookup screen that allows you to search for and delete locks on e-
docs that are locked for editing by particular users
Employee Status
Future functionality.
Employee Type
Message of the Day
Parameter
Defines parameters and business rules
Parameter Component
Parameter Module
Parameter Type
Person Maintains identifying and contact information records about people (employee or non) who are, have
been, or could be involved in research administration activities.
System Options Future functionality.
Parameter and Person are maintenance documents used to maintain table records that are used for maintaining the KRA
system itself. They are technical in nature and more complex than most maintenance documents found on the
Maintenance menu. There may be at most a handful of individuals at your institution who are the Administrators of your
unique implementation of KRA who need to know more than what is given here. The following information provides a
functional overview of these maintenance documents, however, is not intended to replace the details that can be found in
KRA Technical Documentation, access to which is identified on the kuali.org Web site.
Parameter
Parameter Maintenance Document
The Parameter Maintenance Document is used to define parameters and business rules in the KRA. A specific value of a
parameter can vary based on what the parameter is used to define. These rules create restrictions and enforce valid values
and combinations on various document types or batch processes. The value may, for example, be text that KRA is to
display in a given location or it may be a simple yes or no value to turn an option on or off.
Layout
The Parameter document includes the Edit Parameter tab.
Edit Parameter Tab
The Edit Parameter tab is where you define the modules, type, rules, and description of the parameters.
Table 93 Edit Parameter Tab Definition
Field Description
Parameter Namespace Code Any 20. This value is used to categorize parameters by namespace.
Parameter Detail Type Code Any 100. Code identifying the parameter detail type
Parameter Name Required. Enter the name of the parameter being defined . This will be used as the identifier
for the parameter. Parameter values will be accessed using this field and the namespace as the
key.
Parameter Value Required. Enter the value for the parameter. The nature of a given parameter determines what
form the parameter value should take. In cases where multiple values are allowed they should
be separated by a semi-colon. This field houses the actual value associated with the parameter.
This is what's returned by the KualiConfigurationService.
Parameter Description Required. Describe the purpose and usage of the parameter. The description is used for a
documentation purpose (up to 4000 characters).
Parameter Type Code Required. Select the parameter type code from the Parameter Type list or search for it from
the lookup that is meant to identify the parameter type.
Parameter Constraint Code Required. Select Allowed from the drop-down list if the parameter is to allow the defined
parameter value within the KRA application. Select Denied if the
parameter is to deny the defined parameter value within the KRA application.
Workgroup Required. Enter the workgroup that can establish and modify the parameter. The document is
routed to the workgroup for approval. The ID of workgroup with parameter editing ability can
also be located and selected using the lookup .
Routing Process
The Parameter document can be initiated by the members of the workgroup defined in the Parameter document and does
not route for additional approvals if it is only modifying Parameter Values or changing the Parameter Constraint Code.
New parameters or documents that modify additional fields need to be approved by the defined user or workgroup in the
Parameter Maintainers Review route level.
Figure 165 Parameter Document Workflow
Examples
Person
Person Maintenance Document
Layout
Routing Process
Figure 166 Person Maintenance Document Workflow
Workflow Configuration and Monitoring
This topic discusses the links in the Workflow menu group that appears on the System Admin menu. It introduces
screens and functions that are used by technical staff that support the Kuali Enterprise Workflow (KEW). Typically, only
one person or a few people at the organization would use this functionality. Thus, this documentation introduces the
overview of the functionality, however, the technical staff at your institution should consult the Kuali & Rice Web sites,
the Kuali wiki, and related online resources to obtain more detailed instructions from the technical documentation
available from the Kuali Foundation.
Although other menus in KRA contain menu groups labeled Workflow, the one on the System Admin menu is
designed for administrators for configuration and monitoring purposes (as are others like Service Bus). The options in
this menu group are used to configure and maintain the Kuali Enterprise Workflow (KEW).
Table 94 System Admin Workflow Menu Group Definition
Link Description
Application Constants Create new / view existing application constant names and values.
Document Operation Access and open a document by Document ID for the purpose of performing operations on the
document.
Document Type Search for a document type by entering the following criteria: Parent, Name, Label, ID, and/or
Active/Inactive status.
Rule Attribute Enter criteria to search for rule attributes by Name, Class Name and/or Attribute Type.
Rule Template Search for rule templates by Name or Description.
Statistics Report Select date ranges and generate reports containing Users, Actions, Documents and Routing
Status statistics.
Workgroup Type This search screen allows you to view any special workgroup type categories that exist.
Currently KRA only uses one special workgroup: WorkflowAdmin; however, custom types
may be created and added to the system by your system administrators.
XML Ingester Browse for and upload XML data.
Application Constants
The Application Constants allows you to view or modify existing application constant names and values that were
configured during the time of installation. To edit the value, click the corresponding edit link on the far right of the
constant name.
The Application Constants link allows you to view a list of running parameters that are currently in use by Workflow. In
addition to viewing existing constants, you may create new ones by using the fields provided.
Figure 167 Application Constants Workflow Screen
To create a new application constant:
1. Enter a name for your constant in the Constant Name box.
2. Enter a value for your constant in the Constant Value box.
3. Click save.
Your entry appears in the bottom row of the Existing application constants list
table:
To edit an existing application constant:
1. Click the edit link to edit an existing application constant (or delete to delete) as
desired.
Document Operation
The Document Operation link from the Workflow menu group on the System Admin menu causes the Operate on a
document screen to appear a workflow screen that is only accessible to Administrators and Superusers. It is a KEW
screen that allows you to modify any of a documents data, including the raw XML content. It gives you the ability to
change every single property a document hasowner, version, route status, who it is routed to, even change the
Document ID.
The Document Operation function allows you to manipulate the XML data in the document and save the document. The
screen is divided into several sections: Document Action, Document, Action Requests, Action Taken, Action Items,
Route Node Instances, Brach States, and Annotation for Admin Change.
To operate on a document:
1. Click the Document Operation link from the Workflow menu group on the
System Admin menu.
The Operate on a document workflow screen appears.
2. Enter a number in the provided Document ID box and click get document.
The Operate on a document screen is refreshed to display the following
sections:
Document Actions
Document
Action Requests
Actions Taken
Action Items
Route Node Instances
Branch States
Annotation for Admin Change
3. Make changes to the appropriate sections as necessary to modify the document.
You have the ability to modify any field of the document, either by using the
provided boxes, or by editing the raw XML in the Doc Content box. Additionally,
you can entirely delete certain fields, such as Action Request, Actions Taken, and
Action Items by selecting the Delete option from the heading above the
corresponding section.
4. Click save at the bottom of the screen after you have completed your changes.
Be sure to leave an annotation describing the actions taken, as well as the
reasons for taking actions.
Figure 168 Document Actions Section
Figure 169 Document Section
Figure 170 Action Requests Section
Figure 171 Actions Taken Section
Figure 172 Action Items Section
Figure 173 Route Node Instances Section
Figure 174 Branch States Section
Figure 175 Annotation for Admin Change Section
Document Type
The Document Type link allows you to search for and view various data about each document type, in addition to a
complete printout of the associated XML file that is being used by Workflow to define the document. The Lookup a
document type screen provides several entry and selection options for refining criteria by which to search. The
resulting table lists document types with associated report links in the Action column that allow you to view and
export the information about the document type, which includes identifying and configuration information.
This screen functions in many ways like the inquiry and maintenance document lookup screens elsewhere in KRA, but
unlike the Document Type document, this screen allows you to retrieve attributes assigned in KEW and view technical
workflow-related information relating to the document type.
To view Document Type information:
1. Click Document Type from System Admin > Workflow.
The Lookup a Document type workflow screen appears:
2. Enter and/or select criteria as desired (or leave the fields blank) and click search.
The result table appears under the criteria area:
3. Click report in the Action column to the right of the desired Document Type.
The screen is refreshed to display the report data for the document type you selected:
Export the report or hierarchy as desired.
Document Type Search Tips: Use the document type label for search criteria rather than document type
name. The document label is the same as the title of the e-doc whereas the document type name might be different
in some cases. Try removing the space between the words when you are searching for the document type that has
more than two words, for example, CarrierType. The search is case-insensitive and retrieves the document types
that partially includes the text you are searching for.
Rule Attribute
The Rule Attribute link allows you to search for and report on a rule attribute, and export in xml format.
To generate and view a rule attribute report:
1. Click Rule Attribute from System Admin > Workflow.
The Rule Attribute Lookup workflow screen appears:
Rule Attribute Lookup Criteria
Attribute Type List
2. Enter criteria as desired and click search to locate the rule attribute.
The items are retrieved and displayed in a table under the search criteria area:
Rule Attribute Search Result Table
3. Click the report link corresponding to the rule you would like to report on.
The screen is refreshed to display the Rule Attribute report information:
Rule Attribute Screen
4. Click export to save the xml file.
Rule Attribute Exported XML File
Rule Template
Use the Rule Template feature to search for a rule template report, view and export it in xml for reference or reuse. A
rule template report displays both identifying information and attribute detail information about a rule template.
To search for, view, and export a rule template:
1. Click Rule Template from System Admin > Workflow.
2. Search for the rule template. You may search for a partial text in the Name or Description box.
3. Click the report link corresponding to the rule you would like to report on.
4. Click export to view the xml file.
Statistics Report
The Statistics Report link displays a workflow screen that allows you to view the various statistical data about the
operations of Workflow over a timeframe you are able to select. It displays the counts of documents and users for
various statuses and categories.
Figure 176 KRA Statistics Report workflow screen
Modify the Begin and End Date fields as desired by entering in mm/dd/yyyy format or using the calendar selector,
select the desired option from the Average Number of Actions for Date Range list then click the refresh button.
Workgroup Type
Clicking the Workgroup Type link in the Workflow menu group box on the System Admin menu screen causes the
Workgroup Type Lookup workflow screen to appear. It allows you to locate and view attributes of KRA workgroups.
The search result table has an Action column, from which you are able to click a report link that displays the details tab.
From the workgroup tab, you are then able to click an export button to save the data locally as an xml file.
Workgroup Type Lookup screen
To look up a Workgroup Type:
1. Click Workgroup Type.
2. Enter criteria in one or all of the four text boxes (or do not to retrieve all).
3. Select an option in the Active field (the Active radio button is initially selected by default).
4. Click search.
5. Click report.
6. Click export.
XML Ingester
The XML Ingester allows you to upload XML files that you have exported from KRA Workflow to the KEW server.
You can export a large variety of objects, such as document types, rules, rule templates, and workgroups. Once
exported, these XML files serve as a backup of the exported data. The XML Ingester allows you to upload the XML
files to Workflow, to save reconfiguration time, or to return to prior data.
Figure 177 XML Ingester
Additionally, users savvy with XML skills can make modifications directly to the XML files, and use the XML Ingester
to upload the modified file, so that the changes will take place.
The XML Ingester will not overwrite existing data. However, an XML flag, allowOverwrite, can be set to
true inside the <ruleTemplate> tag for rule template XML files. This will override the XML Ingester, and force
any existing template to be overwritten. Example: <ruleTemplate allowOverwrite="true">
Kuali Research Administration v.1.0 User Guide Glossary of Terms 419
Glossary of Terms
Key Term, Role & Acronym Definitions and Synonyms
Overview
This glossary is a compilation of the business terminology relevant to the KRA system. It also includes any technical
terminology that users of the system must understand and some general research administration terminology.
Disclaimer: The maintainers of this archive are not necessarily the authors or maintainers of the individual term or
acronym definitions appearing in this glossary. To correct or contribute to this document, send an e-mail to
kualitestdrive@oncourse.iu.edu. Contributions of others may be copyright of those individuals. You may copy and
distribute this document in any form provided you acknowledge this source. Exclusion of a term does not necessarily
mean it is not acceptable.
Purpose
The purpose of the KRA Glossary is to foster common understanding of terminology between the users and developers
of the system. Terms are listed alphabetically by term, acronym or abbreviation, not by meaning.
Context-sensitive, functional field descriptions can be found interspersed throughout the KRA Online Help and User
Documentation set. Refer to the appropriate topic by screen, page or tab name for the corresponding field to locate the
field definition table in that section.
AAHRPP
The Association for the Accreditation of Human Research Protection Programs, Inc., (AAHRPP) works to protect the
rights and welfare of research participants and promote scientifically meritorious and ethically sound research by
fostering and advancing the ethical and professional conduct of persons and organizations that engage in research with
human participants. AAHRPP achieves its mission by using an accreditation process based on self-assessment, peer
review, and education.
Account
Ledger ID assigned by institution (based on an institution's chart of accounts) to identify the account in the institution's
financial system
Account Type
Type of account to be established in the institution's financial system according to the institution's chart of accounts.
420 Glossary of Terms Kuali Research Administration v.1.0 User Guide
Action List
The online application that lists eDocs routed for appropriate action. An eDoc may be selected from the list and opened
for approval, completion, acknowledgement, or just FYI, depending on the applicable business rules. EDocs appear in
the Action List only when action is requested, and disappear after acted upon.
Activity Type
Activity type refers to the major functions of an institution based on OMB Circular A-21. Per OMB Circular A-21, the
major functions of a "university" are instruction, sponsored instruction and teaching, departmental research, organized
research, sponsored research, university research, other sponsored activities, and other institutional activities. Each
account in an institution's financial system must be identified by its activity type.
Address
This is the physical location information for each performing site. The information is maintained in the Rolodex.
Advance Account
An account that is set up at the department's request in advance of receiving a fully signed award instrument from the
Sponsor.
Affected Budget Period
The budgt period that will utilize the applicable rate for the identified fiscal year.
Agency Tracking ID
A number assigned to a proposal by a sponsor, after a proposal is submitted to Grants.gov, which is used to identify and
track the submission at the agency level.
Aggregator
The Aggregator is an assigned role in KRA that allows the user to make changes to any part of the proposal.
Anticipated Total (or Amount)
The anticipated sponsor funding for the entire project period - current obligation plus anticipated incremental funding
and future year funding, including possible option years. This does not include cost share.
Applicable Rate
In the budget module this is the rate that is automaticaly applied to object codes within each budget version, where
applicable.
Applicant Organization
The applicant organization, or grantee, is the organization or other entity that submits the proposal and receives the
award assuming legal and financial responsibility and accountability both for the awarded funds and for the performance
of the grant-supported activity.
Appointment Type
Type of employee or duration of the appointment for the indiviudal names in the Person column.
Authorized Representative Name and Address
The administrative official who, on behalf of the proposing organization, is empowered to make certifications and
assurances and can commit the organization to the conduct of a project that the sponsor is being asked to support as well
as adhere to various sponsor policies and grant or contract requirements. The address is the institution contact
information for the administrative official.
Authorized Institutional Official
An officer of an institution with the authority to speak for and legally commit the institution to adherence to the
requirements of the federal regulations regarding the involvement of human participants, animals, biological agents,
scientific misconduct and/or other regulations.
Award
To grant or declare as merited or due. If, after consideration, an outside agency/sponsor decides a proposal has merit and
worth, an agreement is drawn between the funding agency and Institution for services. This agreement is called an
award. An award is a legal, binding document for services in lieu of funds to perform the original outline of the proposal
submitted.
Award Instrument
The legal document in which the conditions of a sponsored award are communicated to an award recipient. Some
examples of an award instrument are a grant, contract or cooperative agreement.
Award ID
A unique ID automatically assigned by the system (based on institution specifications) to identify an award.
Award Type
The type of award instrument received by the award recipient (e.g. grant, contract, cooperative agreement, etc.).
Base Salary
The individual's current salary less any special pays (administrative supplements)
Biohazards
Biohazards are infectious agents or hazardous biological materials that present a risk or potential risk to the health of
humans, animals or the environment. The risk can be direct through infection or indirect through damage to the
environment. They include certain types of recombinant DNA; organisms and viruses infectious to humans, animals or
plants (e.g. parasites, viruses, bacteria, fungi, prions, rickettsia); and biologically active agents (i.e. toxins, allergens,
venoms) that may cause disease in other living organisms or cause significant impact to the environment or community.
(http://biosafety.ucla.edu/bio_hazard_def.html).
Biosketch
A biosketch, also known as a biographical sketch, is a document that briefly summarizes the professional experience,
publication record and accomplishments of an individual. It is a general term used by the NIH, and other sponsors. It is
required as part of a grant proposal for each PI and other key personnel.
Budget
An estimate of expenditures proposed to be incurred in the performance of a proposed sponsored project.
Budget Start Date
The start date of a budget period as reflected in the sponsor award instrument.
CFDA
Catalogue of Federal Domestic Assistance. A catalogue published twice a year which describes
domestic assistance programs administered by the Federal government. This government wide compendium of Federal
programs lists projects, services, and activities which provide assistance or benefits to the American public.
CFDA Number
A unique identifier for the sponsor and the funding opportunity announcement (FOA). The first 2 digits of the number
identify the Federal agency. The last 3 digits of the number identify the specific Federal program.
Closing Date
The last day and time (deadline date) in which a user may submit an application under a specific opportunity/program.
Co-I
See Principal Investigator
Co-Investigator
See principal Investigator
Co-PD
Co-PI
Co Principal I nvestigator. Investigators who share responsibility for the scientific or technical
direction of the sponsored project. (AKA Co-Investigator) See Multiple PIs Alternate: See Principal Investigator
(Delete definition and Remove complete spelling of CO-Principal Investigator in column to left and list as just "CO-PI")
Co-Principal Investigator
Co-Project Director
Committee Members Term of Appointment
The period of time in which a committee member has been appointed to a compliance committee
Common Rule
That portion of the federal regulations involving human participants that all federal agencies subscribe--45 CFR 46
Subpart A.
Community Sourcing
A model for the purposeful coordination of work in a community. It is based on many of the principles of open source
development efforts, but community source efforts rely more explicitly on defined roles, responsibilities, and funded
commitments by community members than some general open source efforts.
Competition ID
This identifies the version of federal forms required by the sponsoring agency and Grants.gov for the specific grant
application package.
Compliance Committee
A committee appointed by the research institution to oversee a compliance program to meet federal and state regulations.
These may include the use of human participants, animals, biological agents, chemical agents, radiation safety, scientific
misconduct, financial conflict of interest, etc.
Compliance Committee Member
An individual appointed to a Compliance Committee to review and approve research protocols describing proposed
research and use activities. These individual may be (1) employees (faculty, students, and/or staff) of the research
institution as well as members of the local community unaffiliated with the research institution, (2) designated as voting
or nonvoting, and (3) designated as ex officio or regular members.
Congressional District
The U.S. Congressional district number of the applicant organizational contact and the performing organizational
contact. Each Congressional district is an area within a state from which a member of the U.S. House of Representatives
is elected. There are 435 U.S. Congressional districts, each with a unique code.
Contact PI
This is a term used by NIH for projects where multiple PIs are proposed. The "contact PI" is the one PI designated for
all communication sbetween the PIs and the agency. The contact PI must meeet all eligibility requirements for PI status
in the same way as other PIs, but has no special roles or responsibilities within the project team beyond those mentioned
above. (See Multiple PIs).
Contact Type
The sponsor's point of contact for administrative, technical, fiscal, payment, patent, property, procurement, reporting,
sub-awarding or other matters.
Continuation
A proposal and/or award that has been previously committed (multi-year funding).
Correspondent
Cost Share
The portion of total project costs that are paid from sources other than the sponsor.
Clinical Research Coordinator (CRC)
CRISP
Computer Retrieval of Information on Scientific Projects (CRISP) is a searchable database of federally funded
biomedical research projects conducted at universities, hospitals, and other research institutions. The database,
maintained by the Office of Extramural Research at the National Institutes of Health, includes projects funded by
the NIH, Substance Abuse and Mental Health Services (SAMHSA), Health Resources and Services Administration
(HRSA), Food and Drug Administration (FDA), Centers for Disease Control and Prevention (CDCP), Agency for Health
Care Research and Quality (AHRQ), and Office of Assistant Secretary of Health (OASH). Users, including the public,
can use the CRISP interface to search for scientific concepts, emerging trends and techniques, or identify specific
projects and/or investigators.
Custom Attributes
A data element needed by an institution that is not available out of the box from the application.
Custom Data
A set of additional data elements needed that are not available out of the box from the application.
Destination Account
The institutionally assigned account ID where cost share expenses are recorded.
Direct Cost
Costs that can be identified specifically with a particular sponsored project, an instructional activity, or any other
institutional activity, or that can be directly assigned to such activities relatively easily with a high degree of accuracy.
Distributable Total
The monies received on an award not yet allocated to child awards.
Distributed Total
The monies allocated to child awards from a parent award.
Document Funding ID
The Document ID associated with the draw down of funds from the sponsor (such as the federal DHHS Letter of Credit
system.)
e-doc
electronic document An online business transaction initiated in a Web-based form and routed
electronically through a prescribed sequence of approvers. When the eDoc has been through its entire approval process,
it is maintained in a database for future reference.
Enhancement
A change to KRA that improves its functionality in some way, either by adding functionality that does not exist in the
baseline system (Coeus), or making substantive changes to functionality that does exist in Coeus. Requests for
enhancements from the KRA SME groups must show benefit over cost, and are reviewed by the KRA Technical Team
and Functional Council. The Functional Council ultimately votes to include, exclude, or defer enhancements in KRA.
KRA Enhancement Process
EPA
Environmental Protection Agency. The EPA is a federal sponsor.
eRA Commons
The electronic Research Administration (eRA) Commons is the NIH infrastructure that provides for the secure receipt,
review and administration of electronic grants. https://commons.era.nih.gov/commons/index.jsp
eRA Commons Username
The unique identifier (User ID) given to each individual registered with the NIH eRA Commons.
Execution Date
The date the sponsor award instrument is fully executed.
Exempt
See Exemption from IRB Review
Exemption
See Exemption from IRB Review
Exemption from IRB Review
Categories of research (primarily educational, behavioral, social science and research involving existing data, medical
records, and pathological specimens) that present little or no risk to the research participants. Research that qualifies for
"Exemption from IRB Review" must meet one of six categories outlined in the Common Rule (e.g. 45 CFR 46.101(b)
and should not involve vulnerable research participants except under unique situations. Reference Robert Amdur and
Elizabeth Bankert Institutional Review Board - Management and Function, Boston: Jones and Bartlell Publishers, p. 111.
Exemption Category Number
One of six categories of exempt research specified by the Common Rule (45 CFR 46.101(b).
Exemption Number
See Exemption Category Number
Expedited Review
Review of proposed human participant research by the IRB chair or a designated voting member or group of voting
members rather than by the entire IRB. Federal rules permit expedited review for certain kinds of research involving no
more than minimal risk and for minor changes in approved research Federal Policy xxx.110 (e.g. 45 CFR 46.110).
F&A
Facilities and Administration. Costs that are incurred for common or joint objectives and, therefore,
cannot be identified readily and specifically with a particular sponsored project, an instructional activity, or any other
institutional activity. F&A costs are synonymous with indirect costs and overhead costs.
See Indirect Cost.
FDA Application ID
Fiscal Report
The financial report(s) required to be submitted to the sponsor.
Fiscal Year
Federal wide Assurance (FWA) Number
The unique number that is assigned to the Federal wide Assurance. The Federal wide Assurance (FWA) is an assurance
of compliance with the federal regulations for the protection of human subjects in research. It is approved by the Office
for Human Research Protections (OHRP) for all human subjects' research conducted or supported by the Department of
Health and Human Services (HHS). The FWA is also approved by OHRP for Federal wide use, which means that other
departments and agencies that have adopted the Federal Policy for the Protection of Human Subjects (also known as the
Common Rule) may rely upon the FWA for the research that they conduct or support.
http://ohrp.cit.nih.gov/efile/FWA_start.asp
Foreign Travel
Any travel to, between or within countries outside of the United States and its territories and possessions that may occur
within the project period. Additional exemptions (Canada, Mexico, etc.) may also apply depending on specific sponsor
and/or institutional regulations.
Frequency Base
The date from which the system will calculate the due dates of the report(s) if it is required to be submitted within a set
frequency (i.e. quarterly, annually).
Funding Opportunity Announcement (FOA)
A Funding Opportunity Announcement (FOA) is a notice or solicitation of a grant funding opportunity.
Home Unit
The main unit in the Human Resources (HR) system associated with an individual's position or institutional appointment.
Human Participants
A living individual about whom an investigator (whether professional or student) conducting research obtains (1) Data
through intervention or interaction with the individual, or (2) Identifiable private information. 45 CFR 46.102(f)
Human Subjects
This term has been replaced by Human Participants in federal regulatory language.
IACUC
Institutional Animal Care and Use Committee. A committee qualified through the experience and
expertise of its members that oversees its institution's animal program, facilities, and procedures. (The IACUC
Handbook, edited by Jerald Silverman, Mark A. Suckow, Sreekant Murthy. 2nd Edition, Boca Raton: CRC Press, 2007,
inside back cover)
IBC
Institutional Biosafety Committee. Institutional Biosafety Committees (IBCs) were established under
the NIH Guidelines for Research Involving Recombinant DNA Molecules to provide local review and oversight of
nearly all forms of research utilizing recombinant DNA. Over time, many institutions have chosen to assign their IBCs
the responsibility of reviewing a variety of experimentation that involves biological materials (e.g., infectious agents)
and other potentially hazardous agents (e.g., carcinogens). This additional responsibility is assigned entirely at the
discretion of the institution. (http://www4.od.nih.gov/oba/IBC/IBCrole.htm)
Indirect Cost
See F&A Facilities and Administration
Institute Rate
Institutional rate associated with the rate type, on/off campus and fiscal year.
Instruction Page URL
The URL address that links to the program's complete grant application package instructions. Provided by the sponsor
and available for download from the Grants.gov link.
Intellectual Property Report
The intellectual property/patent report(s) required to be submitted to the sponsor.
International Programs
A category that can be chosen in the special review section, if the proposed sponsored project has an international
component (e.g. the work will be conducted in another country).
IRB
Institutional Review Board. A specially constituted review body established or designated by an entity to
protect the welfare of human participants subjects recruited to participate in biomedical or behavioral research. See
information provided in the Common Rule xx.102(g), xx.108, xx.109 (for example 45 CFR 46.102(g), 45 CFR 46.108.
45 CFR 46.109).
IRB Registration Number
A unique registration number assigned by OHRP to an individual IRB. The IRB Registration Number is connected to the
Institution and to the IRB Name in the Federal wide Assurance. There may be multiple IRB Registration Numbers and
IRB Names for one institution.
Institutional Official
See Authorized Institutional Official
Job Code
the Human Resources position identifier directly associated with the individual named in the Person column.
Key Person Role
The role in which each Key Person will be assigned for the proposed sponsored project.
Key Personnel
All individuals who contribute in a substantive, measurable way to the scientific development or execution of the project
or protocol, whether or not salaries are requested (NIH definition).
Key Person
A named contributor (other than the PI) who is integral to the proposed sponsored project, or who makes a significant
contribution to the scientific development or execution of the project, including Consultants (if applicable) and mentors
on Career awards. This includes Key Personnel and Other Significant Contributors as defined by NIH and Grants.gov.
Keyword
A term that describes the discipline of a sponsored project (e.g. sustainable agriculture, children's literature, etc.).
Kuali
(ku-wah-lee) 1) kitchen wok - humble utensil which plays an important role in a successful kitchen, 2) Kuali
Financial Systems - insanely fine, collaboratively developed, modular financial information system for higher education,
3) Community sourced development effort for distributed services in higher-education, including:
-Kuali Financial Systems (KFS)
-Kuali Endowment Module (KEM)
-Kuali Research Administration (KRA)
-Kuali Enterprise Workflow (KEW)
-Kuali Nervous System (KNS)
-Kuali Enterprise Notification (KEN)
Layman Abstract
written in less technical language than the proposal narrative. See also: Proposal Abstract, and Technical Abstract
Lead Unit
The designated unit responsible for the application and administration of the proposed sponsored project.
Location
The name of performing sites and subcontract locations where the proposed sponsored project will occur.
Maintenance Document
An eDoc initiated to create or modify, i.e., "maintain", a Kuali table record. Maintenance documents can be initiated
from the Menu for a large variety of attributes, e.g., Agency, Proposal Type, etc.
Modification ID
The modification ID as it appears on the sponsor award instrument.
MTDC
Modified Total Direct Cost. The aggregated direct costs for a given University activity, such as organized
research, excluding certain costs specified by A-21. Costs excluded from MTDC include, but are not limited to,
equipment, capital expenditures, tuition remission, stipends, and that portion of a subcontract in excess of $25,000.
Multiple Pis
An applicant organization may designate multiple individuals as PD/PIs who share the authority and responsiblity for
leading and directing the project, intellectually and logistically. Each PD/PI is responsible and accountable to the
applicant organization, or, as appropriate, to a collaborating organization, for the proper conduct of the project or
program including the submission of all required reports. (See Contact PI).
Name/Organization
The sponsor or sponsor's representative.
NIH
National Institutes of Health. A federal agency that sponsors biomedical research and training, conducts research in its
own laboratories and fosters communication of medical information. http://www.nih.gov\\
The mechanism used to communicate information about the funding opportunity for this project. Examples include
federal solicitations (e.g. RFP, RFA, PA), nonfederal solicitations, unsolicited proposal, verbal request, etc.
NSF
National Science Foundation. A federal agency that sponsors fundamental research in science and
engineering and also supports science education. http://www.nsf.gov/
NSF Science Code
A numeric code that is used by the institution to indicate a field of research activity, as defined by the NSF. For
example, the NSF science code for Chemical Engineering is 012. These codes are important when an
institution compiles data for the NSF Annual Survey, and for other annual reporting exercises.
Obligated Total (or Amount)
The amounts obligated by the sponsor to date under the award. This does not include cost share. The Obligated Total
must be equal or less than the anticipated total.
Obligation End Date
The end date of the current funding period. It must be the same as or earlier than the final expiration date.
Obligation Start Date
The effective date of the current funding period. It must be the same as or later than the award effective date.
OHRP
Office for Human Research Protections. The HHS Office for Human Research Protections (OHRP)
supports, strengthens and provides leadership to the nation's system for protecting volunteers in research that is
conducted or supported by the U.S. Department of Health and Human Services (HHS). OHRP provides clarification and
guidance to research institutions, develops educational programs and materials, and promotes innovative approaches to
enhancing human subject protections. (http://www.hhs.gov/ohrp/)
In addition, OHRP is the lead federal agency for the Common Rule (45 CFR 46 Subpart A) that is used by most federal
agencies for protecting volunteers in research that is conducted or supported with federal support.
On/Off Campus
Indicates whether a rate applies to on campus use or off campus use.
Opening Date
The date a user may begin submitting grant application packages, under a specific funding opportunity/program.
Opportunity ID
The unique identifier associated with each sponsor's funding opportunity. Equivalent to Funding Opportunity
Announcement (FOA).
Opportunity Title
The Opportunity Title is a sponsor assigned brief descriptive heading of the program solicitation or funding opportunity.
Not all programs have Opportunity Titles. (AKA Program Title or Program Annoucement)
Original Proposal ID
The number assigned by KRA Proposal Development module for the previously submitted proposal record currently
being revised.
Other Significant Contributor
Individuals who have committed to contribute to the scientific development or execution of the project, but are not
committing specified measurable effort (e.g. mentors on Career awards) (NIH definition).
Overhead
See F&A Facilities and Administration
Paid Member
A member of an IRB, IACUC, IBC, or other regulatory compliance committee who is compensated for participating in
the activities of the regulatory compliance committee. While the member is most frequently an unaffiliated member of a
regulatory compliance committee, they may be affiliated if allowed under institutional policy.
Payment Type
The payment structure of the sponsored award. For example: Cost Reimbursement, Fixed Price, etc.
Payment Method
The mechanism for obtaining payment as required by the sponsor. For example: Federal Letter of Credit, Automatic
Scheduled Payment, Cost Invoice, etc.
Percent (%) Effort
The time/effort that the Investigators, and/or other personnel, are committing to the sponsored project. This must be the
proportion of time in relation to all institutional commitments and obligations. The total effort cannot exceed 100% for
all sponsored projects and work-related duties.
Performing Organization
The organization where the majority of the proposed sponsored project will take place.
PI
Principal I nvestigator. The individual bearing primary responsibility for all essential aspects of the
project or protocol, including programmatic work, compliance with government, sponsor and university policies and
regulations, fiscal stewardship of sponsored funds, and all administrative requirements of the project.
Alternate: See Principal Investigator (Delete definition and Remove complete spelling of Principal Investigator in
column to left and list as just "PI")
Pre-award Costs
Grantee may, at its own risk incur obligations and expenditures to cover costs prior to the begin date of the initial budget
period. Depending on the sponsoring agency, prior sponsor approval may be required for pre-award costs.
Pre-award Authorized Amount
The amount authorized to be spent during a pre-award period.
Pre-award Effective Date
The start date for the incurrence of pre-award costs.
Prime Sponsor
The organization that funds a sponsored project, and is the original source of funds.
Prime Sponsor ID
The internal reference ID of the organization that funds the sponsored project.
Principal Investigator
The Principal Investigator/Project Director/Program Director (PI/PD) is the individual designated by the grantee, and
approved by the sponsoring agency, who will be responsible for the scientific or technical direction of the project. If
more than one, the first one listed will have primary responsiblity for the project and the submssion of reports. All others
listed are considered co-PI/PD, and share in the responsiblity of the scientific or technical direction of the project. The
term "Principal Investigator" generally is used in research projects, while the term "Project Director/Program Director"
generally is used in education, and service projects. For purposes of this glossary PI/co-PI is interchangeable with
PD/co-PD.
Principal Investigator- Contact
See Contact PI
Principal Investigator-Multiple
See Multiple PIs
Program Announcment
See Opportunity Title
Project Director
Program Director
Program Title
See Opportunity Title
Project End Date
The expiration date of the currently proposed/funded period, plus unfunded periods (this may include possible option
years).
Project Start Date
In the Proposal Module, this is the requested project start date for the project in the proposal. In the Award Module this
becomes the project period start date as reflected in the sponsor award instrument. These two fields may not be the
same.
Proposal
To propose, make an offer. A proposal is a written document developed by an individual or a group for
presentation to an outside organization. Ideas for possible research or services are put forward to agencies/sponsors for
their review and consideration. If the ideas proposed to the agency/sponsor are favorable to both parties involved, an
award agreement would be initiated granting the researcher a designated dollar amount for use in their outlined mission.
Alternate: A formal written document provinding detailed information to a potential sponsor on the technical and
business aspect of a proposed project. A proposal may be unsolicitated or in response to a specific funding
announcement. the successful outcome of a proposal will result in an award to the institution.
Proposal Abstract
the objectives, expected outcomes, including significance of the project to the field being studied. There may also be
sponsor specific requirements as listed in the program announcment or application instructions. See also: Layman
Abstract, and Technical Abstract
Proposal Development Document
The proposal development document represents a series of pages that enable the user to create an electronic version of
the proposal. These pages will accommodate all the information required by the sponsor and the institution for a full
proposal submission.
Proposal Rights
The specific accesss to various components of the Proposal Development module allowed to a user based upon the
Proposal Pole. See Proposal role.
Proposal Role
The role assigned to an individual user of the KRA Proposal Development module. This defines the level of access to the
different parts of the system (e.g. aggregator, viewer, budget creator, etc.). See Proposal Rights.
Proposal ID
The unique number assigned by KRA Proposal Development module when a proposal is created and saved.
Protocol
The protocol or protocol application is institution specific and is developed by the Compliance Committee to take into
consideration federally mandated criteria as well as local institutional policies and practices in proposed research and to
be able to assess the risk/benefit ratio for the proposed project. As it relates to protecting human participants, the protocol
is more specific than the proposal and they may or may not be tied together. At almost all institutions, there is a many to
one and a one to many relationship between the protocol and the proposal. (Reference R Amdur and E. Bankert.
Institutional Review Board - Management and Function. Boston: Jones and Bartlett Publishers, p. 143.)
Protocol ID
A unique number assigned by the institution and/or compliance committee to a specific research Protocol.
Radioisotopes
Chemical variants of radioactive elements with potentially oncogenic, teratogenic, and mutagenic effects on the human
body. (http://www.epa.gov/OCEPAterms/rterms.html)
Rate Type
The type of rate that the system applies to spcific cost elements (i.e. fringe benefits, F&A, inflation, etc)
Recombinant DNA
The new DNA that is formed by combining pieces of DNA from different organisms or cells.
(http://www.epa.gov/OCEPAterms/rterms.html)
Renewal
A proposal and/or award that has not been previously committed (competing request for additional funding).
Revision Type
A change in a sponsor's financial obligation or contingent liability of an existing award. For example, the NIH uses the
following revision types: (1) Increase award (2) Decrease award (3) Increase duration (4) Decrease duration and (5)
Other.
Salary Effective Date
The date of the employee's annual increase.
Schema URL
The URL address that links to the program's federally funded schema provided by the sponsor and available for
download from the Grants.gov link. Defines the required and optional forms for each funding opportunity. Form
schemas are included by reference in the opportunity schema.
Schema
A way to define the structure, content and, to some extent, the semantics of XML documents.
Sequence ID
The identification number assigned by the system based on the rules of the institution. The sequence number is
increased with each award new entry.
Source Account
The account that details the cash resources that will be used to cover the expenses that will post in the Destination
account.
Space Change
Space Change is a KRA Special Review option in the proposal module which indicates a change in space requirements
needed for the proposal.
Special Review
Sponsor
The organization or agency that is providing support for the sponsored project.
Sponsor Award ID
The sponsor reference ID as it appears on the sponsor award instrument.
Sponsor Div Code
A code that is unique to each NSF division and required for NSF proposals. Currently this code is specific to the NSF
only.
Sponsor Hierarchy
A recognized relationship among a group of sponsors that is defined within the system. Will frequently be used to allow
a roll-up of sponsors into a single group for reporting purposes. For example each NIH Institute may be listed as a
separate sponsor and a administrative organization hierarchy will allow data to be collected across NIH.
Sponsor Program Code
A code that is unique to each NSF program and required for NSF proposals. Currently this code is specific to the NSF
only.
Sponsor Proposal ID
The sponsor assigned identifier for a proposal.
Sponsor Template
The standard terms and conditions associated with a specific sponsor award program.
Start Date
In the KRA budget module, this is the date for which a rate becomes effective.
Subaward
A financial assistance agreement, which transfers a substantive effort of the project, issued to a sub-recipient when the
prime award mechanism is a GRANT or COOPERATIVE AGREEMENT. Generally subject to prime agency flow-
through terms & Conditions and OMB circular regulations.
Subcontract
A formal agreement issued to a sub-recipient when the prime award mechanism is a CONTRACT. A subcontract is
generally subject to state & federal contract/procurement law such as FAR clauses.
Submission Type
The type of grant application package/proposal submitted. For example, types of submissions include: (1) Pre-
application (2) Application (3) Changed/Corrected Application
Sub-plan
A subcontracting plan established on all Federal or Sub-Federal contracts over $550,000.00 which must be analyzed to
determine what portion of the purchases against this contract can be awarded to Small, Disadvantaged or Women-Owned
Businesses. FAR 52.219-9
Technical Abstract
the objectives, expected outcomes, including significance of the project to the field being studied. See also: Proposal
Abstract, and Layman Abstract
Technical Report
The technical report(s) required to be submitted to the sponsor.
Term
See Committee Member Term of Appointment
Title
The project title as it appears on the sponsor award instrument.
Unrecovered F&A
F&A costs which are not requested or provided by the sponsor. See F&A.
Vertebrate Animal
The term "animal" means any live or dead dog, cat, monkey (nonhuman primate mammal), guinea pig, hamster, rabbit,
or such other warm-blooded animal, as the Secretary may determine is being used, or is intended for use, for research,
testing, experimentation, or exhibition purposes or as a pet; but such term excludes horses not used for research purposes
and other farm animals, such as, but not limited to livestock or poultry, used or intended for use as food or fiber, or
livestock or poultry used or intended for improving animal nutrition, breeding, management or production efficiency, or
for improving the quality of food or fiber. With respect to a dog the term means all dogs including those used for
hunting, security, or breeding purposes (Animal Welfare Act) Any live, vertebrate animal used for or intended for use in
research, research training, and biological testing or for related purposes. (PHS Policy on Humane Care and Use of
Laboratory Animals).
Vulnerable Participants
Participants whose willingness to volunteer in a research protocol may be unduly influenced by the expectation, whether
justified or not, of benefits associated with participation, or of a retaliatory response from senior members of a hierarchy
in case of a refusal to participate. Participants may be vulnerable based upon the class of individuals in which they may
permanently or temporarily be associated. Additional safeguard are (1) always given to selected classes (prisoners,
individuals kept in detention facilities, children, and neonates), (2) sometimes given to selected classes when they are the
focus of the research (pregnant women and human fetuses) by federal regulations. The IRB may also require additional
safeguards to others groups based upon the details of the proposed research protocol. These may include patients with
incurable diseases, individuals with deminished capacity or incapable of giving consent, persons in nursing homes,
unemployed or impoverished individuals, patients in emergency situations, ethnic minority groups, homeless persons,
nomads, refugees, military, "normal volunteers" etc.
workflow / Workflow Services / Kuali Enterprise Workflow (KEW)
The Kuali infrastructure service that electronically routes an eDoc to its approvers in a prescribed sequence, according to
established business rules based on the eDoc content.
Workgroup
A group of users designated for eDoc routing that share a common business function. EDocs may be routed at any point
in their approval to individuals or workgroups. Workgroup approvals may require approval of all workgroup members or
any one member.
45 CFR 46
Federal regulations that apply to all research involving human participants conducted, supported or otherwise subject to
regulation by any federal department or agency. Subpart A is the Common Rule that applies to all research funded by
any federal department or agency while Subpart B "Additional Protection for Pregnant Women, Human Fetuses and
Neonates Involved in Research", Subpart C "Additional Protections to Biomedical and Behavioral Research Involving
Prisoners as Subjects", and Subpart D "Additional Protection for Children Involved as Subject in Research" only apply
to research supported by HHS or other federal department or agency that specifically chooses to abide by them. Many
academic institutions apply 45 CFR 46 to all research conducted at their institution regardless of the source of support.
See also Common Rule.
Kuali Research Administration v.1.0 User Guide 439
Scott R. Cooley
Digitally signed by Scott R. Cooley
DN: cn=Scott R. Cooley, o=Kuali Foundation, ou=Michigan State
University, c=US
Date: 2008.07.20 16:13:46 -04'00'
Reason: I am the author of this document
Location: cooleys2@msu.edu; (517) 432-6670 x.310 Signature Not Verified

KRA 1.0 User Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

KRA 1.0 User Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Kuali Research Administration v.1.

Das könnte Ihnen auch gefallen