KFS Overview Master

Kuali Financial System
Overview
Version 3.1
January 30, 2010
The Kuali Foundation
This manual was produced using ComponentOne Doc-To-Help.™
Contents
Introduction.................................................................................................................................1
Kuali Communities Overview....................................................................................................2
About the KFS User Documentation..........................................................................................7
Organization and Conventions.....................................................................................8
User Support Information...........................................................................................12
Caveats about Using this Documentation...................................................................13
Copyright and Licensing.............................................................................................17
Key Kuali Components.............................................................................................................24
Kuali Nervous System (KNS)....................................................................................25
Kuali Enterprise Workflow (KEW)............................................................................26
Kuali Financial System (KFS)....................................................................................27
KFS Architecture......................................................................................................................28
E-Docs........................................................................................................................29
General Ledger (G/L).................................................................................................30
Decision Support........................................................................................................31
KFS Modules............................................................................................................................32
Chart of Accounts (COA)...........................................................................................33
Vendor........................................................................................................................34
Purchasing and Accounts Payable (PURAP).............................................................35
Pre-Disbursement Processor (PDP)............................................................................36
Capital Asset Management (CAM)............................................................................37
Accounts Receivable (AR).........................................................................................38
Contracts and Grants (C&G)......................................................................................39
Effort Certification......................................................................................................40
Labor Distribution......................................................................................................41
Navigating through the KFS.....................................................................................................42
Screen Elements..........................................................................................................43
Logging on and off the KFS.......................................................................................47
KFS E-Doc Fundamentals........................................................................................................48
E-Doc Screen Layout..................................................................................................49
Standard Tabs.............................................................................................................62
Basic E-Doc Operations.............................................................................................78
Workflow: Overview and Key Concepts..................................................................................89
KEW Overview..........................................................................................................90
Route Levels and Workflow Routing.........................................................................91
Accounting Line Import Templates........................................................................................124
Links to Default Data Import Templates..................................................................126
Process Overview.....................................................................................................131
AD_CR_CCR_DV_SB_Import.xls..........................................................................135
AV_Import.xls..........................................................................................................136
BA_YEBA_Import.xls.............................................................................................137
DI_YEDI_IB_TF_YETF_PE_Encumbrance_Only_Import.xls...............................139
GEC_YEGEC_Import.xls........................................................................................140
ICA_Import.xls.........................................................................................................141
JV_Ext_Encumbr_Import.xls...................................................................................142
JV_NonOffset_Bal_Type_Import.xls.......................................................................143
KFS v. 3.1 Overview Contents · v

JV_Offset_Bal_Type_Import.xls..............................................................................144
LLJV_Import.xls......................................................................................................146
ND_Import.xls..........................................................................................................148
PE_Disencumbrance_Only_Import.xls....................................................................149
PURAP_Item_Import.xls..........................................................................................150
PURAP_Account_Import.xls...................................................................................151
CAM_MPAY_Account_Import.xls..........................................................................152
General Ledger (G/L)..............................................................................................................153
General Ledger G/L Process.....................................................................................154
Sufficient Funds........................................................................................................189
Flexible Offset..........................................................................................................191
Year-End Processes..................................................................................................194
G/L Correction Process (GLCP)...............................................................................210
Accounting Cycle Files.............................................................................................211
Index........................................................................................................................................215
vi · Contents KFS v. 3.1 Overview

Introduction
This overview provides an introduction to the Kuali community, the Kuali Financial System (KFS) user documentation,
and the foundation's documentation copyright practices. It also provides an overview of the KFS, including its
components, the common characteristics of KFS screens, and instructions for performing common operations.
This overview is only one of several types of help/documentation on using the KFS. Both
online help and downloadable files (for The Guide to the KFS Main Menu, The Guide to
the KFS Maintenance Menu, and The Guide to the KFS Administration Menu) provide
information about using the functions on the KFS main menu, maintenance menu, and
administration menu, respectively.
KFS v. 3.1 Overview Introduction · 1

Kuali Communities Overview
As an introduction to the Kuali Financial System (KFS) documentation, it is important that you understand how KFS is a
part of a larger community.
Figure 1 - Kuali communities overview
The KFS is a higher-education, community-source software project that is merely a spoke in the wheel of the larger
Kuali Community. The Kuali Community is the hub of a wheel of a growing number of communities, each of which are
made up of people and functions. Together they are creating a comprehensive suite of open, modular and distributed
administrative software systems that combine the proven functionality of legacy applications with the ease and
universality of online services. The Kuali Foundation serves all of these communities and assumes specific
responsibilities related to keeping the wheel in motion.
Each individual community shares a similar organizational structure and some modular functionality while its
components stand alone to perform unique functions. All of these communities are designed for seamless integration
with each other, yet each project is made up of modules that provide a variety of implementation combinations to suit
any Carnegie-class institution's unique business needs.
Table 1 Kuali communities overview
Community Name Personnel Functions
Kuali Kuali Board of Collaboration infrastructure, copyright holding,

Community Foundation Directors, Partner licensing, resource planning, licensing,
(KF) Institutions, documentation, bug tracking, legal services, user
2 · Kuali Communities Overview KFS v. 3.1 Overview

Commercial support
Affiliates,
Technical Council
Financial Kuali Financial Project Board, Financial transactions, General Ledger, Chart of
Community System (KFS) Project Accounts, reporting/decision support, contracts &
Management, grants, vendor, purchasing/accounts payable, labor
Functional distribution, effort certification, budget, accounts
Council, receivable, capital assets
Development
Teams, Subject
Matter Experts
Research Kuali Project Board, Proposal development, budget development,

Community Research Project routing form, grants.gov integration, institutional
Administration Management, review board (IRB) / human subjects, awards,
(KRA) Functional conflict of interest
Council,
Development
Teams, Subject
Matter Experts
Kuali Kuali Rice Development Kuali Nervous System (KNS), Kuali Service Bus
Infrastructure (KR) Team (KSB), Kuali Enterprise Notification (KEN), Kuali
Community Enterprise Workflow (KEW), Kuali Identify
Management (KIM)
Endowment Kuali Project Board, Investment tracking & reporting, investment

Community Endowment Project participation (endowment and non-endowment)
Management Management, Management and reporting, including unitized
(KEM) Functional transaction, budgeted and actual income projections
Council, (pooled funds and separately invested holdings),
Development access to donor instructions, manage available
Teams, Subject funds with searchable data elements describing the
Matter Experts terms of use.
Student Kuali Student Functional Person, time, learning unit, learning result, learning
Community (KS) Steering plan, learning resources, concierge
Committee,
Technical
Steering
Committee
KFS v. 3.1 Overview Kuali Communities Overview · 3

Figure 2 - The organization of Kuali
The following list provides a brief description 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
Foundation's 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. The Council implements sustainable practices that
ensure software quality by achieving an effective balance between sound architecture and the meeting of project
deadlines and functional requirements.
 Project Boards: Provide management and oversight of the business and affairs of projects, including
management of assets and resource allocation. The Board of Directors for a Kuali community project
establishes and maintains the coordination processes needed to support the development and release of the
Kuali software. Further, the project boards act as a 'court of final appeal' for discussions, work groups, and
collaborative member activities of the project.
 Functional Councils: Provide overall project guidance related to the identification and prioritization of
business practices and functional requirements 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.
 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 thato developers can react to end-user business
requirements efficiently and produce high-quality business applications. Based on Service Oriented
Architecture (SOA) concepts, 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.' Together these functions
provide a re-usable development framework that encourages a simplified approach to developing true business
functionality as modular applications.
 Kuali Research Administration (KRA): Delivers a means to administer your institution's research
information, improve access to this information, and enhance support for research compliance. Based on the
functionality of MIT's 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 Revi5$Ä6}H5‚mˆd5½~5¼5!E55ºîü55@™ZG'è

 ®$µ
 ª6PÁÀöIAæ@P¶€ã566 Institute Proposal / Negotiations, Report Tracking, Subcontracts, Cost Share

Commit6$Ä6}H6‚mˆd6½~
6!E6 ¡ü66@æ
G'è

 ®$µ
 ª7PÁÀˆIAæ@P¶€$Œ77 recipient Monitoring, Export Controls / ITAR Management, and Chemical Tracking
System.
 Kuali Endowment Management (KEM): Provides a means of accounting for your institution's 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): Supports 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 include 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 p7$Ä6}H7‚mˆd7½~7f7!E77dý77@w°G'è

 ®$µ
 ª8PÁÀ

 ÙIAæ@P¶€ZY99urces (instructors, classrooms, equipment). The concierge function is a self-service
information-sharing system that aligns information with needs and tasks to accomplish goals. Support for
integration of locally-developed processes provides flexibility to accommodate any institution's needs.
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 University's 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 (G/L),
Chart of Accounts, reporting/decision support, post-award contract administration, purchasing/accounts payable, labor
distribution, budget, accounts receivable and capital assets. A key component of the KFS is an 'electronic document' (e-
doc) environment in which electronic documents are initiated on a personal computer, electronically routed through an
approval process, and eventually passed to the General Ledger. KFS is important to those who use and process financial
information for a variety of reasons. It reduces paper proce9$Ä6}H9‚mˆd9½~9t9!E99r‚ü99@£G'è

®$µ
ª10PÁÀwIAæ@P¶€\1010 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 creates audit
trails.

About the KFS User Documentation
The Kuali Financial System (KFS) is a community-source software application system developed by and for higher
education institutions to serve their financial software needs. The purpose of KFS user documentation set is to provide
high-quality descriptions of how the software system interacts and performs with manual procedures in order to
appropriately respond to business events. It is aimed at not only providing user guides and online help for implementing
institutions, but also providing a basis for training new system users. The documentation contains detailed descriptions
of the functionality of each component of the application, so it may serve as a reference for users who are already quite
familiar with financial business rules and web-based software.
The audience is all users of KFS, but the focus is on standard end-users rather than those involved in configuration and
maintenance. Administrator and superuser functions are 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 KFS technical documentation
resources that are accessible from www.kuali.org. Additionally, these users may refer to technical documentation on the
KFS wiki (http://test.kuali.org/confluence) 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 only the maintenance documents
used for maintaining reference tables used in system administration.
TOPICS
Organization and Conventions 8

How the Organization Suits the Subject Matter & Corresponds to the Software Design...........9
Icons and Symbols....................................................................................................................10
Typographic Conventions.........................................................................................................11
User Support Information 12
Caveats about Using this Documentation 13

Screen Images and Test Data....................................................................................................14
Institutional Business Processes and KFS Implementation......................................................15
Configurable Values.................................................................................................................16
Copyright and Licensing 17

Software Licensing...................................................................................................................18
Contributor Licensing...............................................................................................................19
Third Party Contributions.........................................................................................................20
Documentation Licensing.........................................................................................................22
KFS v. 3.1 Overview About the KFS User Documentation · 11

Organization and Conventions
This help documentation is designed to help you use the system efficiently by providing information about:
 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, so you can readily locate
specific information.
All KFS 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 KFS, you can
use this as a valuable guide to permforming less common tasks and as a source of information should you experience any
difficulties.
12 · About the KFS User Documentation KFS v. 3.1 Overview

How the Organization Suits the Subject Matter &
Corresponds to the Software Design
Wherever possible, the organization of this help documentation mirrors that of the software application's user interface.
In order to reduce the required effort for documentation maintenance, the documentation does not repeat material across
various chapters. Topics are designed to cross-reference each other to reduce redundant information within procedural
topics and give you one location for information lookup.
Figure 2 - KFS user documentation topic information architecture
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.

Icons and Symbols
The following icons are used throughout this user documentation to call your attention to pieces of textual information
and statements that fall into four categories.
Table 3 Purpose of icons in KFS documentation

Icon
Description
Note/Important/FYI
Cross-reference/Link/ Internal or External
Hyperlink
Suggestion/Concept/Hint/Tip/Idea
Caution/Warning/Error

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. Field names are also displayed in boldface type and are displayed exactly as they are on the KFS screens.
Sequential tasks are numbered, notes and action results are indented, and user interface element references are typically
formatted with the first initial capitalized to enhance readability. Mouse pointer icons and callouts are used frequently to
show you what to click on at each process step.

User Support Information
'The Kuali Foundation is not your vendor.' - Brad Wheeler
The Kuali Foundation does not have a large staff that does the work of a software vendor, including produce
documentation. It does, however, assist with coordinating the sharing of documentation. Similarly, it does not serve as a
corporate help desk, but instead provides access to online collaboration tools that allow implementing institutions and
end users to help each other.
Documentation Wiki: https://test.kuali.org/confluence/. Even though Kuali software is carefully designed to be easy to
use without the assistance of documentation, it is nonetheless delivered with high-quality documentation in the form of
integrated online help, printable user guides, functional specifications, technical design, and installation/implementation
documentation. All of these materials are accessible via the Kuali Confluence wiki.
Online Collaboration (Community Documentation 'Remixing' and Sharing): https://collab.kuali.org/xsl-portal.

Implementing institutions and user community members take the delivered, project-specific documentation, 'remix' it
based on their unique implementations, and contribute it to the Community so others may take advantage of it. The Kuali
Collaborative Learning Environment is where this sharing occurs. It also provides important mailing lists, news, and
event subscription services.
Commercial Affiliate Documentation & Support: http://www.kuali.org/support/. Commercial affiliate community

members may also produce customized documentation to accompany the customized Kuali software and/or hardware
they sell along with the implementation-related services they provide to their clients. The Kuali web site offers an index
to these firms and links to their contact information.
To contact the Kuali Foundation, see http://www.kuali.org/contact.

Caveats about Using this Documentation
This documentation is specific to the 'out-of-the box' version of KFS 3.0, and this out-of-the-box version and your
institution's version of KFS may differ in important ways. Consequently, this documentation will not necessarily
accurately reflect what you see on your screens, the way your institution uses KFS, or your institution's unique
configuration of it.

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 KFS
Implementation
Various components of KFS modules contain functions that are configurable prior to implementation, based on
individual institutional business processes. KFS 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 configurable, and an institution implementing KFS 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 differ from those in use at your institution, depending on the institution's
configuration decisions.

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
Copyright © 2005-2009 by The Kuali Foundation, Incorporated. All rights reserved. Kuali is licensed for use pursuant to
the Educational Community License (ECL), Version 2.0 ('the License,' the full text of which can be found at:
http://www.opensource.org/licenses/ecl2.php). You may not use these files 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
Portions of Kuali are copyrighted by other parties, including the parties listed below. Refer to the licenses directory for
complete copyright and licensing information. Questions about licensing should be directed to license@kuali.org.
Copyright 2009 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. For complete copyright and licensing information, refer to the licenses directory
(https://test.kuali.org/confluence/display/KULFOUND/Licensing).

Third Party Contributions
Portions of Kuali were developed by Indiana University, Cornell University, University of Hawaii, Michigan State
University, University of Arizona, San Joaquin Delta Community College, University of California, University of
Southern California, and The rSmart Group.
Refer to: https://test.kuali.org/confluence/display/KULFOUND/3rd+Party+Licenses for the most detailed, up-to-date

information.
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 SAXPath Project (http://www.saxpath.org/).
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).
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) 1995-2006 International Business Machines Corporation and others. 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) 2003-2006 The Werken Company. All Rights Reserved. (http://jaxen.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/)
Portions Copyright (c) 2002-2005, Jonas Bon?r, Alexandre Vasseur. All rights reserved.
Portions Copyright (c) 1998-2003 World Wide Web Consortium (Massachusetts Institute of Technology, European
Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. This work is distributed
under the W3C® Software License in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Documentation Licensing
Copyright  2006-2009 by The Kuali Foundation. Some rights reserved.
Kuali Financial System 3.0 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 author's
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.

Key Kuali Components
'Kuali' is an umbrella of applications development, under which smaller applications known as modules are developed to
support end-user tasks. Modules are portions of larger programs that carry out specific functions. They may be
implemented alone or combined with other modules.
The KFS's modular architecture allows institutions to implement only the functional elements they need. In this way, the
KFS can be scaled to meet the needs of institutions of any size.
Currently falling under the Kuali umbrella are the Kuali Nervous System (KNS), which encompasses infrastructure
components, and the Kuali Enterprise Workflow (KEW), which automates routing of electronic documents (e-docs) for
approval according to specified business rules. The core system is comprised of Rice (which includes KEW), Chart of
Accounts, Financial Processing, General Ledger, Pre-Disbursement Processing, and Vendor modules. These are
considered 'core' modules because they depend on one another, while non-core modules and their components depend on
the core because these core modules are necessary for other functional modules to operate.
Specifications are available for institutions to develop their own interfaces to the core system modules. Any dependency
of one non-core component on another non-core component is flexible, which allows your institution to implement
unique combinations of subsets via parameterization and service interface definition to meet institutional users' needs.
TOPICS
Kuali Nervous System (KNS) 25
Kuali Enterprise Workflow (KEW) 26
Kuali Financial System (KFS) 27
28 · Key Kuali Components KFS v. 3.1 Overview

Kuali Nervous System (KNS)
The KNS is the underlying infrastructure code that any KFS module may employ to perform its functions. The 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.
KFS v. 3.1 Overview Key Kuali Components · 29

Kuali Enterprise Workflow (KEW)
The Kuali Enterprise Workflow (KEW) is a general purpose, content-based electronic routing infrastructure or workflow
engine. Client applications use the KEW to automate and regulate the routing and approval processes for the
transactions/documents they create. Worflow starts with an e-doc that users compose in a client application such as the
KFS or another Web application that requires routing and approval of documents. The KEW electronically routes the e-
doc to designated individuals and groups for approval in a prescribed sequence, according to established university or
departmental business rules and policies based on the e-doc's content.
The KEW streamlines mediated business processes across the enterprise. Via the KEW centralized routing system, users
can access and search for many types of e-docs from various client applications, such as HR, Purchasing, Travel,
Research Administration, Timekeeping, etc.
Accessing the appropriate documents is accomplished from a single location that provides both action list and doc
search buttons. The Route Log for each document allows users to follow its progress.
For more information about KEW, see Workflow: Overview and Key Concepts.
30 · Key Kuali Components KFS v. 3.1 Overview

Kuali Financial System (KFS)
The Kuali Financial System (KFS) 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). KFS
includes a base system of these modules.
 Chart of Accounts: controlling tables that define financial information.
 General Ledger (G/L): repository of all financial and budget information.
 Financial Transactions Processing: allows account managers and organizations to transact financial business
through electronic means, rather than by using paper forms.
 Reporting/Decision Support: allows account managers and others to access financial information and provide
tools to assist in the analysis of the financial information.
Additional modules may be implemented when institutions identify a need. These modules include: Accounts
Receivable, Budgeting, Capital Asset Management, Endowment, Enhanced Decision Support/Reporting, Labor
Distribution, Purchasing/Accounts Payable, and Post-Award (Contracts and Grants).
KFS v. 3.1 Overview Key Kuali Components · 31

KFS Architecture
The three main components of the KFS archetecture are electronic documents (e-docs) in which users initiate and update
financial data; the General Ledger (G/L), where financial data is stored; and decision support, which enables users to
retrieve data from the G/L.
Figure 3 - Three main components of the KFS
TOPICS
E-Docs 29
General Ledger 30
Decision Support 31
32 · KFS Architecture KFS v. 3.1 Overview

E-Docs
In the KFS, department personnel initiate a transaction from their desktop Web browser. This transaction is called a
document (often called an e-doc or electronic document). The initiator receives immediate feedback on the validity of the
document both in light of the appropriateness of data and the compliance with business rules. The KEW routes a valid
document to one or more designated approvers based on the type and content of the transaction. Fully approved
transactions are sent to the General Ledger at a later time.
Anyone who initiates, reviews or approves financial transactions may be a user of an e-doc, including:
 Departmental support staff, professional staff, and faculty
 Fiscal officers and delegates
 Contracts and Grants principal investigators
 Deans, directors, and department chairs
 Administrators
KFS v. 3.1 Overview KFS Architecture · 33

General Ledger (G/L)
The G/L is the official repository of all the university's financial and budget information. It stores account balance and
budget information for multiple fiscal years as well as detailed records of all financial transactions. Whenever a financial
transaction in an e-doc is fully approved, it is recorded in the G/L and affects balances.
34 · KFS Architecture KFS v. 3.1 Overview

Decision Support
Decision support is a collection of online services that provide access to the data within the KFS. Decision support
includes inquiries and reports available in the KFS. You can use decision support to:
 View account budgets, balances, and individual transactions.
 Retrieve standard reports such as Account Status or Account Transaction Listing.
 Generate pre-defined or custom reports from financial and system data.
KFS v. 3.1 Overview KFS Architecture · 35

KFS Modules
This section introduces the major software modules that constitute the KFS. These modules include Chart of Accounts
(COA), Vendor, Purchasing and Accounts Payable (PURAP), Pre-Disbursement Processor (PDP), Capital Asset
Management (CAM), Accounts Receivable (AR), Contracts and Grants (C&G), Effort Certification, and Labor
Distribution.
TOPICS
Chart of Accounts 33
Vendor 34
Purchasing and Accounts Payable (PURAP) 35
Pre-Disbursement Processor (PDP) 36
Capital Asset Management (CAM) 37
Accounts Receivable (AR) 38
Contracts and Grants (C&G) 39
Effort Certification 40
Labor Distribution 41
36 · KFS Modules KFS v. 3.1 Overview

Chart of Accounts (COA)
The Chart of Accounts (COA) is the set of tables that define the codes and coding structures within KFS, including
attributes such as accounts, organizations, and object codes. The COA exists primarily to support and validate entries
into the General Ledger (G/L). For example, transactions cannot be applied to an account in the G/L unless that account
exists in the COA. The account and other COA attributes are associated with additional attributes, such as the fund group
or organization associated with an account, or the object level that is associated with an object code. Defining these
attributes and their various relationships is how the financial structure of an institution is defined. By leveraging the
COA, your institution can organize its information to support activities such as e-doc routing, management of internal
controls, and internal and external reporting.
The KFS features a very flexible, multiple Chart of Accounts capability that can accommodate the needs of Carnegie
Class institutions, from small community colleges to large multi-campus research institutions.
KFS v. 3.1 Overview KFS Modules · 37

Vendor
The KFS Vendor module allows your institution to maintain a table to track businesses or other entities that your
institution has done or plans to do business with. The Vendor table includes all information pertinent to a vendor,
including tax ID, addresses, contacts, and other details required for the management of your institution's procurement
process.
This module also provides a lookup that allows Purchasing and Accounts Payable users to quickly identify vendor
contracts by description, by vendor, and even by payment terms.

Purchasing and Accounts Payable (PURAP)
The Purchasing and Accounts Payable (PURAP) module allows you to request materials and services, generate and
transmit purchase orders, and process invoices and credit memos received from vendors. The requisition, purchase order,
payment request, purchase order amendment, and credit memo documents use the workflow Kuali Enterprise Workflow
component for document approval followed by encumbrance, expense and liability entries in the General Ledger as
required.

Pre-Disbursement Processor (PDP)
The Pre-Disbursement Processor (or PDP) receives data from systems that need to make disbursements and outputs a
data file that can be sent to a check writer or formatted and sent to a bank for automated clearing house (ACH) direct
deposits. It can also generate ledger entries when appropriate, such as relieving liabilities when making a disbursement
against a KFS Payment Request document.
Files for processing may be created from KFS e-docs (such as the Disbursement Voucher or the Payment Request
document) or may be manually uploaded. The systems that provide these files are referred to as PDP 'customers.'
Depending on the specifications of these customers, checks and ACH deposits may be formatted in various ways before
being outputted.

Capital Asset Management (CAM)
The KFS Capital Asset Management (CAM) module allows you to track assets purchased through your institution's
financial system, assets received as gifts, and assets that have been transferred or even found. This module handles
records for both capital and non-capital assets.
CAM e-docs allow you to create, maintain, and retire asset records. Additionally, the system can create asset records
from data collected on financial transaction documents in other modules. The system also provides several documents to
assist your organization with inventory management and other aspects of managing assets.
In the KFS, the Capital Asset Builder (CAB) is the asset creation module for tracking movable capital additions.
Information from the General Ledger and the Purchasing module is pulled together in the CAB to create assets and add
payments.

Accounts Receivable (AR)
The Accounts Receivable module is used for billing non-student receivables. The module creates invoices, records
payments, issues credit memos, tracks outstanding receivables, and maintains historical data regarding customer charges
and payments.

Contracts and Grants (C&G)
The KFS supports all post-award financial requirements for contracts and grants, including indirect costs and cost share
as well as budgets and project to date balances.

Effort Certification
The KFS Effort Certification module uses a batch process to automate the creation of effort certification reports (also
referred to as effort reports). These reports certify the percentage of effort an employee worked on a particular project.
Reports route for approval and may be modified to correct the distribution of effort. After being fully approved, the
report generates salary expense transfer documents to align the Labor Ledger and General Ledger with the newly
certified effort. The fully-approved Effort Certification report serves as a permanent record detailing the distribution of
effort for the employee for a given period.
This module allows your institution to control the periods for which effort certification reports are created and the types
of employees that are included in a particular group of reports. You may also generate effort certification reports on an
exception basis, view effort certification reports still outstanding for approvals, inquire on the extracted Labor Ledger
data used to build effort certification reports, and more.

Labor Distribution
The Labor Distribution module manages the accounting aspects of compensation-related expenses such as salaries and
benefits. It includes salary transfer, benefit transfer, Labor Ledger correction process, and Labor Ledger journal voucher
e-docs. Labor distribution reports are accessed through balance inquiries.

Navigating through the KFS
After you access the KFS by typing the URL for it into your browser's address bar, you need to know where to find
information and how to navigate. This section covers these topics.
TOPICS
Screen Elements 43
Message of the Day...................................................................................................................45
Standard Data Entry, Selection, Action, and Navigation Tools................................................46
Logging on and off the KFS 47
46 · Navigating through the KFS KFS v. 3.1 Overview

Screen Elements
The KFS is organized into three menu tabs. The Main Menu tab displays the list of transactions and functions that
regular users are permitted to initiate. The Maintenance menu tab is geared towards the central administration staff who
maintain various reference tables to support field validation and lookups. The Administration menu tab displays the list
of functions that the only technical staff or super users in the functional area are likely to use.
Each menu tab is organized into multiple submenus that group similar types of functions. Each menu tab also has these
standard features:
 Workflow functionality is accessible from action list and doc search buttons in the upper-left corner of the
screen.
 A Message of the Day is displayed on the top of the screen.
 The current user is displayed on the upper right corner of the screen.
 A Provide Feedback link on the upper right corner of the screen allows anyone to report bugs, issues, and
suggestions.
KFS v. 3.1 Overview Navigating through the KFS · 47

Figure 4 - The KFS screen layout

Message of the Day
All three menu tabs include the Message of the Day at the top of the screen to quickly distribute messages to all KFS
users on-line.
Figure 5 - Message of the Day
Updating Message of the Day
If no message of the day is defined in the system, the Message of the Day area is not displayed on
the screen. To define the message of the day, initiate the Message of the Day e-doc from the
Administration menu tab. See 'Message of the Day' in the Guide to the KFS Administration Menu.

Standard Data Entry, Selection, Action, and Navigation
Tools
Online forms within this web-based software application allow you to enter and select information and to perform
actions and navigate, both within and outside the system. The following table briefly outlines the basic tools.
Table 4 Basic KFS tools

Element KFS Reference / Description
box (a.k.a. edit box, text box, or entry field): A 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.
check box (a.k.a. selection box): A 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 (a.k.a. radio button, option button): A round button used

to select one of a group of mutually exclusive options. Use a
mouse to click within the circle. The dot symbol indicates that the
option is selected.
list (a.k.a. drop-down menu, combo box, or list box): A box with
an arrow indicating a list that drops (expands) downward for
viewing (may expand upward to take advantage of available
screen real estate). Click the down arrow icon to list menu
options, and then click the text to highlight and select an option.
button (a.k.a. command button, action button): A rectangular

button with a text label that indicates the action to be performed.
Use a mouse to click the button to initiate the action.
http://www.kuali Link (external file or Web page hyperlink): Use a mouse to click
.org on the underlined text (usually blue in color) to navigate to a
different Web page or system within the same Web browser
(may open a new pop-up window).
Link: An internal hyperlink to a different place on the current

page, a different screen within the current application, or a
related system. Use your mouse to click on the underlined text to
cause the desired information to appear.

Logging on and off the KFS
When you select an item on a menu tab for the first time in a session, the KFS asks for your user ID and password. The
KFS performs user authentication and authorization to restrict access to business transactions, according to your
institution's prevailing practices.
Figure 6 - The KFS authenticates users.
After you have logged on, you are not asked to logon again until you logoff
from the system by closing the browser.
If your institution opts to integrate the user authentication with the campus
authentication system, the logon sequence may differ.
To log off from the KFS, simply close the Web browser by clicking the standard browser's Close button located in
the upper right corner.

KFS E-Doc Fundamentals
The following sections describe the page layout, common attributes of an e-doc, and basic functions.
TOPICS
E-Doc Screen Layout 49

Document Header.....................................................................................................................50
Expand All /Collapse All Buttons.............................................................................................51
Show/Hide Buttons...................................................................................................................52
Required Fields.........................................................................................................................53
Date Fields................................................................................................................................54
Standard Links and Icons..........................................................................................................55
Standard Tabs 62
Document Overview Tab..........................................................................................................63
Accounting Lines Tab...............................................................................................................65
Capital Edit Tab........................................................................................................................71
General Ledger Pending Entries Tab........................................................................................74
Notes and Attachments Tab......................................................................................................75
Ad Hoc Recipients Tab.............................................................................................................76
Route Log Tab..........................................................................................................................77
Basic E-Doc Operations 78

Initiating a Document................................................................................................................79
Copying a Document................................................................................................................80
Saving a Document...................................................................................................................82
Canceling a Document..............................................................................................................83
Closing a Document..................................................................................................................84
Routing a Document.................................................................................................................85
Using the Action List................................................................................................................86
Using Doc Search to Find a Document.....................................................................................87
52 · KFS E-Doc Fundamentals KFS v. 3.1 Overview

E-Doc Screen Layout
An e-doc consists of a document header and a document body. The document header in the upper right corner of the
screen contains system information about the document. The document body is organized in a stack of labeled tabs that
are similar to file folders. Based on the type of document, the system displays different sets of tabs. To facilitate the
document input process, an initiated document opens with required tabs expanded and optional tabs collapsed. Workflow
action buttons appropriate to your role are displayed at the bottom of the screen.
Figure 7 - Components in an e-doc
KFS v. 3.1 Overview KFS E-Doc Fundamentals · 53

Document Header
Table 5 Basic information in the document header
Title Description
Document The unique number used to identify each document. The KFS
Number assigns a sequential number to each document when it is
(Document Nbr) created, regardless of the type of document.
Status A code that identifies the status of a document within the

Workflow process.
Initiator The user ID of the document initiator.
Created The time and date the document was created.
For information about status definitions, see Route Status.
Table 6 Optional information in the document header

Title Description
Copied from The KFS allows users to create new financial documents
Document ID based on previous transactions by way of a copy function.
When one document is copied from another, the document
number of the copied document appears here.
Correct The KFS gives you the option of reversing a fully approved
Document ID financial transaction through the use of an 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 in an existing
document.

Expand All /Collapse All Buttons
You may expand or collapse all tabs in a document by clicking expand all or collapse all.
Click expand all to expand all of the e-doc tabs.
Figure 8 - Click expand all to expand the e-doc tabs.
Click collapse all to collapse all of the tabs.
Figure 9 - Click collapse all to collapse the e-doc tabs.

Show/Hide Buttons
Click show or hide on the tabs to expand or collapse an individual tab.
Figure 10 - The show and hide buttons on each e-doc tab allow you to expand or collapse the tab.

Required Fields
All required fields in an e-doc are denoted with an asterisk. You cannot submit the document until all required fields
contain data.
Figure 11 – Each required field is denoted with an asterisk.

Date Fields
Dates must be specified in mm/dd/yyyy format. Alternatively, you may select a date by clicking the Calendar and
selecting from the calendar that is subsequently displayed.
Figure 12 - Click to select a date from the calendar.

Standard Links and Icons
Since the KFS is a web-based application, hyperlinks and icons are used for navigation. Clicking hyperlinks and icons
allows you to drill down into document detail and to obtain additional information.
Figure 13 - Examples of icons
Help Icon
When you click the icon by the document title, the help screen displays the description of the screen that you are in.
Field Lookup
The round magnifying glass or 'lookup' icon allows you to look up reference table information so you avoid data entry
errors.
Figure 14 - Click the magnifying glass icon to see a list of valid values for the field.
After you click the icon, the system displays a list of valid values for you to select from or connects you to a form that
allows you to search for the value you need.
Figure 15 – Search form retrieved by clicking the magnifying glass icon
To look up valid values in this form, follow these steps:
1 Fill in one or more search criteria or all the search criteria fields blank to retrieve all.
Search criteria may be specified by:
Typing data into any combination, all or none of the listed search fields.(Most search
fields change the typed data to uppercase for the search.)
Using wildcards at the end of or within a string of characters to represent any character or

characters. The symbols * and % can be used as wildcards.
Using range operators on numbers and dates are >, <, >=, <=, or
All operators except .'.' should be before a date value.
The operator .'.' should separate date values.(Dates should be specified as mm/dd/yyyy.)
Using logical operators & (AND) and | (OR) with multiple search parameters.
2 Click search.
The KFS displays the list of applicable values that you have requested. After the
value list is displayed, you may take one of the following actions by clicking the
hyperlinks labeled a through c in the following picture.
Figure 16 - The KFS retrieves valid values in the field lookup.
(a) Click return value to select the code.
(b) Click return with no value to cancel the search (or click cancel).
(c) Click the name of a column to sort the retrieved values by that column.
Multiple Value Lookup

Documents requiring a list of values come with a special multiple value lookup screen where you may select multiple
values from the search list. The Look Up / Add Multiple xxx Lines (where xxx is the name of the attributes you are
updating) link is available in the applicable section of the tab where this feature is available.
Figure 17 - Click the lookup icon to add multiple accounts.

The Look Up / Add Multiple xxx Lines takes you 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 rightmost
column.
Figure 18 - Click return selected to return the checked items.
Click select all to select all values in the list.
Click unselect all to clear the check boxes for all values in the list.

Figure 19 - Multiple accounts have been returned.
Clicking the cancel button returns you to the tab you came from without populating the
tab.
Multiple value lookup is used in global documents and labor e-docs.
Export Options Links

To export the result of the table lookup to your local computer in CSV, Excel, or XML format, follow these steps:
1 Click the export option link for the format you want.
Figure 20 - You may export the result of the lookup.
The system prompts you. to click Open, Save, or Cancel.

Figure 21 - File Download dialogue box
2 Click one of the buttons and follow the standard prompts.
Drilldown
After you perform a search, when the system displays a link or icon in the list of retrieved data, you can 'drill down into'
(that is, display) details for any of the linked items. Standard drilldown features in the KFS include the following.

Figure 22 - The KFS has standard drilldown features.
 Document ID drilldown: (a) Clicking the Document ID link retrieves the specified document so you can view
or edit it.
 User drilldown: (b) Clicking a linked user ID takes you to a Person Impl Inquiry report.

Figure 23 - The Person Impl Inquiry report shows details about a user.
 Route Log lookup: (c) Clicking the Route Log icon takes you to the KFS Route Log for the document in
this row. The Route Log contains two tabs summarizing routing activities. The Action Taken tab logs prior
events and the Pending Action Requests tab logs known future events, from which you can see current
Workflow action requests.
Figure 24 - Clicking the Route Log icon displays routing information for a document.
For more information about the Route Log, see Route Log.

Standard Tabs
While the tabs contained in various e-docs may vary from one document type to another, a set of
s67$Ä6}H67‚mˆd67½~67–67!E6767”Jþ6767@=G'è

®$µ
ª68PÁÀäõIAæ@P¶€g6868 Document Overview, Notes and Attachments, Ad Hoc Recipients, and Route Log tabs.
Additionally, financial transactions e-docs contain the Accounting Lines tab and the General Ledger Pending Entries
tab. Another tab, Capital Edit, is included on many but not all financial transaction documents.

Document Overview Tab
The Document Overview tab identifies the document and includes fours fields—Description, Explanation, Total
Amount, and Org. Doc #.
Figure 25 - Document Overview tab
The Description field is a required field on every e-doc beause it is used to identify the financial transaction and is
included in the G/L inquiry, standard reports, action list and document search.
Figure 26 - An e-doc's description is displayed as the title in a user's action list.
The Explanation and Org Doc# fields allow you to include additional information about the document. The Total
Amount field is updated when the document is submitted successfully.
Figure 27 - Total Amount is displayed when the document is submitted.
Table 7 Document Overview tab definition

Title Description

Description Required. Enter the short description for the document. The description
appears in the GLG/L Inquiry, standard reports, action list and document
search a primary identification of the document.
Explanation Optional. Enter a more detailed explanation than the information supplied in
the description field.
Total Amount Display-only. Displays the total amount of accounting lines when the
document is submitted successfully.
Org Doc # Optional. Enter the value that may include departmental or organizational
information. This number is not the same as the Document Number
assigned by the KFS.
Other data fields may be available in the document overview of specific documents.

Accounting Lines Tab
Accounting information for a financial transaction is entered in the Accounting Lines tab. This is where the accounting
string data is entered. The required fields and the format of the tab vary slightly by document type. The Amt field may
also look different, depending on the type of document you are creating.
Single-Sided Entry
A number of documents require you to enter information onto only one side of the transaction because the balancing side
of the transaction is automatically generated by the KFS based on pre-set business rules. An example of a single-sided
entry is the Cash Receipt (CR) document.
Figure 28 - The CR document is an example of a single-sided entry.
Double-Sided Entries
Several types of documents function by placing accounts, object codes, and amount combinations in separate sections of
the Accounting Lines tab. These sections may be entitled From/To, Income/Expense, Decrease/Increase, etc.,
depending on the type of document.
In a document with From/To sections (such as the General Error Correction or GEC document), the From section of the
transaction represents a decrease in income, expense, or budget to an account. For example, when an account is entered
in the From section of a GEC document and the object code is an expense type, the transaction reduces (credits) the
expense and increases (debits) cash for that account.
The To section of this same type of transaction represents an increase in income, expense, or budget to an account. For
example, when an account is entered in the To section of a GEC document and the object code is an expense type, the
transaction increases (debits) the expense and decreases (credits) cash for this account.

Figure 29 - The GEC document is a double-sided-entry document.
Debit/Credit Entries
A document requiring both debit and credit entries has fields for both the debit or credit amount on each accounting line.
A debit and credit may not be entered on the same accounting line; only a debit or a credit may be entered on a single
line. The Journal Voucher (JV) document is an example of a document requiring debit/credit entry.
Figure 30 - The JV document has fields for the debit or credit amounts on each line.
Table 8 Accounting Lines tab definition

Title Description
Chart Required. Select the chart code from the Chart list.
Account Required. Enter the account number or search for it from the
Account lookup .
Sub-Account Optional. Enter the sub-account number or search for it from the
Sub-Account lookup .
Object Required. Enter the object code or search for it from the Object
Code lookup .
Sub-Object Optional. Enter the sub-object code or search for it from the Sub-
Object lookup .
Project Optional. Enter the project code or search for it from the Project

lookup .
Object Type Required only for the Journal Voucher document. Enter the object
type code or search for it from the Object Type lookup . This
value is auto-populated based on the object code used in the JV
document when you click add.
Organization Optional. Enter the appropriate data for the transactions.

Reference
Amount Required. Enter the amount.
Ref Origin Required only for the General Error Correction document. Enter
Code the ref origin code or search for it from the Origination Code
lookup .
Ref Number Required only for the General Error Correction document. Enter
the ref number.
Line Desc Optional in most documents. Enter a description of the transaction

line. This field is required in a few documents and is noted as
required in the help documentation for these types of documents.
Some of the above fields are not included in all documents. Specific requirements for each
document type are noted in the section for the document type.
Displaying Account Detail

Descriptions for the accounting string data may be hidden or shown by clicking show detail and hide detail. The system
displays the alternate option after you click the button.
Figure 31 - The hide detail button
Figure 32 - Clicking hide detail hides the COA titles in the Accounting Lines tab.

Figure 33 - Clicking show detail displays the COA titles in the Accounting Lines tab.
Accounting Lines Buttons

The accounting lines buttons offer the following options.
To add an accounting line to the document, click the add button. The system then validates
the account number, expiration status and business rules specific to the document type.
Figure 34 - Click add to validate accounting lines and add them to the document.
If the account number is expired, you must check the Expired Override box or enter a
different account in order to add the line.
Figure 35 - Select the Expired Override check box to use an expired account.
To delete the accounting line, click delete.

Figure 36 - Delete and bal inquiry buttons
Click the bal inquiry button to open the balance inquiry menu.
Select one of the reports by clicking the lookup icon next to the desired report title.
Figure-37 - The bal inquiry button displays the Balance Inquiry Report Menu.
For information about how to use Balance Inquiry Report Menu, see 'Decision
Support.'
Sales Tax
The KFS can be configured to require sales tax information on the selected document types as well as the account and
object code combinations. The document types and account/object code combinations are stored in two separate business
rules. When an account and object combination in the account and object code parameter is used on a document in the
document type parameter, the systems displays the sales tax line after you add the accounting line.
Figure 38 - Sales tax entry
The system does not display the sales tax line until you enter the account and object

code and click the add button.
The SALES_TAX_APPLICABLE_DOCUMENT_TYPES parameter defines the

document types that this behavior should appear on. The
SALES_TAX_APPLICABLE_ACCOUNTS_AND_OBJECT_CODES parameter
specifies the account and object code combinations thatprompt you to enter sales tax
information. For more information about business rules, see Parameter in the Guide to
the KFS Administration Menu.
Import Lines
If you have a number of accounting lines to enter, you may create a .csv file containing the transactions and import it into
the document.
For information about accessing and using the import templates, see Accounting Line
Import Templates.
Restrictions
Each financial transaction document is governed by business rules for the document type and the accounting line data.
Rules may be derived from specific attributes associated with the account, object code, or other accounting string data.
The following is a partial list of account and object code attributes that may cause restrictions on various documents.
Table 9 Attributes that may cause restrictions in entering accounting lines

Attribute Cross Edits
Account Fund Group, Sub-Fund Group, Budget Recording Level,

Effective/Expiration Date, Account Sufficient Funds, Object Presence
Control, Income Stream Account
Object Code Object Type, Object Sub-Type, Object Level, Consolidated Object
Code

Capital Edit Tab
Figure 39 - Capital Edit tab
The Capital Edit tab is included only in Cash Receipt, Distribution of Income and Expense, General Error Correction,
Internal Billing, Procurement Card, and Service Billing financial transaction documents.
This tab allows users to add a new asset or update information about an existing asset to which this transaction applies.
Information is required in this tab when the Accounting Lines tab contains an object code belonging to one of the
following object type codes:
 AM: Art & museum objects
 CF: Capital movable equipment - federally funded
 CM: Capital equipment - university funded
 CO: Capital equipment - federally or other owned
 C1: Capital lease equipment - above threshold
 C2: Capital lease equipment - below threshold
 UC: Movable fabrication - university funded
 UF: University constructed - federal funded
 UO: Movable fabrication - federally owned
Note that these object type codes are defaults, and your institution's values may vary (as defined in the parameter KFS-
CAB FINANCIAL_PROCESSING_CAPITAL_OBJECT_SUB_TYPES).
Use of this tab varies based on the business rules for each type of financial transaction.
For more information about using this tab, see the documentation on the specific type
of transaction you are performing.
The Capital Edit tab includes two sections—Retrieve Asset to be Updated and Create New Assets. Both sections are
displayed regardless of the type of transaction, but for some types of transactions only one section or the other is
appropriate.
Retrieve Asset To Be Updated Section

This section allows you to retrieve information about an existing asset in order to associate it with a financial transaction.

Table 10 Retrieve Asset To Be Updated section definition
Title Description
Asset Required when making changes to information for an asset that

Number has already been added to the data base. Enter the asset number
or select it from the Asset lookup .
Business Rules
 The asset number entered must identify an active valid asset. Active assets have an inventory status code of 'a'
(active), 'c' (active and non-accessible), 's' (surplus), or 'u' (university constructed).
 The asset number entered is locked until the financial document is approved, canceled, or disapproved.
 An existing asset may be modified only if the object code with the capital object subtype is displayed on the
From or Income portion of the Accounting Lines tab. For document types with only one section in the
Accounting Lines tab (such as the Cash Receipt or Procurement Card document), the documents themselves
may also be used to modify assets.
Process
When a financial document that modifies an existing asset is approved, the system adds a payment to the asset database
for the given asset number. Next, a batch process loads an approved financial document into Capital Asset Builder Other
G/L Transactions. Finally, the Capital Asset Office reviews the transaction and, if appropriate, applies the transaction to
the asset.
Create New Assets Section

Use this section to create a new asset record and associate the asset with a financial transaction.
Table 11 Create New Assets section definition

Title Description
Asset Required. Enter a number to indicate how many assets will be

Quantity created in the data base.
Asset Type Required. Enter the code that identifies the type of asset. You may
search for this code from the Asset Type lookup .
Vendor Name Required. Use the Vendor lookup to find the name of the
vendor from whom the asset was obtained.
Manufacturer Required. Enter the name of the asset's manufacturer.
Model Optional. Enter the model number of the asset.
Asset Required. Enter a detailed description of the asset.

Description
Action Click to add the asset or to clear the fields in this

section.

After you click add, the system displays the fields described below.
Tag Number Optional. Enter the unique identification number issued by the
university and affixed to the asset.
Serial Optional. Enter the unique identification number assigned by the

Number manufacturer to the asset.
Campus Required. Enter the code identifying the physical campus in which the
Code asset is physically located. You may search for this value from the
Campus lookup .
Building Required. Enter the code assigned to the building in which the
Code asset is physically located. You may search for this value from the
Building lookup .
Room Required. Enter the room number in the building in which the asset
Number is physically located. You may search for this value from the Room
lookup .
Sub Room Optional. Specify the cubicle in which the asset is physically
located.
Action To delete this record, click delete.
Business Rules
 If you specify a tag number, the system verifies that the number is not already being used on an active asset.
 An asset may be created only if the object code with the capital object sub type is displayed on the To or
Expense portion of the Accounting Lines tab. Note that the Procurement Card document may also be used to
create a new asset.
Process
When a financial document capitalizes an expense, the system creates a new asset in the asset database. Then a batch
process loads an approved financial document into Capital Asset Builder Other G/L Transactions. Finally, the Capital
Asset Office reviews the transaction and, if appropriate, creates the asset.

General Ledger Pending Entries Tab
After a financial transaction document has been submitted, the General Ledger Pending Entries tab displays the actual
entries that are to be posted to the G/L when the document is fully approved and the G/L batch process has run. In
addition to the entries the user created, the General Ledger Pending Entries tab may include system-generated offset
transactions. Before you submit the document, this tab contains the message 'There are currently no General Ledger
Pending Entries associated with the Transaction Processing document.'
Figure 40 - The General Ledger Pending Entries tab is empty prior to clicking submit.
When the document is submitted into routing for approval, the pending entries are displayed in the General Ledger
Pending Entries tab. If offset entries are generated by the KFS, they are also displayed in this tab.
After a transaction is fully approved, these entries are posted in a batch process to the General Ledger. After the batch
process has been run, the general ledger pending entries are moved from this tab of the document.
Figure 41 - The General Ledger Pending Entries tab displays pending items after the document has been submitted.
Figure 42 - Offset generation; object code 8000 lines were created by KFS
Specific offsets are determined by the Offset Definition table. For more information about
offsets, see Offset Definition in the Guide to the KFS Maintenance Menu.
Balancing Rules
Each e-doc is governed by a set of balancing rules, some of which are more complex than others. The balancing rules
within a document often enforce the basic rule that debits must equal credits. Whether or not an accounting line
generates a debit or credit relies on various factors, including which side of a double-sided document it is in and whether
the object code used represents income, expense, assets, or liabilities, etc.
The Accounting Lines total in some documents may balance to sections in the document
or to entries in the tabs on the document. For example, the Cash Receipt document's
Accounting Lines tab balances to the Reconciliation section of the document.

Notes and Attachments Tab
The Notes and Attachments tab displays user notes, attachments, or system-generated information about the document.
The number of notes and/or attachments is indicated on the tab.
Size and File Type Restrictions for Attachments
The maximum size of attachments is 5 megabytes by default, but your institution may
change that limit. The system imposes no restrictions on types of files that may be
attached.
Figure 43 - The number of notes and/or attachment is shown in parentheses.
Table 12 Notes and Attachments tab definition

Title 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.
Note Text Required. Enter comments.
Attached File Optional. Select the file to attach by clicking Browse and
using the standard Choose File dialog box. Click Cancel to
clear the file name you have selected.
Figure 44 - Choose File dialog box
Click add to add a note.

Ad Hoc Recipients Tab
The Ad Hoc Recipients tab allows you to interrupt the normal workflow routing of the document and include
individuals or groups 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 Group Requests. Use one or both of the
sections to route the document to a person, group, or both.
Figure 45 - Ad Hoc Recipients tab
Table 13 Ad Hoc Recipients tab definition

Field Name Description
Action Requested Required. Select the desired action from the Action
Requested list. The choices are APPROVE,
ACKNOWLEDGE, and FYI.
Person Required when routing the document to an individual. Enter

a user ID or select it from the UserID lookup .
Ad Hoc Group Required when routing the document to a group. Enter a

Requested group name or select it from the group lookup .
Click add in the Actions column to add the current line.
Click delete in the Actions column to delete the current line.
For more information about ad hoc routing, see Ad Hoc Routing.

Route Log Tab
Most financial documents require one or more approvals before they impact the General Ledger. The process usually
begins with Workflow identifying all account numbers used on the document and requesting the approval of the fiscal
officers associated with these accounts. The applicable routing information for each e-doc can be found in its Route Log
tab.
Figure 46 - The Route Log tab displays the workflow status and actions taken.
For more information about the Route Log, see Route Log.

Basic E-Doc Operations
This section describes basic e-doc operations that you perform on many different types of documents.

Initiating a Document
1 Select the document link from the main menu.
If you have not logged into the KFS, the system prompts to enter your user ID and
password.
2 Complete required tabs for the document.
For information about the requirements for a particular type of e-doc, see the help
documentation for the specific document type.
3 Click submit to route the document for approval.

Copying a Document (initiating a document based on
another document)
You may initiate a new document based on an existing document. To do so, follow these steps:
1 Retrieve the document from which you want to copy.
For information about how to retrieve a document, see Using Doc Search to Find a
Document.
2 Click the copy button in the array of workflow action buttons.

The system creates a new document with a new document ID.
The document ID information for the copied-from document is displayed in the document header and also in the Notes
and Attachments tab of the new document.
Figure 47 - The copied-from Document ID is displayed.
Clicking the Copied from Document Id takes you to the document you copied from.
Figure 48 - A note stating that the document was copied from another document is attached.
3 Complete required tabs for the document.
54 Click submit to route the document for approval.
For information about the requirements for a particular type of e-doc, see the help
documentation for the specific document type. For information about routing the
document, see Routing a Document.
Lookup and Copy Feature for Chart of Account Maintenance e-docs
To create a Chart of Accounts code that is similar to one of the existing codes, click the
copy link. The system creates a document with the same values, except for the values in the
identifying fields. This copy feature is available on the document lookup directly from the
Main Menu or Maintenance menu tab and is not available from the valid value lookup
within the financial transaction documents.

Figure 49 - Lookup and copy feature of maintenance e-docs

Saving a Document
1 To save the document to work on later, click save in the array of workflow action
buttons.
2 Verify that the document was successfully saved.

The system displays a message in the upper left corner.
Figure 50 - The KFS message 'Document was successfully saved' confirms that the document was saved.
3 Retrieve the document at a later time to continue working.
For information about how to retrieve an e-doc, see Using Doc Search to Find a Document.

Canceling a Document
1 To cancel a document, click cancel in the array of workflow action buttons.
2 When prompted, 'Are you sure you want to cancel?' click yes to proceed.
Figure 51 - When you click cancel, the confirmation dialog box is displayed.
Documents in 'INITIATED' status that are canceled are removed from the database and
cannot be retrieved or viewed.

Closing a Document
1 To close a document and return to the main menu, click close in the array of workflow
action buttons.
2 When prompted 'Would you like to save this document before you close it?' click yes to
proceed.
Closing a document in 'INITIATED' status has the same effect as canceling the document.

Routing a Document
The e-doc process supports both pre-established workflow routing and ad hoc routing. In workflow routing, the KFS
routes the document to the proper users based on business rules established in Workflow. Ad hoc routing allows a user to
route the document to one or more individual users and/or groups for approval, acknowledgement, or FYI.
Unless you want to add an ad hoc routing, select one of the action buttons to route the document in the predefined
routing hierarchy.
Figure 52 - Select an action button to route the document.
Ad Hoc Routing in the Purchasing/Accounts Payable Module
Ad hoc routing is not available in Purchasing/Accounts Payable documents because the

workflow statuses are closely related to the document statuses (PO and requisition status,
etc.). For information about document routing, see Route Levels and Workflow Routing.

Using the Action List
The action list button is located in the upper left corner of the screen allows you to view and act on documents that
require your completion, acknowledgement, approval, and FYI.
Figure 53 - The action list button and sample action list report
Documents sent to your action list may request various types of actions from you. The most commonly requested actions
are:
 Approve: Verify that the transaction is acceptable. Approved financial documents continue routing to additional
approvers, or if fully approved, are included in the next update to the General Ledger.
 Acknowledge: View and acknowledge a transaction, without the need for giving formal approval. You must
open the document from your action list to clear it out. This type of action request is generated to prior
approvers and the initiator when a document is disapproved.
 FYI: A courtesy request allowing you to view the transaction or to clear the request from your action list
without viewing it. You do not need to view the transactions sent for FYI routing.
For more information about the action list, see Action List.

Using Doc Search to Find a Document
The doc search button is located in the upper left corner of the screen. Using this button, you can search for a document
you want to view or work with.
Figure 54 - Click doc search to search for a document.
1 Click doc search.
2 Enter search criteria.
Figure 55 - Enter your criteria to search for a document.
For explanations about search criteria fields, see Standard Data Entry, Selection, Action,
and Navigation Tools and Standard Links and Icons.
3 Click search.
4 Click the document ID link to open the document, the Initiator ID link to retrieve a
workflow user report, or the Route Log icon to view the workflow status.

Figure 56 - From the search results, you may drill down by document ID, initiator or route log.
Table 14 Document search criteria

Field Description
Type Document type. Enter the document type or select it from

the Document Type lookup .
Initiator User ID of the document initiator. Enter the user ID or

select it from the Person lookup .
Document/Notification Enter the numeric document ID assigned by the system.

ID
Date Created from/to Enter or select from the Calendar the range of
document creation dates to search. You may select the
From date only, the To date only, or both.
Name this search To save the search criteria for future use, enter a name for
(optional) the search. All saved search are accessed via a list at the
top of the document search screen.
Using Wildcards (*) in the Search Criteria
The use of asterisks in the search criteria allows you to perform pattern matching. To
search for documents containing a string of characters in alphanumeric fields such as
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.
For information about advanced features of the document search, see Advanced Document
Searches.

Workflow: Overview and Key Concepts
The Kuali Enterprise Workflow (KEW) is a general-purpose, content-based electronic routing infrastructure or workflow
engine. Its main purpose is to automate the routing of electronic documents (e-docs) to individuals and groups for
approval, yet the KEW 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.
This section provides an overview of KEW as it relates to the KFS.
TOPICS
KEW Overview 90
Route Levels and Workflow Routing 91

Typical Route Levels................................................................................................................93
Viewing Route Nodes...............................................................................................................97
Workflow Responsibilities........................................................................................................99
KFS v. 3.1 Overview Workflow: Overview and Key Concepts · 95

KEW Overview
The KFS uses the KEW (also called Workflow) to handle the routing of electronic documents for actions such as
approvals, acknowledgements and FYI notifications. Although much KEW functionality works behind the scenes, the
action list and doc search buttons and the Workflow submenu options on the KFS Administration menu tab are part of
the KEW. These workflow options allow you access, act on, and search for many types of e-docs from various functional
areas from a single location. Additionally, the Route Log tab on your KFS e-docs is a workflow feature that allows you
to follow the progress of given documents through the approval process.
Many facets of Workflow (such as the route nodes that define how a given document type
routes) are stored in workflow process definition files for the various document types.
These files can be easily modified to alter the default routing of documents in your KFS
implementation, but doing so requires a technical resource and as such is beyond the scope
of this documentation.
KFS Workflow relies on Kuali Identity Management (KIM) to specify when workflow action requests are to be
generated and who should take action to fulfill them. Functional users employ the KIM interfaces to make changes that
affect the routing of documents.
96 · Workflow: Overview and Key Concepts KFS v. 3.1 Overview

Route Levels and Workflow Routing
Documents route by progressing through a series of route levels (also called 'route nodes'). All e-docs support both pre-
established workflow routing and ad hoc routing.
Figure 57 - An example of the approval route nodes a typical financial processing document passes through
In workflow routing, a document's type (General Error Correction, Transfer of Funds, etc.) determines the route levels it
passes through. Route nodes are defined by document type within the workflow process definition file.
To view workflow process definitions in XML, use the export button on the Document Type Inquiry.
Figure 58 - Use the export button to open and view the workflow process definition for a document type.
You may need technical assistance to understand or modify a workflow process definition file. Given that assistance, the
file can easily be modified to change a document's routing behavior.
An easier view for functional users is located in the Routing and Identity Management Document Type Hierarchy
option in the Functional submenu group of the Configuration submenu on the Administration menu tab.

Figure 59 - Routing & Identity Management Document Type Hierarchy option in the administration menu
The KEW arranges KFS document types in a hierarchical fashion, with some document types being 'parent' to the
document types below them in the hierarchy. 'Child' document types inherit attributes from their parents. The Routing
and Identity Management Document Type Hierarchy screen displays documents in their respective positions in this
hierarchy and also displays the route nodes associated with each document type. Nodes are listed in the order in which
the document progresses through them.
Figure 60 - Route nodes associated with the Transfer of Funds document type viewed through the Routing and Identity
Management Document Type Hierarchy

Typical Route Levels
Most, but not all, Kuali financial documents progress through three route levels: account level, organization hierarchy,
and special conditions.
Account Level Routing (Fiscal Officer)

Each account in the KFS is assigned a designated approver called a fiscal officer. This individual is responsible for
maintaining the fiscal integrity of an account and is often one of the first approvers to review a document that impacts
the account. Most financial processing documents are routed to the fiscal officer for each of the accounts identified in the
document. For example, Sue is the fiscal officer for account 1012300. All financial transactions involving this account
are routed to Sue for approval.
Organization Review (Review Hierarchy) Routing

Every account belongs to an organization. The organization develops customized routing to appropriate roles based on
criteria such as document type, dollar amount and override code. This routing may take advantage of the Chart of
Accounts organization hierarchy, meaning that approvals are set up at different levels in the organization hierarchy. A
document proceeding through this hierarchy routing might route to someone at the department level, then route to
someone else at this department's school or college, and might even continue routing to someone up to a campus or
university level.
Organization hierarchy routing (corresponding to the AccountingOrganizationHierarchy route node) is very flexible and
may be customized to be as simple or complex as needed. For example, it can be set up to accommodate appropriate
routing when the Dean of Biology wants to approve every Transfer of Funds document over $1,000 that involves an
account reporting to his organization.
Some documents without dollar amounts (such as account maintenance documents) also use organization hierarchy
routing. While technically distinct, this type of routing functions exactly as described above without regard to dollar
amount or override code.
Special Conditions Routing

Special condition routing is a blanket term for additional route levels that might be triggered by various attributes of a
transaction. Special conditions often represent special administrative approvals that may be required. This routing may
be based on the type of document, attributes of the accounts being used, or other attributes of the transaction.
Throughout the KFS help documentation, we refer to route levels that are not
fiscal officer or organization review routing as 'special conditions routing.' This
term covers a variety of different types of routing that are explained in the help
documentation sections about the various document types that use these route
levels.
For example, you may establish sub-fund routing that requires that a document using an account belonging to an
endowment sub-fund be approved by a role responsible for the endowment; or you may establish Contracts and Grant
routing that requires that a document using a grant account be approved by a central Contracts and Grants administration
area.
Table 15 Examples of special conditions routing

Routing Type Description E-Docs

Content Routing If the document's content is incomplete, Requisition
routes the document to an appropriate
individual for completion.
Separation of If the amount of the document exceeds an Requisition

Duties institutionally-defined threshold and there
have been no approvers other than the
document initiator, routes the document to
a defined central approver.
Sub-Account If the document uses a sub-account and Purchasing

Routing the sub-account has a routing rule related e-docs
established, routes the document to the
person, group or role for which the rule
has been established.
Sub-Fund If a sub-fund derived from an account Financial

Routing appearing on the document has a routing transactions e-
rule established, the document routes to docs
the person, group or role for which the rule
has been established.
Ad Hoc Routing
Ad hoc routing allows a document initiator or approver to add additional individuals or groups to the routing of a
specific document. In most cases, ad hoc approvers inserted into the routing interrupt the regular routing process. For
example, when a user initiates a financial document and ad hoc routes it to another user for approval, the document
routes to the ad hoc approver before it routes to the fiscal officer.
Ad hoc acknowledge and FYI routing do not interrupt the regular routing process. Financial
processing documents with these types of ad hoc requests still pending post to the General Ledger
as soon as all other approvals are obtained. The system does not put them on hold while waiting
for the acknowledgement to take place or for the FYI to be cleared.
The following steps describe how to add an ad hoc recipient in the Ad Hoc Recipients tab.
1 Select an action requested from the Action Requested list. To route the
document to an individual, select this option in the Person Requests section. To
send the request to a group, select this option in the Ad Hoc Group Requests
section.
Figure 61 - Select an action from the Action Requested list.

2 To ad hoc route the document to another person, type the principal name in the
Person box in the Ad Hoc Recipients section or use the lookup icon to
search for the appropriate username.
Figure 62 - Ad hoc routing to another person
3 To ad hoc route the document to a group, in the Namespace Code field in the Ad
Hoc Group Requests section, enter the group name or use the Lookup icon to
search for the appropriate group name.
Figure 63 - Ad hoc route to a group
4 Click add. The system verifies that the person ID or group namespace code and
name that you have entered for routing is valid.
5 Click submit.
After you complete the Ad Hoc Recipient section and submit the document, the
system changes the Node(s) value to 'Adhoc' and changes the Status value to
'ENROUTE.'
Figure 64 - ENROUTE status

Figure 65 - The Pending Action Requests tab shows the requested action and the user ID.
When a document is enroute, you may send ad hoc requests without taking a
workflow action on the document. To do this follow the steps listed above but use
the Send Ad Hoc Request button instead of Submit.
Figure 66 - Send ad hoc request button
When you review the Route Log immediately after submitting a document, you may
not see the Pending Action Requests tab. This is because the KFS has not yet
received the routing information from Workflow. In this case, wait for a few
seconds and click the Refresh button at the top of the Route Log to refresh the
screen. You may need to repeat this process a few times until the information
appears in the Pending Action Requests tab.
Figure 67 - Click the refresh button to view the updated workflow information.

Viewing Route Nodes
To see the route nodes associated with a particular document type, follow these steps:
1 Click the Administration menu tab.
2 Select Routing & Identity Management Document Type Hierarchy from

the Functional submenu group in the Configuration submenu.
The system displays document types in the hierarchy.
3 Locate the desired document type route levels.
For example, you might scroll down to Transfer of Funds to view the rules of the Transfer of Funds document route
levels.
Figure 68 - Locate the document type.
Beneath the document type, you see the nodes that the document routes through. The system lists these nodes in order from first to last. To view more
detail about the KIM responsibilities associated with these route nodes, click the View Document Configuration link.
Figure 69 - Click the View document Configuration link to view details.
4 Scroll down to the Workflow / Responsibilities tab.
Figure 70 - Document Configuration Workflow / Responsibilities tab

In the Workflow / Responsibilities tab, the system displays the name of each route node along with the associated
role(s) and other information. The first entry in the list defines the exception routing for this document type. This entry
identifies the role that receives the document if Workflow encounters an error that prevents it from completing the
document's normal routing.
In some cases a document may have route nodes that the document passes through based on
certain conditions. These split or branching route nodes are indented to distinguish them from the
route nodes through which all documents of this type pass.

Workflow Responsibilities
When a document routes through a particular route level, the KEW evaluates it against the responsibilities that reference
this document type and route level. A responsibility acts like a trigger: If the document meets its criteria, the system
sends an action request to a particular user or group of users.
Responsibilities are associated with roles in KIM. Roles have members or assignees who are represented in the system as
persons, groups, or other roles. Users assigned to a role inherit the role's responsibilities, meaning that they receive
action requests from Workflow when specified conditions are met.
To view responsibilities, select the Responsibility option from the System submenu
on the administration menu.
Figure 71 - Responsibility option on the administration menu
Each responsibility includes several attributes (that is, values and details) that determine when it is triggered.
Figure 72 - Responsibility attributes
Table 16 Responsibilities lookup results definition

Title Description
Template Display-only. The namespace for the responsibility template.

Namespace Usually, the namespace identifies the application and module
Code the applicable responsibility template pertains to. Because
responsibilities pertain to workflow, most responsibility
templates are associated with the KR-WKFLW (Kuali Rice-
Workflow) namespace.
Template Name Display-only. The name of the template on which the

responsibility is based. The template defines, in a broad sense,
what the responsibilities based on it do. Since responsibilities
usually generate action requests for user review, most

responsibilities have a Template Name of 'Review.'
Responsibility Display-only. The namespace with which the responsibility is

Namespace associated. This namespace usually corresponds to the
namespace of the document type for which the responsibility
generates action requests.
Responsibility Display-only. The name of this responsibility. In most cases, the

Name responsibility name will be the same as the associated template
name (Review).
Like permission names, responsibility names are not unique.
Thus most KFS responsibilities have a Responsibility Name of
'Review.'
Responsibility Display-only. Additional detail that identifies the document this

Detail Values responsibility generates action requests for, when the requests
are generated and how Workflow handles them.
Route Node Name: The point in a document's workflow routing
at which this responsibility generates requests.
Document Type Name: The name of the document type this
responsibility will generate action requests for.
Action Details At Role Member Level: A 'True' or 'False'
indicator that indicates where the details of this workflow action
request are defined. If the value is 'True,' action details are
collected when members are assigned to the role. If the value is
'False,' the action details are collected when this responsibility
is assigned to a role.
Required: A 'True' or 'False' value that indicates whether this
responsibility is required to generate an action request or send
the document into exception status ('True') or is an optional
responsibility and can be bypassed if no action requests are
generated ('False').
While responsibilities are created and maintained centrally, users may supply qualifying values when assigning users to a
role associated with these responsibilities. These qualifying values generally identify specific circumstances under which
the responsibility is invoked. For example, if a departmental user adds a user to a role with a responsibility that refers to
an organization hierarchy route node, the departmental user supplies the appropriate chart and organization code.
Subsequently, only documents that contain this chart and organization code route to the specified user.
For more information about roles and responsibilities, see KIM Permissions,
Responsibilities, and Roles in the Guide to the KFS Administration Menu.
Route Log
The Route Log tab displayed on all KFS e-docs shows workflow status details. The Route Log is broken into four
subtabs—Document ID, Actions Taken, Pending Action Requests, and Future Action Requests.

Figure 73 - The Route Log tab displays the workflow status and actions previously taken, actions that are pending, and
requests yet to be generated.
Table 17 Route Log tab definition

Title Description
Title A combination of the document type, description, and the

organization document number (if any).
Type The document type. The full name of the transaction used to
identify this document type in Workflow.
Initiator The name of the person who created the document.
Status The route status for the document.
For more information, see Route Status.
Node(s) The current route node of the document—that is, the current
step that the document is on, on its route path. Route nodes are
also referred to as 'route levels.'
Created The time and date that the document was created.
Last Modified The time and date that the document was modified last.
Last Approved The time and date that the last action was taken on this

document.
Finalized The time and date that the document reached' Final,'
'Canceled,' or 'Disapproved' status.
Actions Taken Tab

The Actions Taken tab displays the history of workflow actions on the e-doc.
Figure 74 - The Actions Taken tab within the Route Log displays the document's workflow history.
This tab lists each action taken, the name of the person who took this action, and the time and date the action was taken.
The For Delegator field shows the name of a delegate that took action on someone else's behalf. For example, for
account routing the fiscal officer's name is shown here if this person's delegate took action on the document.
To drill down into the details of each action, click show.
Figure 75 - Drill down into the workflow action requestor information by clicking show.
Figure 76 - Display of detail for workflow action requestor
Several layers of information may be available for an action request.
Pending Action Requests Tab

The Pending Action Requests tab displays the next action to be taken and shows more detailed routing information
about this request. Only action requests at the current route node are displayed.
Viewing Pending Actions

The following example shows a document that is awaiting approval by two fiscal officers.

Figure 77 - Pending Action Requests tab
The Action field indicates whether the document is in a user or group's action list or is pending their approval. An action
of Pending Approve means Workflow has identified other approval actions needed at this route node, but it has not
actually sent these requests yet. These pending approval actions may be determined by the Priority attribute on the
appropriate workflow responsibilities.
The Requested Of field displays the name of the user or group responsible for the pending action. The value in this field
is based on the responsibility at this current route level. In cases where a document routes to a role with more than five
members the name of the role will be displayed along with any qualifying values pertaining to the role assignees who
received the request.
Note that the Pending Action Requests tab shows pending requests only for the document at its current route node. The
system may add new requests when the document transitions to a new route level.
To identify members of a group whose ID is displayed in the Requested Of field,

click the link for the group ID. The system displays information about the group members.
Figure 78 - Group member display
If multiple users are identified as the recipients of a single action request, the number of actions required is controlled by
the action policy code associated with the responsibility that generated the request.
 If this code is set to 'ALL,' all users specified must take the required action on the document before the request
will be cleared.
 If the action policy code is 'FIRST,' the first of the specified users to take the action will cause the system to
clear the action request for all other users with the same request.
Future Action Requests Tab

When a document's status is 'saved' or 'enroute,' the Future Action Requests tab on the Route Log shows the action
requests that Workflow will generate in the future based on the information currently on the document.
Figure 79 - Future Action Requests tab
To open this section and view the future action requests, click the show button. Future action
requests are listed in the order in which they are to occur.
As a document routes and users take action on it, the system updates the contents of the Future Action Requests tab to
show only those requests that have not yet been made by Workflow. When a document reaches 'Final' or 'Processed'
status in Workflow, this tab becomes empty because there are no future requests to display.
The Annotation entry is a message that is generated based on the KIM responsibilities being referenced by Workflow.
Figure 80 - Routing annotations appear in the Route Log.
Viewing Routing Details

To display more detailed routing information about the request, click show.
Figure 81 - Click show to view detailed routing information.
The resulting display contains additional information about the request.
Figure 82 - Display of action request detail

Table 18 Pending Action Requests detail definition
Title Description
Node The route node at which this request was generated.
Priority The priority assigned to this workflow request. If multiple

requests are generated at the same workflow node, the system
generates requests with low priority numbers before requests
with higher priority numbers.
Approval Policy A value indicating whether members of a role receiving this

request must each take action to fulfill the request or if only a
single role member must take action.
Forced Action A true/false indicator specifying whether a user must take action
on this document even if he or she has acted on it previously. If
'True,' then the user must take another action. If 'False,' then the
previous action will automatically fulfill this request.
Route Status
Route status indicates where a document is in its routing process. For any given document, the system displays route
status in both the Route Log tab and the document header.
Figure 83 - Route status is displayed in the Route Log tab.
The following table summarizes the meaning of various route statuses in the KEW.
Table 19 Route status

Status Description
Approved The document has been approved. The document is now a

valid business transaction in accordance with institutional
needs and policies. See note below.
Canceled The document is denoted as void and should be disregarded.

This status is applied to a document when an initiator creates
a document and cancels it before submitting it for approval.
Committed The document has been committed to the database. See note
below.
Disapproved The document has been disapproved by an approver.
Enroute The document has pending approval requests.

Exception The document has been routed to an exception queue
because workflow has encountered an error when trying to
process its routing.
Final The document has been routed and has no pending approval
or acknowledgement requests. Documents in 'Final' status are
considered approved in that documents in this status affect the
General Ledger or update Chart of Accounts values.
Initialized The document has been created but has not yet been saved or
submitted.
Processed The document has no pending approval requests but still has
one or more pending acknowledgement requests. Processed
documents are considered approved, so they impact the
General Ledger or update Chart of Accounts values.
Saved The document has been started but not completed or routed
yet. The save action allows the initiator of a document to save
his or her work and close the document. The document may
be retrieved from the initiator's action list for completion and
routing at a later time.
A user does not ordinarily see a Status value of 'Approved' or 'Committed.' The
system displays these statuses to users only as a result of a system error or
performance issue.
Action List
In the KFS, you receive action requests for e-docs through your action list. This list provides summary information about
each document that requires your attention, 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 you've received this request because you are a
delegate or a member of a group.
1 Click action list.
The Workflow system retrieves all documents that you have initiated and saved and any documents that are routed to
you to approve, acknowledge, or FYI.
Figure 84 - Documents in the action list that are pending action
2 Click the document Id link to open the document.

The system displays a set of buttons at the bottom of the screen. The buttons you
see depend on your role and the requested action.

Figure 85 - Workflow action buttons
3 Click one of the workflow action buttons.
Workflow Action Buttons

When you open a document, you see various workflow action buttons at the bottom of the page. The buttons vary
depending on the kind of action request you have received for the document and the KIM role(s) to which you belong.
Table 20 Workflow action buttons

Action Description
Signifies that you have responded to the acknowledgement

action request. This button is available only to users to whom a
document has been routed for acknowledgement. See FYI
below.
Signifies that in your judgment the document represents a valid

business transaction in accordance with institutional needs and
policies. A single document may require approval from several
users, at multiple route levels, before it moves to 'Processed'
status.
Bypasses all subsequent levels of approval and immediately

moves a document to 'Processed' or 'Final' status. Anyone who
would otherwise have received the document for approval
receives an acknowledge request instead. This action may be
taken only by roles associated with blanket approve document
permission, such as the KFS-SYS Manager role.
Denotes that the document is void and should be disregarded.

Canceled documents cannot be modified in any way and do
not route for approval.
Allows you to exit the document. The system displays a

message asking whether you 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 you to create a new document based on the existing

document. Not all document types can be copied.
Signifies that in your judgment the document does not

represent a valid business transaction. A disapprove action
from any single approver prevents a document from posting to
the G/L or updating a maintenance table.
Allows you to correct documents by creating a new document

that reverses the original transaction. This feature can be used
only on documents that have completed the routing process
and have been fully approved. Not all document types are

eligible for error correction.
Signifies that you have responded to the FYI action request.

This actioin is available only 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.
Refreshes the screen and displays the most recently saved

information. Changes that are made but not saved prior to
reloading a page are not maintained.
If you are the initiator of this document, allows you to save your
work and close the document. The document may be retrieved
from your action list for completion and routing at a later time.
If your permissions allow you to edit enroute documents, you
can also save changes to an enroute document in your action
list.
Moves the document (through workflow) to the next level of

approval. After a document is submitted, it remains in 'Enroute'
status until all approvals have taken place.
Special attention should be paid when you select any of the workflow action buttons noted below.
Blanket Approving a Document

Click blanket approve to approve the document bypassing all other approvals.
If you are a member of a role with a blanket approve document permission (such as the KFS-SYS Manager role), you
have the option to blanket approve a document routed to you for your approval.
Note that you can only blanket approve a document you are initiating or a document for which you already have an
approval request.
Disapproving a Document
1 Click disapprove.
2 Enter a reason for disapproval, and then click yes to confirm.

Figure 86 - Enter a reason for disapproval.
After you complete the disapprove action, the system displays the reason in the Notes and
Attachment tab.
Figure 87 - The system displays the reason for disapproval in the Notes and Attachments tab.
Acknowledging a Document
Click acknowledge.
Acknowledgements do not interrupt the normal workflow routing of a document.

They do not stop a document from routing on to other individuals, groups, or roles
who need to take approval actions.
FYI
FYIs do not interrupt the normal workflow routing of a document.
To signify that you have responded to the FYI action, you may take either of two
actions:
- Click FYI when you open the document
- or, in the action list, select FYI in the Actions column and click take actions.

Figure 88 - Selecting FYI from the Actions column in the action list
Setting the default action for FYI
To clear all FYI actions in the action list simultaneously, first set the default action from 'NONE'
to 'FYI.'
Figure 89 - You can set the default to action to FYI in the action list.
Next, click apply default (in the upper right corner) and then click take actions.
Correcting Errors after Approval

The error correction action allows you to correct documents by creating a new document that reverses the original
transaction that has been fully approved. A document created with the error correction action must route and be approved
in the same manner as the e-doc it corrects.
The error correction action should not be confused with the financial transaction document type
General Error Correction (GEC), which is described in 'General Error Correction' of the Guide to
the KFS Main Menu.
1 Click error correction.

The system creates a new document with a new document ID. The system also displays
Corrects Document ID in both the document header and the Notes and Attachment tab of
the document.
Figure 90 - Corrects Document ID in the document header

Figure 91 - Amounts are in negative to reverse the original transaction.
Figure 92 - The new document has an annotation that is an error correction.
2 Click submit.
The header of the corrected document shows the corrected by document ID.
Figure 93 - Corrected by Document ID
Workflow Preferences
The system allows you to change the automatic refresh rate, action list page size, email notification, and row colors that
indicate the status of the document, You may also limit the list of documents in the action list by setting filters for
delegators or workflow status. To make any of these changes, click the preferences button in the action list.

Figure 94 - Click the preferences button in the action list.
Figure 95 - Preferences allows you to change the display of your action list.
Table 21 Preferences definition

Criteria Description
Automatic Enter a number in whole minutes.

Refresh Rate
Action List Page Enter a number of rows to display per page in the action list.
Size
Email Select one of the desired email frequencies from the list:
Notification 'None,' 'Daily,' 'Weekly' or 'Immediate.'
Receive Primary Check this box to receive an email when a document arrives in

Delegate Emails your action list for which you are the primary delegate.
Receive Check this box to receive an email when a document arrives in

Secondary your secondary delegate action list.
Delegate Emails
Delegator Filter In the list, select 'Secondary Delegators on Action List' or

'Secondary Delegators only on Filter Page' to specify when to
show the secondary delegation entries in your action list.
Fields Displayed Check each box to include these items on the action list.
in Action List
Document Route Click one of the color options for each document route status.
Status Colors for
Action List
Entries
To save your preferences, click save.
To return to the default preferences, click reset.
Color changes do not take place until the next time you log onto the system.
Figure 96 - 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.
1 To go to the Action List Filter dialog box, click the Filter button.
Figure 97 - Click the filter button.
2 Specify filtering criteria in the Action List Filter dialog box.

Figure 98 - Specify criteria for your filter.
Table 22 Action List Filter definition

Criteria Description
Document Title Enter a partial or full character string that you are looking for in
the document description. For example, enter 'Test' to see all
documents that contain 'Test' in the document description. This
field is case sensitive. Select the Exclude? check box to
exclude documents with the specified title from the list.
Document Route Select the route status you want. The choices are 'All,'
Status '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 from the list. The choices are 'Acknowledge,'
'Approve,' 'Complete,' and 'FYI.' Select the Exclude? check
box to exclude documents with the selected action from the
list.
Action Requested Select the name of the group that is requested to take an
Group action.
Document Type Select a document type from the Document Type lookup .
Select the Exclude? check box to exclude documents with the
selected type from the list.
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 Enter a date range or select dates from the calendar by
Assigned 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.
3 Click filter.
The system displays a message in the upper left corner.
Figure 99 - Notice the filter message above the action list.
Clearing the Action List Filter

To remove the filter and view the entire list, click the Clear Filter button to remove
the filter.
The Clear Filter button is visible only when you have previously created the
filter.
Figure 100 - Click the Clear Filter button to remove the action list filter.
Advanced Document Searches

In Using Doc Search to Find a Document, we introduced the basic search capabilities within the KEW. The system also
provides more advanced and sophisticated search capabilities.
Detailed vs. Basic Searches

When you click the doc search button, the system displays a search screen that initially defaults to a basic search.

Figure 101 - Basic search
To switch between the basic search and detailed search, click the DETAILED SEARCH OR BASIC SEARCh button
near the top of the screen. The detailed search screen gives you more options for specifying search criteria.

Figure 102 - Detailed search
Superuser vs. Non-Superuser Searches

The search screen initially defaults to a non-superuser search mode. If you are a member of a role (e.g., the KFS-SYS
Workflow Administrator role) that has the administer routing for document permission, you may switch between non-
superuser search and superuser search mode by clicking the Superuser Search or Non-Superuser Search link.

Figure 103 - Superuser search mode gives you more search options.
The superuser search mode gives you more search options and allows you to access documents you wish 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 users with an appropriate role
can actually take special actions on the documents retrieved by the superuser search function.
Document-Specific Searches
Document-specific searches allow you to specify additional criteria when you search specific document types or groups
of documents such as financial transactions or purchasing/accounts payable documents. In addition to the standard

search criteria available in the basic and advanced searches, document-specific searches allow you to specify fields such
as dollar amounts, status, and document-specific reference numbers.
For more information about document-specific search, see the help documentation
section on the applicable document type.
You may also access these search options after you click the doc search button. To access document-specific search at
this point, either enter the document type name and tab out of the field or use the Document Type lookup . The
system displays the appropriate additional search fields.
Named Search
When you name a set of search criteria, the system saves your search as a named search. When you later click search,
the system displays a list of all named searches you have created in the Searches list.
Figure 104 - You may access your named search via the Searches list.
Clear Saved Searches

To clear all of your named searches, click clear saved searches. The KFS clears the Searches
list.
Figure 105 - Cleared searches list
Clearing Search
To clear your previous search criteria, click clear.
Superuser Functions
If you are a user with 'Administer Routing for Document' permission (for example, if you are a member of the KFS-SYS
Workflow Administrator role), you may take special workflow actions on documents.
1 To access these options, click the doc search button.

2 Select the superuser search link in the upper-right corner.
Figure 106 - Access to superuser document search
3 Perform a document search as normal and open the document.
From the superuser view, you may take various actions that are allowed only for the superuser.

Figure 107 - Superusers may take special actions on the documents retrieved.
The following describes the actions that can be taken by the superuser.
To add an annotation, enter the text in the Annotation box.

Figure 108 - Superusers may add an annotation.
The system displays a checkbox indicating whether or not the post-processor logic associated
with this document type should occur. After approvals are complete, most KFS document types
invoke a post-processor to update the appropriate tables (i.e., update G/L pending entries for
transactional documents and update maintenance tables for maintenance documents). In most
cases you'll want the regular post-processing to occur, so the box defaults to checked. Note that
this option may be suppressed for certain document types.
Figure 109 - Leave this box checked to have the system perform post-processor logic.
If for some reason you don't want this document to be processed by the post-
processor, uncheck the box.
To ad hoc route the document, select the type of recipient you are routing to (person
or group), then enter the appropriate principal name or namespace code and group
name, select the desired action request, and click route to recipient.
Figure 110 - Superusers may ad hoc route a document.
Choose one of these actions:
 To approve a document, click approve document.
 To disapprove the document, click disapprove document.
 To cancel the document, click cancel document
 To return the document to the previous route level, select a node name from
the route level list and click return to previous route level.
Figure 111 - Superusers may approve, disapprove, cancel, or return the document to the previous route level.
 To complete a requested action, click the action button that the system displays along

with the description of this pending action request.
Figure 112 - Click approve to finalize this superuser action.

Accounting Line Import Templates
Accounting line import templates allow you to import any number of accounting lines or line items from a comma-
delimited (.csv) file. This section contains a table that lists types of e-docs for which templates are available in the
default system and provides a link to the corresponding template for each document type. Following the table is a
process overview that includes complete instructions for using accounting line import templates and importing multiple
lines of data. Additional subsections contain detailed information about each template.
TOPICS
Links to Default Data Import Templates 126
Process Overview 131
AD_CR_CCR_DV_SB_Import.xls 135
AV_Import.xls 136
BA_YEBA_Import.xls 137
DI_YEDI_IB_TF_YETF_PE_Encumbrance_Only_Import.xls 139
GEC_YEGEC_Import.xls 140
ICA_Import.xls 141
JV_Ext_Encumbr_Import.xls 142
JV_NonOffset_Bal_Type_Import.xls 143
JV_Offset_Bal_Type_Import.xls 144
LLJV_Import.xls 146
ND_Import.xls 148
PE_Disencumbrance_Only_Import.xls 149
PURAP_Item_Import.xls 150
PURAP_Account_Import.xls 151
130 · Accounting Line Import Templates KFS v. 3.1 Overview

CAM_MPAY_Account_Import.xls 152
KFS v. 3.1 Overview Accounting Line Import Templates · 131

Links to Default Data Import Templates
The following table lists the types of e-docs for which templates are available in the default system along with links to
the corresponding templates.
Table 23 Data import templates by document type

Document Type Link to Template Usage Notes
Advanced AD_CR_CCR_DV_SB_Import.xls
Deposits
Document (AD)
Cash Receipt
(CR)
Credit Card
Receipts (CCR)
Disbursement
Voucher (DV)
Service Billing
(SB)
Auxiliary Voucher AV_Import.xls An amount is
(AV) required in either
the Debit or Credit
column for each
accounting line. If
amounts are
erroneously
entered in both
Debit and Credit
fields on an
accounting line,
only the credit
amount will be
imported to the e-
doc; the debit
amount will not be
imported.
Budget BA_YEBA_Import.xls If an amount is
Adjustment (BA) erroneously
entered in the
Year End Budget
Base Budget
Adjustment
Adjustment
(YEBA)
Amount column, it
is imported to the
accounting line of
the e-doc. An error
is displayed when
the data is
validated via
saving or
submitting the e-

doc.
Distribution of DI_YEDI_IB_TF_YETF_PE_Encumbrance_Only_Import.xls
Income and
Expense (DI)
Internal Billing
(IB)
Pre-Encumbrance
- encumbrance
lines only (PE)
Transfer of Funds
(TF)
Year End
Distribution of
Income and
Expense (YEDI)
Year End
Transfer of Funds
(YETF)
General Error GEC_YEGEC_Import.xls
Correction (GEC)
Year End General
Error Correction
(YEGEC)

Indirect Cost ICA_Import.xls Object code is
Adjustment (ICA) automatically
populated by an
APC value
Journal Voucher JV_Ext_Encumbr_Import.xls Debit/credit
(JV)- Debit/Credit amount entry, used
amount entry, for external
used for the encumbrance
following balance balance types. A
type: journal voucher
has three different
EX - External
accounting line
Encumbrance
formats, depending
on its balance type.
You must choose
the balance type
before importing.
An amount is
required in either
the Debit or Credit
column for each
accounting line. If
amounts are
erroneously
entered in both
Debit and Credit

fields on an
accounting line,
only the credit
amount is imported
to the e-doc; the
debit amount is not
imported.
Journal Voucher JV_NonOffset_Bal_Type_Import.xls Single amount
(JV) - Single entry, used for
amount entry, non-offset balance
used for the types. A journal
following Non- voucher has three
offset balance different
types: accounting line
formats, depending
AS- Actual
on its balance type.
Statistics
You must choose
BB- Adjusted the balance type
Base Budget before importing.
BS - Budget
Statistics
CB - Current
Budget
JB - July 1
Budget
MB - Monthly
Budget
RE -Year-End
Budget Reversion
Journal Voucher JV_Offset_Bal_Type_Import.xls A journal voucher
(JV) - Debit/Credit has three different
amount entry, accounting line
used for the formats, depending
following Offset on its balance type.
balance types: You must choose
the balance type
A2- A21
before importing.
Balances-Labor
An amount is
Ledger Only
required in either
AC- Actuals the Debit or Credit
(Blance Sheet) column for each
accounting line. If
CE- Cost Share amounts are
Encumbrances erroneously
IE- Internal entered in both
Encumbrance Debit and Credit
fields on an
NB - Close accounting line,
Normal Balance only the credit
PE - Pre- amount is imported
Encumbrance to the e-doc; the
debit amount is not

TR - Transfers imported.
Labor Distribution LLJV_Import.xls
Journal Voucher
(LLJV)
Non-Check ND_Import.xls
Disbursement
(ND)
Pre-Encumbrance PE_Disencumbrance_only_Import.xls Disencumbrance
(PE) lines only
-disencumbrance
lines only
Purchase PURAP_Item_Import.xls This template
Requisition imports line item
(REQS) item data into the Items
import tab. (The REQS
document has no
Accounting Lines
tab.)
Purchase PURAP_Account_Import.xls The REQS and PO
Requisition documents have
(REQS) and no Accounting
Purchase Order Lines tab, but
(PO) account clicking setup
import distribution in the
Items tab opens
an Accounting
Lines section. This
template imports
account data into
the Accounting
Lines section.
Capital Asset CAM_MPAY_Account_Import.xls The MPAY
Payment (MPAY) document has no
account import Accounting Lines
tab, but clicking
setup distribution
in the Items tab
opens an
Accounting Lines
section. This
template imports
account data into
the Accounting
Lines section of
the Asset Payment
and Asset Manual
Payment menu
items.

Process Overview
The import lines button is located in the upper right corner of the Accounting Lines tab. It allows you to import a .csv
file containing financial transaction accounting line data into the Accounting Lines tab of the financial transaction
document. For each financial transaction document type there is an accounting line import template. Multiple e-docs may
use the same template.
The layout and format of the .csv import template files varies by document type.
Using the incorrect format for the .csv file causes the import to fail. Note that a
separate file is needed for each Accounting Lines tab section (for example, the
From and To sections).
Creating a .csv File

The format of the .cvs file varies depending on the document type. The desired template file for the document may be
downloaded from Kuali Confluence or you may access it directly from the document you are working in.
The import lines button is located in the upper right corner of the Accounting Lines tab.
1 Click the import lines button in the upper right corner of the Accounting Lines tab.
Figure 113 - Click import lines in the upper right corner of the Accounting Lines tab.
The system displays additional buttons such as Browse, add, and cancel import.
2 Click the question mark icon to the right of the Accounting Lines section header.
Figure 114 - Click the question mark icon to access templates.
The system opens the on-line help that explains the import rules and format
requirements.
3 Open the template file that corresponds to the type of financial transaction document
you are working on. The system provides a template for each document type (in
some cases, multiple document types use the same template).

Figure 115 - Accounting lines import file template
4 Save the template to your computer as an Excel workbook.
Figure 116 – Saving the template
5 Add data to the file.
Required field headings are marked with an asterisk and appear in red.
Figure 117 - Import file
6 If the file is to be used again in the future, save the file as an Excel workbook (don't
delete the headers yet). If the file is not to be used again, skip this step.
Figure 118 - Saving the file
7 Delete the header rows at the top.
Figure 119 - Deleting header rows
8 Save the file again, with a new name, in .csv format.

Figure 120 - Resaving in CSV format
9 Click Browse and locate the file you have created from your computer.
Figure 121 - Clicking Browse
10 From the Choose File window, select the .csv file to be imported and click Open.
11 Click add.
Figure 122 - Clicking add to import the .csv file
The screen displays the imported data.
Figure 123 - Imported data using IMPORT LINES
12 When finished, archive or delete the .csv file.

When the file is needed again, follow these instructions:
1 Open the saved Excel workbook with the data from Step 5 above.
2 Edit the file as necessary.
3 Follow steps 6 - 12 above.

AD_CR_CCR_DV_SB_Import.xls
The AD_CR_CCR_DV_SB_Import.xls template applies to several document types:
 Advanced Deposits Document (AD)
 Cash Receipt (CR)
 Credit Card Receipts (CCR)
 Disbursement Voucher (DV)
 Service Billing (SB)
The basic format of the template is shown below.
Figure 124 - AD_CR_CCR_DV_SB_Import.xls
Table 24 AD_CR_CCR_DV_SB_Import template format

Column Field Name
A Chart Code*
B Account Number*
C Sub-Account Number
D Object Code*
E Sub-Object Code
F Project Code
G Organization Reference Id
H Line Description
I Amount*

AV_Import.xls
The AV_Import.xls template applies to Auxiliary Voucher (AV) documents.
Figure 125 - AV_Import.xls
Table 25 AV_Import template format

Column Field
A Chart Code*
B Account Number*
D Object Code*
E Sub-Object Code
F Project Code
H Debit*
I Credit*
An amount is required in either the Debit or Credit column for each accounting
line. If amounts are erroneously entered in both Debit and Credit fields on an
accounting line, only the credit amount are imported to the accounting lines, the
debit amount is not imported.

BA_YEBA_Import.xls
The BA_YEBA_Import.xls template applies to two document types:
 Budget Adjustment
 Year-End Budget Adjustment
Figure 126 - BA_YEBA_Import.xls (part 1)
Figure 127 - BA_YEBA_Import.xls (part 2)
Table 26 BA_YEBA_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Sub-Object Code
F Project Code
H Current Budget Adjustment Amount*
I Base Budget Adjustment Amount
J Month 1 Budget Amount
K Month 2 Budget Amount
L Month 3 Budget Amount
M Month 4 Budget Amount
N Month 5 Budget Amount
O Month 6 Budget Amount

P Month 7 Budget Amount
Q Month 8 Budget Amount
R Month 9 Budget Amount
S Month 10 Budget Amount
T Month 11 Budget Amount
U Month 12 Budget Amount
If an amount is erroneously entered in the Base Budget Adjustment Amount column, it is

imported to the accounting line of the eDoc. An error is displayed when the data is validated
via saving or submitting the eDoc.

DI_YEDI_IB_TF_YETF_PE_Encumbrance_Only_Im
port.xls
The DI_YEDI_IB_TF_YETF_PE_Encumbrance_Only_Import.xls template applies to several document types:
 Distribution of Income and Expense (DI)
 Internal Billing (IB)
 Pre-Encumbrance - encumbrance lines only (PE)
 Transfer of Funds (TF)
 Year-End Distribution of Income and Expense (YEDI)
 Year-End Transfer of Funds (YETF)
Figure 128 - DI_YEDI_IB_TF_PE_Encumbrance_Only_Import.xls
Table 27 DI_YEDI_IB_TF_PE_Encumbrance_Only_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Sub-Object Code
F Project Code
H Amount*

GEC_YEGEC_Import.xls
The GEC_YEGEC_Import.xls template applies to two document types:
 General Error Correction (GEC)
 Year-End General Error Correction (YEGEC)
Figure 129 - GEC_YEGEC_Import.xls
Table 28 GEC_YEGEC_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Sub-Object Code
F Project Code
H Reference Origin Code*
I Reference Number*
J Line Description
K Amount*

ICA_Import.xls
The ICA_Import.xls template applies only to Indirect Cost Adjustment (object code is automatically populated by an
APC value).
Figure 130 - ICA_Import.xls
Table 29 ICA_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Sub-Object Code
E Project Code
F Organization Reference Id
G Amount*

JV_Ext_Encumbr_Import.xls
The JV_Ext_Encumbr_Import.xls template applies only to Journal Voucher (JV) - Debit/Credit amount entry, used for
External Encumbrance balance types
A Journal Voucher has three different accounting line formats, depending on its Balance Type. You
must choose the Balance Type before importing.
Figure 131 - JV_Ext_Encumbr_Import.xls
Table 30 JV_Ext_Encumbr_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Object Type Code*
F Sub-Object Code
G Project Code
H Organization Reference Id
I Reference Origin Code*
J Reference Type Code*
K Reference Number*
L Debit*
M Credit*
An amount is required in either the Debit or Credit column for each accounting line. If amounts
are erroneously entered in both Debit and Credit fields on an accounting line, only the credit
amount is imported to the e-doc, the debit amount is not imported.

JV_NonOffset_Bal_Type_Import.xls
The JV_NonOffset_Bal_Type_Import.xls template applies only to Journal Voucher (JV) - Single amount entry, used for
non-offset balance types.
A Journal Voucher has three different accounting line formats, depending on its balance type. You
must choose the balance type before importing.
Use this template for the following balance types:
 AS- Actual Statistics
 BB- Adjusted Base Budget
 BS - Budget Statistics
 CB - Current Budget
 JB - July 1 Budget
 MB - Monthly Budget
 RE -Year-End Budget Reversion
Figure 132 - JV_NonOffset_Bal_Type_Import.xls
Table 31 JV_NonOffset_Bal_Type_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Object Type Code*
F Sub-Object Code
G Project Code
I Amount*

JV_Offset_Bal_Type_Import.xls
The JV_Offset_Bal_Type_Import.xls template applies only to Journal Voucher (JV) - Debit/Credit amount entry, used
for Offset balance types.
A Journal Voucher has three different accounting line formats, depending on its balance type.
You must choose the balance type before importing.
Use this template for the following balance types:
 A2- A21 Balances-Labor Ledger Only
 AC- Actuals (Blance Sheet)
 CE- Cost Share Encumbrances
 IE- Internal Encumbrance
 NB - Close Normal Balance
 PE - Pre-Encumbrance
 TR - Transfers
Figure 133 - JV_Offset_Bal_Type_Import.xls
Table 32 JV_Offset_Bal_Type_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Object Type Code*
F Sub-Object Code
G Project Code
I Debit*

J Credit*
An amount is required in either the Debit or Credit column for each accounting line. If amounts
are erroneously entered in both Debit and Credit fields on an accounting line, only the credit
amount is imported to the e-doc, the debit amount is not imported.

LLJV_Import.xls
The LLJV_Import.xls template applies to the Labor Distribution Journal Voucher (LLJV) document.
Figure 134 - LLJV_Import.xls (part 1)
Figure 135 - LLJV_Import.xls (part 2)
Table 33 LLJV_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object*
E Type Code*
F Sub-Object Code
G Project Code
H Org Ref Id
I Position Number*
J Employee ID*
K Employee Record
L Earn Code
M Pay Group
N Salary Admin Plan
O Grade
P Run ID
Q Period End

R Pay FY*
S Pay Period*
T Pay Hours
U Original Chart
V Original Account
W Original Sub-Account
X Original Object Code
Y Original Sub-Object Code
Z Company
AA Set ID
AB Debit* (Enter an amount either the debit or credit field)
AC Credit* (Enter an amount either the debit or credit field)

ND_Import.xls
The ND_Import.xls template applies to the Non-Check Disbursement (ND) document type.
Figure 136 - ND_Import.xls
Table 34 ND_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Sub-Object Code
F Project Code
H Reference Number*
I Line Description
J Amount*

PE_Disencumbrance_Only_Import.xls
The PE_Disencumbrance_only_Import.xls template applies to the Pre-Encumbrance (disencumbrance lines only)
document type.
Figure 137 - PE_Disencumbrance_Only_Import.xls
Table 35 PE_Disencumbrance_Only_Import template format

Column Field Name
A Chart Code*
B Account Number*
D Object Code*
E Sub-Object Code
F Project Code
H Reference Number*
I Amount*

PURAP_Item_Import.xls
The PURAP_Item_Import.xls template applies to the Requisition document type and is used to import items into the
requisition.
Figure 138 - PURAP_Item_Import.xls
Table 36 PURAP_Item_Import template format

Column Field Name
A Quantity
B UOM*
C Catalog Number
D Commodity Code
E Description*
F Cost*

PURAP_Account_Import.xls
The PURAP_Account_Import.xls template applies to both the Requisition document type and the Purchase Order
document type. It is used to import accounting lines into a requisition or purchase order.
Figure 139 - PURAP_Account_Import.xls
Table 37 PURAP_Account_Import template format

Column Field Name
A Chart*
B Account*
C Sub-Account
D Object Code*
E Sub-Object Code
F Project
G Org Ref ID
H %*

CAM_MPAY_Account_Import.xls
The CAM_MPAY_Account_Import.xls template applies to the Asset Payment (MPAY) document type and is used to
import accounting lines into an Asset Payment transaction.
Figure 140 – CAM_MPAY_Account_Import.xls
Table 38 CAM_MPAY_Account_Import template format

Column Field Name
A Chart*
B Account*
C Sub-Account
D Object Code*
E Sub-Object Code
F Project
G Org Ref ID
H Amount*
I Purchase Order #
J Origin Code
K Requisition #
L Document Number
M Document Type*
N Posted Date*

General Ledger (G/L)
The General Ledger (G/L) contains many important processes that ensure that the KFS runs correctly. For users
processing e-doc transactions, the most apparent of these processes are the generation of offsets and the posting of
transactions to the balance tables. Other important General Ledger processes are less apparent to users. These processes
ensure that transaction data is valid, capitalization entries are created, and indirect cost recovery and cost share transfers
occur. The KFS also offers related features such as sufficient funds checking and flexible offsets for institutions that
want to utilize this functionality.
TOPICS
General Ledger G/L Process 154

Batch Process Steps................................................................................................................155
Process Initiation.....................................................................................................................156
Transaction and Data Sources.................................................................................................157
Transaction Validation............................................................................................................161
G/L Demerger Process............................................................................................................171
G/L Posting.............................................................................................................................172
Sufficient Funds 189
Flexible Offset 191

Flexible Banking Offsets........................................................................................................192
Flexible Offsets by Account...................................................................................................193
Year-End Processes 194

Closing Encumbrances............................................................................................................195
Reversions and Carry Forwards..............................................................................................196
Closing Nominal Activity.......................................................................................................201
Beginning Balances.................................................................................................................202
Batch Assurance Reports........................................................................................................203
General Ledger Automated Balancing....................................................................................207
G/L Correction Process (GLCP) 210
Accounting Cycle Files 211
158 · General Ledger (G/L) KFS v. 3.1 Overview

General Ledger G/L Process
The G/L is the official repository for all of KFS's financial and budget information. It stores account balance and budget
information for multiple fiscal years and stores a detailed record of all financial transactions.
Users do not directly interact with the G/L. Instead, users who need to modify financial information in the G/L do so by
creating e-docs that, when fully approved, are posted to the G/L.
The Kuali G/L module is a daily batch processing application that expects all G/L pending transactions to be collected in
'batch' from the G/L entry files. The daily batch includes transactions generated in Kuali modules as well as transactions
created in external applications and converted to the Kuali G/L entry format.
KFS v. 3.1 Overview General Ledger (G/L) · 159

Batch Process Steps
Because users do not interact directly with the processes described here, the information in this
section is primarily informational.
G/L processing takes place in a batch, meaning that its processes run at a given time for all pending transactions with the
G/L being updated after the processes have completed. The processes include:
 Process Initiation
 'Collector' - Transaction and Data Sources
 'Scrubber' - Transaction Validation and Generation
o Validation
o Offset Generation
o Automated Transaction Generation
 'De-Merge' - G/L Transaction Filter
 'Poster' - G/L Posting
Transactions are processed based on the parameters that your institution has set up. For more
information about the parameters, see Parameter in the Guide to the KFS Administration Menu.

Process Initiation
The G/L process is usually run at a time when it does not compete with online transaction activity or table maintenance
(early morning hours). But process initiation may be set up at the discretion of your institution to be time triggered, event
triggered, or manually started.
KFS documents,
Scrubber Scrubber
“Collector” and Scrubber Offset GL Transaction GL Posting
Transaction Transaction
other external Generation Filter De-Merge “Poster”
Validation Generation
feeds
Capitalization of Assets
Capitalization of Liabilities Main Poster
Plant Indebtedness Reversal Poster
Cost Share Transfers ICR Poster
Cost Share Encumbrances
Figure 141 - KFS batch cycle

Transaction and Data Sources ('Collector')
Figure 142 - Collector
The 'Collector' aggregates transactions for pending financial activity. The process relies on input from multiple sources,
one of which is KFS-generated financial transaction electronic documents (e-docs). These transactions are generated by
the KFS from online input and are stored in the standard pending transaction format expected by the G/L. Stored
transactions go through a screening process to determine which are passed to the G/L. During this process, canceled
transactions and transactions disapproved in the Workflow process are excluded.
The second source of transactions is feeds of financial activity from supporting applications (for example, your
institution's Payroll and Bursar systems). In most cases, transactions from external feeds are not sent to the G/L in the
standard pending transaction format. Two choices are available for addressing the difference in formatting:
 Batch Enterprise Feed (Origin Entry Transactions): The external applications may be modified to correctly
format transactions and store them for direct G/L processing; or
 XML and Flat File Transactions: External application transactions may be generated in XML or a flat file
format and uploaded to KFS. The KFS 'Collector' process scans XML transactions and converts them to Kuali
format G/L origin entries.
XML (eXtensible Markup Language) is a set of rules for defining tags that break a document
into parts and identify the different parts of the document. XML provides a structured file
format for the interchange of data among different applications.
For information about using the XML file batch upload function, see Collector XML Upload in
the Guide to the KFS Administration Menu.
Pending financial transactions are validated against your institution's Chart of Accounts (which is where the
organizational structure and accounts and the detailed categories of financial transactions are defined). The Chart of
Accounts provides options for assigning attributes for sorting, summarizing and reporting financial activity.

KFS
Transactions
(Financial General Ledger
Transactions, Pending
Puchasing/AP, Entries
etc.)
Origin Entry
KFS Labor Scrubber
Directory
External
Enterprise
Systems
Feed Directory
(Non-KFS)
XML or Flat
File “Collector”
Transactions
Figure 143- G/L transaction, data sources and process initiation
The following summary and detail reports are generated when the G/L pending entries are collected:

Figure 144 - The Collector Report (collector)
Figure 145 - Part of the GLPE Statistics Report (glpe_ledger)

Figure 146 - Part of the Pending Ledger Entry table Report (glpe_list)

Transaction Validation ('Scrubber')
Figure 147 - 'Scrubber'
The 'Scrubber' process performs the following primary functions:
 Validation of data: Includes the addition of some missing values, validation against the Chart of Accounts, and
the application of continuation account logic.
 Offset and entry generation: Includes document balancing, capitalization of assets and liabilities, plant
indebtedness, cost share transfers, and cost share encumbrances.
 Error handling after the batch process: Identifies and de-merges errors to be corrected using the G/L Correction
Process (GLCP) document.
While represented here as separate steps for clarity, note that the transaction validation, offset generation, transaction
generation and de-merging process are all part of the KFS batch job 'scrubberJob.' Each of these functions is discussed
in more detail below.
Validation of Data
Data must be validated before being posted to the G/L to ensure that it is complete and correct. Before ledger entries are
posted to the G/L, a transaction validation process is run to ensure that bad data, such as transactions applied to non-
existent object codes or accounts, are not posted to the ledger.
Financial transaction documents generate pending ledger entries automatically. The KFS validates transactions created
via e-docs in various ways, using the Chart of Accounts and business rules to ensure that the entries generated are
complete and without errors. Even so, these transactions undergo the same 'Scrubber' validation as entries from other
sources.
Transactions from External Systems

Transactions that are fed into the KFS from an outside system (such as a payroll or external billing system) are more
likely to send the KFS data in need of correction because they may not be integrated with the KFS Chart of Accounts.
For example, an external system might try to apply expenses to a closed account because that external system does not
have access to the data in the KFS Chart of Accounts.
Transaction Validation Business Rules

The transaction validation process checks to make sure that accounting string values (such as account, object code and
sub-object code) are valid. It also ensures that the transaction has proper identifying information (such as a document
number, document type and origination code indicating the system it came from) attached.
Because some systems may not be capable of providing all of the information required to post a General Ledger
transaction, 'Scrubber' may assign some attributes to complete the transaction.
If necessary, 'Scrubber' can assign a fiscal year, fiscal period, and transaction date to a transaction based on the system
date (which is determined by the date on which the batch process is run). It can also assign an object code type based on
the object code of the transaction.

Table 39 Sample of transaction validation business rules and error messages
No Rule Action or ERROR MESSAGE
1 Origin code must exist in the Origin ORIGIN CODE NOT IN THE ORIGIN
Code table. TABLE
2 Document number is required. DOCUMENT NUMBER IS

REQUIRED
3 Chart code must exist in the Chart CHART CODE NOT IN THE CHART
table. TABLE
4 Chart code must be 'Active.' CHART CODE IS NOT ACTIVE
5 Account number must exist in the ACCOUNT NUMBER IS NOT IN THE

Account table. ACCOUNT TABLE
6 If the Origin code indicates a Kuali ORIGIN CODE CANNOT HAVE A

e-doc or an institution-selected CLOSED ACCOUNT
external application source, the
account must be 'Open', unless the
document type is 'Year-End Closing'
and the balance type indicates
beginning balance.
7 If a sub-account is entered, it must SUB-ACCOUNT IS NOT IN SUB-

exist in the Sub-Account table. ACCOUNT TABLE
8 If a sub-account is entered, it must SUB-ACCOUNT CODE IS NOT

be 'Active.' ACTIVE
9 Object code must exist in the Object OBJECT CODE IS NOT IN THE
Code table. OBJECT CODE TABLE
10 If a sub-object code is entered, it Action: If Sub Object Code is

must exist in the Sub-Object Code null/blank or if it doesn't exist in table,
table. dashes are substituted.
11 Balance type must exist in the BALANCE TYPE CODE IS NOT IN

Balance Type table. THE BALANCE TYPE TABLE
12 Object type code must exist in the OBJECT TYPE CODE IS NOT IN
Object Type table. THE OBJECT TYPE TABLE
13 Fiscal year must exist in the Options FISCAL YEAR IS NOT IN THE
Maintenance table. OPTIONS MAINTENANCE TABLE
14 Fiscal period code must exist in the FISCAL PERIOD CODE IS NOT IN
Accounting Period table THE ACCOUNTING PERIOD TABLE
15 Fiscal period must be 'Open.' FISCAL PERIOD IS CLOSED
16 Transaction entry sequence number Action: If null/blank/non-numeric,

must be numeric. zeroes are substituted.
17 Transaction ledger entry amount LEDGER AMOUNT IS NOT

must be numeric. NUMERIC

18 If Balance type offset generation NEGATIVE AMOUNT IS INVALID
attribute is 'Y' or 'C', then transaction WHEN OFFSET GENERATION
ledger entry amount must be greater CODE=Y OR C
than or equal to zero.
19 If Balance type offset generation DEBIT/CREDIT CODE MUST BE

attribute is 'N', then Transaction SPACE
debit/credit code must be blank or
null.
20 If Balance type offset generation DEBIT/CREDIT CODE IS NOT D OR

attribute is not 'N', then transaction C
debit/credit code must be 'C' or 'D.'
21 Transaction date must exist in the In this case the invalid date will be
University Date table. replaced with the current date.
22 Document type must exist in the DOCUMENT TYPE IS NOT IN THE

Document Type table. DOCUMENT TYPE TABLE
23 If a project code is entered, it must PROJECT CODE IS NOT IN THE

exist in the Project Code table. PROJECT CODE TABLE
24 If a project code is entered, it must PROJECT CODE IS CLOSED

be 'Active.'
25 If reference document number is not REFERENCE DOCUMENT TYPE IS

blank or null, then reference NOT IN THE DOCUMENT TYPE
document type must exist in the TABLE
Document Type table.
26 If reference document number is not REFERENCE ORIGINATION CODE

blank or null, then reference origin IS NOT IN THE ORIGIN CODE
code must exist in the Origin Code TABLE
table.
27 If transaction encumbrance update REFERENCE DOCUMENT NUMBER

code is 'R', then reference document CANNOT BE SPACE
number must not be blank or null.
28 If reversal date is entered, it must REVERSAL DATE IS NOT IN THE

exist in the University Date table UNIVERSITY DATE TABLE
29 If balance type encumbrance ENCUMBRANCE UPDATE CODE IS

indicator is 'Y' and object type fund NOT=D OR R OR N
balance indicator is 'Y', then
transaction encumbrance update
code must be 'D', 'R', or 'N.'
30 If object type code is expense type SUB-FUND GROUP IS NOT IN THE

and balance type code is 'Actuals' or SUB-FUND GROUP TABLE
'Encumbrance,' then sub-fund group
must exist in the Sub-Fund Group
table.
(Sub-fund group is determined via
account number.)

Continuation Account for Expired Account
Special logic is also applied in 'Scrubber' to determine whether a continuation account should be substituted for the
account on a transaction. This logic is triggered when the account on the transaction has an expiration date or is closed.
When configuring the KFS, institutions may choose to exclude transactions with certain origination codes, balance types,
and document types from the Scrubber's application of the continuation account logic. For example, in most instances
users want to exclude transactions generated by KFS e-docs from this process. Financial e-docs include a process that
allows the document initiator to use the expired account or the account's continuation account. This option is available
based on settings in two system parameters: CONTINUATION_ACCOUNT_BYPASS_DOCUMENT_TYPES and
CONTINUATION_ACCOUNT_BYPASS_ORIGINATIONS.
If a transaction applies to an expired account and is not otherwise excluded, 'Scrubber' attempts to find a valid
continuation account to substitute. Accounts are considered expired if their expiration date is less than or equal to the run
date of 'Scrubber' batch process. The expiration date of Contracts and Grants accounts may be extended by any number
of days for the purpose of determining expiration for this process with the
CG_ACCOUNT_EXPIRATION_EXTENSION_DAYS parameter.
AUTO FR
The KFS makes ten attempts at finding a valid continuation account before reporting an
error. 'Valid' in this instance means that the account exists in the Account table and is not
expired or closed. If a substitution is made, the KFS adds AUTO FR and the original account
number into the transaction description for tracking purposes.
Pre-Scrubber Function
The 'Scrubber' also includes a pre-scrubber function that can be used to complete Chart of Account code values for
entries that do not contain them. This function will be used only if your institution has decided not to allow the same
account number to be used on multiple Charts of Accounts (the KFS-SYS ACCOUNTS_CAN_CROSS_CHARTS_IND
parameter must be set to 'N'). In this case a special step will complete the Chart of Accounts code on incoming
transactions if it is blank. Note that the pre-scrubber will not correct invalid chart/account combinations (these will
become 'Scrubber' errors) and will not complete the Chart of Accounts field if the supplied account number is invalid.
Also, the setting of this parameter will have no impact on the function of Account maintenance documents.
G/L Correction Process

If an error is encountered during any part of the validation process, the associated document(s) are not posted. Instead,
error records are placed in the ScrbErr file (for more on G/L files see Accounting Cycle Files. This file can be retrieved
using a G/L Correction Process (GLCP) document. This process allows for the manual correction of errors so the
associated documents may be re-posted in a future batch cycle.
For information on the G/L Correction Process (GLCP) document, see G/L Correction Process
(GLCP).
Offset Generation

Figure 148 - Offset generation
'Scrubber' also ensures that all transactions are balanced, and it generates required offsets with an offset generation
process.
For transactions created via KFS e-docs, offsets should already be in place. The KFS ensures that these transactions are
balanced by automatically generating any required offsets when each document is submitted for approval. Prior to the
batch process running, the offset transaction lines (such as offsets to cash) may be viewed within the General Ledger
Pending Entries tab of a financial transaction document.
The KFS uses the Offset Definition table to define how offsets should be generated for unbalanced transactions. This
table uses information from the unbalanced transaction (such as the fiscal year and chart the transaction is being posted
to and the balance type and document type associated with the transaction) to determine the object code to assign to
offset entries. Ledger entries created with a Journal Voucher document type are specifically excluded from the offset
generation process.
Transactions created in other systems may need to have offsets generated to ensure a balanced transaction. As part of the
system implementation process, users must verify that all external system feeds into the KFS are appropriately addressed
in the Offset Definition table.
Business Rules
The offset transactions are generated in the following cases:
 Document type is not included in the OFFSET_GENERATION_DOCUMENT_TYPES parameter (JV and

ACLO document types are excluded in the base data).
 Fiscal period is not included in the OFFSET_GENERATION_FISCAL_PERIODS parameter (Periods BB and

CB are excluded in the base data.)
 If otherwise eligible and offset generation attribute for the balance type of the pending entry is 'Y.'
Transaction Generation
Figure 149 - Transaction generation
In addition to the basic balancing offsets, additional processes in 'Scrubber' can be turned on or off by your institution.
The following processes generate behind-the-scenes transactions and are discussed in detail below:
 Capitalization of movable and non-movable assets and of liabilities for lease purchases
 Plant indebtedness related to bonds
 Cost share transfers
 Cost share encumbrances
Capitalization of Assets and Liabilities

'Scrubber' generates entries and offsets to properly record the capitalization of assets and liabilities. The KFS determines
which items need capitalization entries by looking for transactions affecting 'Actuals' balance type and using an object
code with an asset-related object sub-type (defined in the parameter CAPITALIZATION_OBJECT_SUB_TYPES).
If is the process determines that a qualifying capital expenditure has occurred, it generates capitalization entries to book
an asset to the appropriate plant fund account under the appropriate plant fund object code. The appropriate account is
generally the plant fund account associated with the organization owning the account on which the original transaction
occurred (for movable assets) or the plant fund account associated with that organization's campus (for non-movable
assets).
The KFS includes 'Generated Capitalization' or 'Generated Liability' in the transaction description of the generated entry
and also sets the object code type to 'Asset' or 'Liability' as appropriate. The object sub-type of the expenditure
determines the object code used on the generated entry (defined in the parameter
CAPITALIZATION_OBJECT_CODE_BY_OBJECT_SUB_TYPE).
Transactions created on journal vouchers, transfer of funds, auxiliary vouchers (accrual type) or the Annual Closing
(ACLO) document type are generally excluded from the capitalization process. This list of document types is defined
and may be modified in the CAPITALIZATION_DOCUMENT_TYPES parameter. Transactions associated with
particular sub-fund groups or charts may also be institutionally excluded from the capitalization process using one or
more of these parameters:
 CAPITALIZATION_CHARTS defines charts excluded from the capitalization process.
 CAPITALIZATION_FISCAL_PERIODS defines fiscal periods excluded by the capitalization process.
 CAPITALIZATION_SUB_FUND_GROUPS defines the sub-fund of accounts that should be excluded from

the capitalization process.
 CAPITALIZATION_IND contains a yes ('Y') or no ('N') value that indicates whether or not the capitalization
process should be active.
Plant Indebtedness
Plant indebtedness entries for notes and bonds payable are similar in nature to the capitalization entries, with a few
exceptions. The original plant indebtedness entries occur on liability object codes (a balance sheet item) and, because
there are fewer classifications, the same object code is used to record the item in the plant fund. Whereas the
capitalization entries add items to the balance sheet (set up assets), these entries move the liability from select fund
groups to the plant fund.
To generate the bond and note liability in the plant fund, a transaction must have a balance type of 'Actuals' and belong
to an institutionally-specified sub-fund group (defined in the PLANT_INDEBTEDNESS_SUB_FUND_GROUPS
parameter) and object code sub-type (defined in the PLANT_INDEBTEDNESS_OBJECT_SUB_TYPES parameter).
The process then uses the organization associated with the account of the original transaction to determine the correct
plant fund account number. The campus plant fund account is always used for plant indebtedness entries.
The KFS includes 'Transfer to Net Plant' in the transaction description of the entry occurring in the original account and
sets the description of the entry occurring on the plant fund account to 'Generated Transfer from (chart and account
number of original entry).' In addition, appropriate offsets to the fund balance object code are also generated to balance
the entries.
Cost Share Transfers

Cost sharing allows for sharing of costs related to Contracts and Grants accounts. Expenses associated with a grant or
contract that are not paid by the sponsoring agency are considered to be cost share, and the KFS can track these expenses
in special cost share sub-accounts. A cost share sub-account is created as part of the contract or grant account for which

costs are being shared. The sub-account is also assigned a 'source account' that identifies the account that actually bears
the expenses that are being shared.
Cost share transfers involve transferring funds into a Contracts and Grants cost share sub-account (to record income),
from the source account (to record the charge).
Any expense that occurs on a cost share sub-account is eligible for this transfer of funds. Expenses occurring on selected
document types may be excluded from the generation of cost share by adding them to the
COST_SHARE_DOCUMENT_TYPES parameter. In the base data, the journal voucher or auxiliary voucher (accrual
type) are excluded from cost share generation via this parameter.
In order to qualify for cost share transfers, the transaction must:
 be associated with an expense object code type (defined in the COST_SHARE_OBJECT_TYPES parameter)
 have a balance type of 'Actuals,' and
 be on a Contracts and Grants account and a sub-account with a sub-account type of 'CS.'
Cost share transfers are posted at a summary level. For the income side of the transfer the document type is 'TF (Transfer
of Funds)' and the object code is an institutionally-defined transfer of funds revenues code (defined by the
COST_SHARE_OBJECT_CODE parameter). The origin code of the transaction is set to 'CS (cost share),' the document
number is pre-fixed with 'CSHR,' the transaction description is set to 'Generated Cost Share from account XXXXXXX
MM/DD,' and the transaction date is set to the run date of the process. An appropriate offset to cash for the income side
of the transfer is also generated.
For the expense side of the transfer, much of the above logic applies with a few changes. The chart, account, and sub-
account for the source account that was found on the sub-account table are used. The transaction description is set to
'Generated Cost Share from account XXXXXXX MM/DD.' The correct object code to use for the charge is determined
by the object code level. A KFS parameter (COST_SHARE_OBJECT_CODE_BY_OBJECT_LEVEL) maps object
code levels to specific institution-defined object codes to which the cost hare transfers are recorded.
Cost Share Encumbrances

Cost share encumbrances are a management tool that enables the fiscal officer of a source account to forecast the cost
share transfer activity that occurs after expenses are realized on the Contracts and Grants cost share sub-account. Any
encumbrances on a cost share sub-account trigger the generation of cost share encumbrances in the source account.
The KFS checks the encumbrances associated with a cost share sub-account and generates matching encumbrances on
the source account to reflect where these expenses are ultimately applied. Eligible transactions must:
 have an expense object type (defined in the COST_SHARE_OBJECT_TYPES parameter),
 have an encumbrance balance type (defined in the COST_SHARE_ENCUMBRANCE_BALANCE_TYPES

parameter),
 be on a Contracts and Grants account and a sub-account with a sub-account type of 'CS,' and
 not be associated with a document type that appears in the COST_SHARE_DOCUMENT_TYPES parameter.
These encumbrances are created with a cost share encumbrance balance type to ensure that they can be distinguished
from the original encumbrances. Cost share encumbrances are posted at the detail level, using the same object code level
mapping that was used for cost share transfers.
Transaction Validation Reports

Each run of the G/L transaction validation process generates the following reports.

Transaction Validation Statistics show the summary record counts of the transactions and the list of errors (if any).
Figure 150 - Scrubber Report Statistics
Figure 151 - Transaction Validation Statistics summary section
The chart above is also shown as part of the preceding figure.

Figure 152 - Part of Transaction Validation Ledger (scrubber_ledger)
Figure 153 - Transaction Validation Bad Balance Type errors (scrubber_badbal)

Figure 154 - Part of Transaction Validation Errors Report (scrubber_error)

G/L Demerger Process
Figure 155 - Demerge process
The G/L transaction demerger process is initiated as part of the overall 'Scrubber' process and prior to 'Main Poster' in the
'Poster' process. The demerger process has several functions.
 Using the errors identified by earlier parts of the 'Scrubber,' it locates all of the accounting entries for each
document number with a reported error and removes these transactions from processing. This action prevents
KFS from posting unbalanced transactions to the General Ledger.
 It removes any offsets that were generated by the 'Scrubber' for the document numbers with errors. 'Scrubber'-
generated offsets are removed to prevent duplicate offset generation when the records are passed back through
the accounting cycle after correction.
 The process creates a ScrbErr2 file in the Origin Entry table with all of the transactions for document numbers
with errors. (ScrbErr2 is the primary error correction file for the G/L Correction Process e-doc). It also
generates statistics as part of the accounting cycle control totals, recording the number of records in the error
group, the number of each type of offset bypassed, the number of records passed to the Main Poster, etc.
 It creates the following report:
Figure 156 - G/L Demerger Report

G/L Posting ('Poster')
Figure 157 - 'Poster' process
This process applies the pending ledger entries, including any KFS-generated entries, to the G/L. The posting function
('Poster') is a batch process distinct from 'Scrubber' function processes whose main function is to validate transactions.
'Poster' is actually made up of several processes that post and generate transactions. The posting process occurs in the
following distinct phases (or modes) with several steps within each phase.
 G/L Account Balance Posting ('Main Poster')
 Reversal Poster
 Indirect Cost Recovery (ICR) Transaction Generation
 ICR Poster
The G/L Posting process is represented in the following diagram.
Figure 158 - G/L Poster process

G/L Account Balance Posting ('Main Poster')
This process posts the entries to the G/L, updating the tables that make up the G/L. Prior to this process being run, entries
are again validated to ensure that there are no errors in the transactions that might have been generated by other parts of
the G/L processing (such as offset generation or capitalization). If errors are found, the affected transactions are not
posted and are dropped into the PostErrs file. This file can be retrieved and corrected using the General Ledger
Correction Process document.
For more information about this file and other files generated by the G/L batch processes, see
Accounting Cycle Files.
Final Validation
The validation criteria are listed in the business rules below:
Table 40 Sample of final transaction validation business rules

No. Rule Error Message
1 Chart code must exist in the Chart ORIGIN CODE NOT IN THE ORIGIN
table. TABLE
2 Account number must exist in the ACCOUNT NUMBER IS NOT IN THE

Account table. ACCOUNT TABLE
3 Balance type must exist in the BALANCE TYPE CODE IS NOT IN

Balance Type table. THE BALANCE TYPE TABLE
4 Object type code must exist in the OBJECT TYPE CODE IS NOT IN THE
Object Type table. OBJECT TYPE TABLE
5 Fiscal year must exist in the Options FISCAL YEAR IS NOT IN THE
Maintenance table. OPTIONS MAINTENANCE TABLE
6 Transaction ledger entry amount LEDGER AMOUNT IS NOT NUMERIC

must be numeric.
7 If balance type offset generation DEBIT/CREDIT CODE MUST BE

attribute is 'N', then transaction SPACE
debit/credit code must be blank or
null.
8 If balance type offset generation DEBIT/CREDIT CODE IS NOT D OR C

attribute is not 'N', then transaction
debit/credit code must be 'C' or 'D.'
G/L Balance Update

Validated G/L origin entries update the G/L Balance table according to the following business rules.

Table 41 G/L balance update business rules
Balance Updated Fiscal Offset Debit/Credit Action on

Period Generation Code same Balance
Code Code of as default of Add (+)
Balance Object Type Subtract (-)
Type
Annual Balance AB N n/a +
AB Y Y +
AB Y N -
Beginning Balance BB N n/a +
BB Y Y +
BB Y N -
Cumulative CB N n/a +
Beginning Balance
CB Y Y +
CB Y N -
Annual Balance 01 through N n/a +

and 13
Period Balance
01 through Y Y +
13
01 through Y N -
13
G/L Encumbrance Update

The G/L posting function evaluates the pending ledger entries to determine whether they affect encumbrances. For
entries that satisfy all the following business rules (see the Encumbrance Update Business Rules table in Open and
Closed Encumbrance Amounts), the G/L Encumbrance table is updated:
 Transaction encumbrance update code must be 'D' (document) or 'R' (reference document), and
 Object type must not be a fund balance object type.
 Balance type must be identified as an encumbrance on the Balance Type table.

Open and Closed Encumbrance Amounts
When posting the G/L encumbrance entries associated with a new encumbrance, a new entry in the G/L Encumbrance
table is added with the encumbrance amount set to the total entry amount. This is accomplished by passing entries to the
accounting cycle with a 'D' in the Encumbrance Update Code. This entry tells 'Poster' to insert or update a row into the
Open Encumbrance file using the document number and to put the amount in the Open Amount column. When posting
any subsequent adjustment to that encumbrance, increases or decreases are made to the Encumbrance Close Amount
column for that item by passing entries to the accounting cycle with an 'R' in the Encumbrance Update Code. This value
tells 'Poster' to insert or update a row in the Open Encumbrance file using the reference document number of the entry
and to adjust the amount in the Closed Amount column. Consequently, the Open Encumbrance file shows both the
amount of the original encumbrance (open amount) and the amount of the encumbrance that has been relieved (closed
amount).
These entries may easily be viewed in the application through the Open Encumbrance report. For
more information see Balance Inquiries in the Guide to the KFS Main Menu.
Table 42 Encumbrance update business rules

Transaction Debit/Credit Action on Encumbrance Amount Updated
Encumbrance Code Encumbrance
Update code Amount
D 'D' (Debit) or + (Add) Encumbrance Amount for the

(Document) blank particular Document Type, Origin
Code, Document Number
Other - (Subtract)
R (Reference 'D' (Debit) or - (Subtract) Encumbrance Closed Amount for

Document) blank the particular Reference Origin
Code, Document Reference Type
Code, Reference Document
Number
Purchase Order (PO) Encumbrance Amounts

Purchase order encumbrance entries are handled differently because a single purchase order may have several document
numbers in the KFS. Each time the purchase order is amended or otherwise modified, a new document number is
generated for that transaction but the purchase order number remains the same. To ensure that the open amount updates
correctly and payments are properly associated with the right purchase order number, the parameter
ENCUMBRANCE_OPEN_AMOUNT_OVERRIDING_DOCUMENT_TYPES defines the document types that should
always update the open amount of the Encumbrance table. This parameter contains all the document types used to
identify purchase orders.
The purchase order number is included in the Reference Document Number field of entries from these document types
and the Encumbrance Update Code is set to 'R.' This creates a new or edits an existing open encumbrance amount using
the purchase order number as the reference. Payment requests or credit memos applied to the PO also include the
purchase order number in the Reference Document Number field and have an Encumbrance Update Code of 'R.' Because
these values are not in the ENCUMBRANCE_OPEN_AMOUNT_OVERRIDING_DOCUMENT_TYPES parameter,
they always increase or decrease the Encumbrance Close Amount column for that item.
Future Reversal Update

This function in the posting process identifies G/L origin entries that contain a date in the Reversal Date field. These
transactions are stored in the G/L Reversal table. When the reversal date is reached, reversing entries are generated and
automatically posted to the G/L tables.
Sufficient Funds Rebuild

The Chart of Accounts structure is built into the Sufficient Funds Balance table. The main run of the G/L process checks
the Sufficient Funds Balance table against the parallel supporting Chart of Accounts tables for discrepancies. Any
differences that are detected are incorporated into the Sufficient Funds Balance table chart structure and the sufficient
funds balances are re-calculated (for example, an account may have changed from account level checking to
consolidation level checking). This keeps the Sufficient Funds Balance table aligned with the sufficient funds checking
options established for each account.
Figure 159 - Sufficient Funds Statistics (sufficient_funds)
Sufficient Funds Balance Update

For entries that satisfy all the business rules below, the G/L sufficient funds balance is updated.
The account sufficient funds code is used to determine the level at which Sufficient Funds Balances are maintained. The
five possibilities are listed below. Each defines the scope of a specific sufficient funds check. Sufficient funds checking
never occurs for income object codes.
Table 43 Sufficient funds balance update by object

Object Explanation
Account Budget vs. actual vs. encumbrance check in account, combining

the activity of all object codes with one of the expense object types
Object Budget vs. actual vs. encumbrance check for the combination of all
Consolidation of the object codes in the object consolidation to which the object

code reports
Object Level Budget vs. actual vs. encumbrance check for combination of all the
object codes in the object level to which the object code reports
Object Code Budget vs. actual vs. encumbrance check for the individual object
code only
Cash Cash balance minus liabilities minus encumbrances
The Budget Checking Options Code on the Systems Options Maintenance table is not
used here. This code is used by the e-docs to determine whether or not to perform
sufficient funds checking.
Sufficient Funds Business Rules

The Account Sufficient Funds Code value must be a valid code indicating the object of the sufficient funds checking.
 'O' Object Code
 'L' Object Level
 'C' Object Consolidation
 'H' Cash at Account
 'A' Account
 'N' No Checking
Table 44 Sufficient funds update business rules
Object Type Balance Debit/ Action on Amount updated

Type Credit amount
Expenditure/ Actuals (AC) D + (Add) Account actual

Expense (EX) expenditure
amount
Expenditure/ Not Blank/Nu + (Add)
Expense (EE) ll
Transfer of
Funds/ Expense C - (Subtract)
(TE)
Expense/ Not External D + (Add) Account
Expenditure (ES) Encumbranc encumbrance
e (EX) amount
Blank/Nu + (Add)
ll
C - (Subtract)

Internal D + (Add) Account
Encumbranc encumbrance
e (IE) amount
Blank/Nu + (Add)
ll
C - (Subtract)
Pre- D + (Add) Account

e (PE) amount
Blank/Nu + (Add)
ll
C - (Subtract)
Cost Share D + (Add) Account

e (CE) amount
Blank/Nu + (Add)
ll
C - (Subtract)
Budget Any + (Add) Current budget

Check balance amount
Table 45 Sufficient funds business rules for cash
Balance Type Object Code/ Debit/Credi Action on Amount updated

t Code amount
Object Type
Actuals Cash Object D + (Add) Current budget

Code balance amount
Blank/Null + (Add)
C - (Subtract)
Accounts D + (Add) Current budget

Payable balance amount
Object Code
Blank/Null + (Add)
C - (Subtract)
Other n/a n/a None

External Expenditure/ D + (Add) Account
Encumbrance Expense encumbrance
(EX) (EX) amount
Blank/Null + (Add)
C - (Subtract)
Internal Expenditure/ D + (Add) Account

(IE) (EX) amount
Blank/Null + (Add)
C - (Subtract)
Pre- Expenditure/ D + (Add) Account

(PE) (EX) amount
Blank/Null + (Add)
C - (Subtract)
Cost Share Expenditure/ D + (Add) Account

(CE) (EX) amount
Blank/Null + (Add)
C - (Subtract)
Expenditure/ D + (Add) Account

Not Expense encumbrance
(EE) amount
Blank/Null + (Add)
C - (Subtract)
Transfer of D + (Add) Account

Funds/ encumbrance
Expense amount
Blank/Null + (Add)
(TE)
C - (Subtract)
Expense/ Not D + (Add) Account

Expenditure encumbrance
(EE) amount
Blank/Null + (Add)
C - (Subtract)

G/L Account Balance Posting
The G/L posting function evaluates the pending ledger entries to determine whether or not they affect account balances.
For entries that satisfy both the following business rules, the G/L account balance is updated:
 Balance type indicates actuals or budget checking and
 Balance type indicates encumbrance and object type does not indicate fund balance
G/L account balances are updated according to the following rules.
Table 46 G/L account balance update business rules

Balance Type Debit Credit Offset Action on Balance Amount
Code Generation Balance Updated
Code of Amount
Balance
Type
Budget (CB) Any Any + (Add) Current budget

balance amount
Actual (AC) Default Any + (Add) Actuals balance

Debit/Credit amount
Code for the
Object Type
Null/blank N + (Add)
Other - (Subtract)
Other Any - (Subtract)
Encumbrance Default Any + (Add) Encumbrance

Debit/Credit balance amount
Code for the
Object Type
Null/blank N + (Add)
Other - (Subtract)
Other Other - (Subtract)
G/L Detail Posting

Validated G/L pending entries are recorded as G/L detail. When posting the detail, the Transaction Entry Sequence
Number value is used to ensure a unique key.
G/L Reporting
Each run of the G/L process generates statistics and summary reports. Errors, if any, are displayed at the top of the
report.

Figure 160 - Main G/L Posting Statistics
Figure 161 - Part of Main G/L Posting Ledger
Figure 162 - Part of Main Poster Error Transaction Listing (poster_main_error_list.pdf)

Figure 163 - Part of G/L Summary, Actual (gl_summary _act)
Figure 164 - G/L Summary, Budget (gl_summary_bud)

Figure 165 - G/L Summary, Encumbrance (gl_summary_enc)
Reversal Poster
This function processes any reversal entries that have a reversal date equal to or earlier than the current date. Reversal
dates may be entered on a select group of e-docs such as the journal voucher or accrual voucher or may be provided by
batch feeds from other systems.
Business Rules
This process derives the fiscal year and period code from the reversal date unless that period is closed, in which case the
current period is used. It reverses the debit/credit code of the original transaction, appends the prefix 'AUTO-
REVERSAL' to the document description, and sets the reversal date to blank. Entries are validated to ensure that there
are no errors and then posted to the G/L.
Additional validation is performed on the Reversal Date value:
 If this date is not found in the University Date table, the transaction is flagged as an error (the message 'DATE
FROM G/L REVERSAL IS NOT IN THE UNIVERSITY DATE TABLE' is generated) and reversal processing
stops for this transaction.
 If the reversal date is not in the Fiscal Period table, the transaction is flagged as an error (the message
'REVERSAL DATE IS NOT IN FISCAL PERIOD' is generated) and reversal processing stops for this
transaction.
 If the Fiscal Period has a status of 'CLOSED,' use the current date and fiscal period instead, unless the current
date is not in the University Date table.
 If the current date is not in the University Date table, flag the transaction as an error (the message 'CURRENT
DATE IS NOT IN THE UNIVERSITY DATE TABLE' is generated) and reversal processing stops for this
transaction.
 Following the same business rules used in the main G/L posting function, the pending reversal entries
(generated G/L origin entries) are evaluated to determine whether or not they should be included for ICR. For
entries that satisfy the business rules (below), G/L expense transactions are generated.
Following the same business rules used in the main G/L posting function, the pending reversal entries are evaluated to
determine whether or not they affect encumbrances. Entries that satisfy the G/L encumbrance business rules (above)
update encumbrances.
Similarly, pending reversal entries that satisfy the sufficient funds business rules (the same business rules used in the
main G/L posting function) update sufficient funds balances.

Pending reversal entries that satisfy the G/L account balance business rules (the same business rules used in the main
G/L posting function above) update G/L account balances.
Reversal Poster Report

The G/L reversal process generates the following reports:
Figure 166 - G/L Reversal Statistics

Figure 167 - Part of Reversal Poster Ledger (poster_reversal_list)
Figure 168 - Part of Reversal Poster Listing (poster_reversal_list)
Figure 169 - Part of Reversal Poster Error Transaction Listing (poster_reversal_error)
ICR Calculation and Posting ('ICR Poster')

Pending ledger entries are evaluated for eligibility for automated ICR generation. This process has three parts:
 ICR expense and income entries
 ICR encumbrance entries
 ICR transaction posting
ICR Expense and Income Entries

ICR expenses and income entries are generated using the values defined on the Indirect Cost Recovery Rate table.
To generate indirect costs, transactions must have an object type code that has the ICR Selection Type value set to 'Yes'
and the Indirect Cost Rate of the account must not be blank.
Additional criteria further restrict the expenses that may be included in the ICR calculation. The Indirect Cost Recovery
Exclusions by Account table is checked for any specific exclusion by account and object code. The Indirect Cost
Recovery Type value assigned to the account is also referenced for exclusions using the Indirect Cost Exclusion by Type
table.
The Indirect Cost Rate table is then used to create the ICR expense and income transactions. Transactions are created by
referencing fiscal year, balance type, and ICR percent on this table. The table contains the accounting strings and the
rates to use for each indirect cost rate.

For generated entries, the document number is set to the run date (YYYYMMDD), and the transaction identifies the item
as a charge or income with the ICR type, ICR percentage, object code of the original expense, and direct cost amount.
The document type is set to 'ICR' (or the value your institution defines in the
INDIRECT_COST_RECOVERY_DOCUMENT_TYPE parameter.) The chart, account number, sub-account, object
code, sub-object code, and debit/credit code are based on the values in the Indirect Cost Recovery Rate table. The
amount of the ICR transaction is set to the original direct cost amount times the ICR percent identified on the table.
ICR Income and Expense Transaction Business Rules

The ICR income and expense transactions are generated in the following cases:
 ICR indicator of the object type indicates expenditures directly related to a project.
 Indirect cost rate ID of the account number must exist in the Account table.
 Fiscal period code is 01 through 13.
 Sub-account type code must not indicate a cost share account.
 Object code exists in the Object Code table.
 Chart code, account number, 'reports to' chart code of object code, and 'reports to' object code do not exist in the
Indirect Cost Recovery Exclusions by Account table (by agreement with sponsor or agency, some types of
direct expenses may not be eligible for ICR).
 Chart code, account number and object code do not exist in the Indirect Cost Recovery Exclusions by Account
table (the COA/Account is excluded for some object codes, but not the reports-to object code).
 ICR type code of account and the expense object code do not exist in the ICR Exclusion by Type table.
 ICR type code of the account, 'reports to' chart code of object code, and 'reports to' object code do not exist in
the ICR Exclusion by Type table. (Sponsor or agency does not reimburse some types of expenses that the
institution groups by object code within ICR type code.)

Figure 170 - Poster ICR Report Statistics (poster_icr)
Figure 171 - Part of ICR Poster Input Transaction Report (poster_icr_ledger)
Figure 172 - ICR Generation Report Statistics (icr_generation)

Figure 173 - ICR Poster Error Transaction Listing (poster_icr_error_list)
ICR Encumbrances
This is the second step in the reversal and calculation of ICR encumbrances. The process retrieves all G/L encumbrances
that do not have an ICEN document type (non-ICR encumbrances). It groups these by fiscal year, chart, account, sub-
account, object code, sub object code and balance type code. It sums the encumbrance amount and sums the
encumbrance close amount for this grouping.
ICR then is processed on each row as described above for ICR Expense and Income Entries, effectively calculating
indirect cost on the amount of the encumbrance that remains open for each grouping. After ICR entries have been
calculated, the process posts them to the G/L.
In order for the ICR encumbrances to be processed, the system parameter USE_ICR_INDICATOR must be set to 'Y.'
Poster Output Summary

When the batch process is complete, the following summary report is generated:
Figure 174 - Poster Output Summary (poster_output_summary)

Sufficient Funds
Sufficient Funds is an option that can be used to stop the processing of e-doc transactions when an account does not have
sufficient balances to cover expense transactions.
Sufficient funds checking is optional and can be established on an account-by-account basis. If the TP Sufficient Funds
Check option on an account is selected and the Account Sufficient Funds Code is set to a value other than 'N' (no
checking), then the account is checked for sufficient funds by the KFS.
For more information about the TP Sufficient Funds Check option, see Account in the Guide to
the KFS Main Menu.
The account sufficient funds code of an account determines the level at which sufficient funds is checked. The options
are:
 Object Code: The specific object code to which expenses are being applied is checked to see whether sufficient
budget exists.
 Level: The object level with which the expense object code is associated is checked to see whether sufficient
budget exists.
 Consolidation: The consolidation level with which the expense object code is associated is checked to see
whether sufficient budget exists.
 Account: The budget balances of all expense object codes on the account are added up and checked to see
whether sufficient budget exists.
 Cash: The cash balance of the account is checked to see whether sufficient cash exists.
Object code, level, consolidation and account checks are all made by comparing budget to actuals. The calculation used
is:
Sufficient Funds = Budget - Actuals - Encumbrances +/- Pending Ledger Entries
Cash checking uses a different formula:
Sufficient Funds = Cash Balance - Liabilities - Encumbrances +/- Pending Ledger Entries
The encumbrances include pre-encumbrances, external encumbrances, and internal

encumbrances, depending on the account.
If the KFS finds that an account does not have sufficient funds, it presents the user with an error message and does not
allow further processing of the document.

Figure 175 - An error message is displayed in the Accounting Lines tab.
A message displayed in the Accounting Lines tab indicates which account does not have sufficient funds.
Not all KFS financial document types perform sufficient funds checking. The following
document types do not check for sufficient funds:
 Advance Deposit
 Auxiliary Voucher
 Cash Management
 Cash Receipt
 Credit Card Receipts
 Journal Voucher
 Pre-Encumbrance
 Procurement Card

Flexible Offset
The KFS uses the Offset Generation table to generate the appropriate offsets for transactions. This table indicates the
object code used in offset generation, based on the transaction's chart, fiscal year, document type, and the balance type it
affects. Offsets are generated automatically by a KFS e-doc or in 'Scrubber' during G/L processing.
Normally, offsets are applied to the same account as the transaction that generated the offset. But the KFS has a flexible
offset feature that allows institutions to have offset entries applied to different accounts. This KFS feature includes two
functions:
 Flexible banking offset
 Flexible offsets by account

Flexible Banking Offsets
Document types that require a user to specify a bank account number (such as the Advance Deposit or Credit Card
Receipt documents) can apply offset entries to a special account associated with this bank account number. If the
ENABLE_BANK_SPECIFICATION_IND parameter is set to 'Y,' an additional set of cash entries is created to a
designated accounting string (chart, account, sub-account, object code, and sub-object code) defined in the Bank
document. These entries occur in addition to the normally generated cash offsets created to balance a set of transactions.
In effect, they reclassify the generic cash entry to a bank-specific cash entry for reconciliation and tracking purposes. If
the ENABLE_BANK_SPECIFICATION_IND parameter is set to 'N,' the normal balancing cash entries are created but
the reclassification of cash to a bank-specific entry is not performed.
This option allows the user to specify the document types on which a bank code should appear. This information, which
is specified in the BANK_CODE_DOCUMENT_TYPES parameter, allows you to specify bank information on
additional document types that create disbursements or record revenue. A default Bank Code value should be established
for each document type by using the DEFAULT_BANK_BY_DOCUMENT_TYPE parameter.
For more information about the Bank Account document, see Offset Account in the Guide to
the KFS Maintenance Menu.

Flexible Offsets by Account
This option allows the KFS to redirect offset entries for an account to another specified account. It allows the KFS to
accommodate tracking offsets such as cash or liabilities in central designated accounts as opposed to tracking such offset
entries in every account. The Offset Account document identifies the offset account for an object code and account
number combination.
If the offsets by account option is enabled within the parameter USE_FLEXIBLE_OFFSET_IND, the KFS goes through
a special process in e-docs and in 'Scrubber' during G/L processing to determine the account that the offsets should be
made to for a given transaction.
For more information about flexible offsets by account, see Offset Account in the Guide to the
KFS Maintenance Menu.
When the flexible offsets function is enabled, generation of offsets on e-docs occurs as follows:
1 The offset object code is defined in the Offset Definition table.
2 The object code and account number are searched from the Offset Account table.
3 If a match is found in the Offset Account table, the offset is made in the offset account
defined there.
4 If no match is found, the offset is made in the same account on which the original transaction
occurred.
Generation of offsets in 'Scrubber' when the flexible offsets function is enabled occurs as follows:
1 'Scrubber' looks up the document type for a transaction in the Document Type table.
2 'Scrubber' checks the document type of the entry against the document types defined in the
parameter.
 OFFSET_GENERATION_DOCUMENT_TYPES: If the document type is found

in this parameter, 'Scrubber' does not generate offsets for this entry. This ensures
that document types that should not generate offset entries (like journal voucher)
do not have offsets generated during 'Scrubber' processing.
 DOCUMENT_TYPES_REQUIRING_FLEXIBLE_OFFSET_BALANCING_EN
TRIES: If the document type is found in this parameter, 'Scrubber' generates
offsets even if the document type appears to be balanced. This allows 'Scrubber' to
generate the proper flexible offsets for transactions that originate outside of KFS.
3 If you are using flexible offsets (parameter USE_FLEXIBLE_OFFSET_IND is set to 'Y'),

'Scrubber' checks the document type against those found in the parameter.
4 If 'Scrubber' determines in the previous steps that an offset is to be generated, it determines

the transaction's offset object code using the Offset Definition table.
5 If you are using flexible offsets (parameter USE_FLEXIBLE_OFFSET_IND is set to 'Y'),

'Scrubber' searches for the object code and account number in the Offset Account table.
6 If a match is found in the Offset Account table, the offset is made in the offset account
defined there. If no match is found, the offset is made in the same account on which the
original transaction occurred.

Year-End Processes
Four year-end processes allow users to properly 'close' a fiscal year:
 Closing of pre-encumbrances, except for those relating to accounts that are in the Contracts and Grants (CG)
fund group, and carry forward internal and external encumbrances into the new fiscal year.
 Computing reversions and carry forwards.
 Closing of nominal (actual) activity to net expenses, net revenue, and fund balance.
 Establishing beginning balances for CG accounts that had activity in the fiscal year being closed.
These processes generate pending ledger entries which are then fed to the G/L batch cycle. These year-end processes are
run in sequence over the course of three cycles. Subsequent cycles depend on the successful completion of the preceding
cycles.
Figure 176 - Year-End Cycles

Closing Encumbrances
This process closes and carries forward pre-encumbrances and internal and external encumbrances into the new fiscal
year. The process also carries forward pre-encumbrances for Contracts and Grants accounts. It examines all G/L
encumbrance entries for the fiscal year being closed. These entries are summarized by chart code, account number, sub-
account number, object code, sub-object code, and balance type. Each combination is considered as a unit of work in the
application of the following business rules. The rules are divided into two categories—business rules associated with
closing encumbrances and business rules associated with cost share carry forward.
Business Rules for Closing Encumbrances

 Internal encumbrance, external encumbrance and pre-encumbrance balance types are eligible for close.
 Internal encumbrances for labor distributions balance type/origin code (as defined in the parameter
FORWARD_ENCUMBRANCE_BALANCE_TYPE_AND_ORIGIN_CODE) combinations are ineligible.
 Pre-encumbrances related to CG balance type/fund group combinations are eligible to be carried forward into
the new fiscal year.
 Encumbrances that do not have a zero balance are eligible.
 The object code must be valid.
 If the unit of work qualifies for closing encumbrances, the encumbrance beginning balance entry and its
corresponding offset are created as G/L pending entries.
Business Rules for Cost Share Carry Forward Encumbrances

 Expenses related to CG fund groups are eligible to be carried forward into the new fiscal year.
 Internal encumbrance, external encumbrance, and pre-encumbrance balance types are eligible.
 Internal encumbrances for labor distribution balance type/origin code combinations are ineligible.
 Expense-related object types are eligible.
 Encumbrances that do not have a zero balance are eligible.
 Cost share sub-accounts are eligible.
If the unit of work qualifies for cost share carry forward of encumbrances, the cost share encumbrance beginning balance
entry and its corresponding offset are created as G/L pending entries.

Reversions and Carry Forwards
Reversions and carry forwards are computed at year-end to handle excess budgeted resources or deficits. The process is
governed by a set of rules (sometimes known as 'lapsing rules'). These rules may be self-imposed or mandated by an
outside funding source such as the state, federal government, or a sponsoring agency. This process is intended to
encourage good fiscal practices. The process is comprised of three primary actions:
 Budget Reversion: A pair of pending ledger entries is generated for the year being closed. One entry adjusts the
budget in the actual account. The other adjusts the budget in a budget reversion account.
 Budget Carry Forward: At least one pair of pending ledger entries is generated for the next fiscal year. For each
pair the accounts remain unchanged. However, one uses the beginning budget cash object code, and the other
uses the carry-forward object code (if carrying forward by object code) or the unallocated object code (when
consolidating carrying forward transactions).
 Cash Reversion: Two pairs of pending ledger entries are generated for the next fiscal year. One moves the cash
out of the actual account and into a cash reversion account. The other moves the corresponding fund balance out
of the actual account and into a cash reversion account.
The reversion/carry forward rules are defined in the organization reversion function via two standard documents called
the Organization Reversion (ORGR) document and the Organization Reversion Category (ORGC) document.
For information about these documents, see Organization Reversion and Organization Reversion
Category in the Guide to the KFS Maintenance Menu.
Carry Forward and Reversion Example

At the fiscal year-end, the Ichthyology Department (Org Code ICH) has an account 1234567 in chart BL. The cash
object code in the account's Chart of Accounts is 8000. The Organization Reversion table for the department specifies
that its
 budget reversion account is 1023295.
 cash reversion account is 1023299.
Reversion codes (Rules) and carry forward object codes are shown in the carry forward and reversion actions
summarized in the following table.
Table 47 Carry forward/reversion actions (example)
Category Object Rule Budget Actual Budget Encumb-

Code Amt Amt Balanc rances
e
Org Wages 3000 N2 6000 5000 1000 100
Action: Encumbrance not covered; 1000 reverted to

1023295
Salary /Fringes 2004 R2 20000 18000 2000 200

Action: Encumbrance not covered; 2000 reverted to
1023295
Financial Aid 5800 N1 3000 4000 -1000 500
Action: Encumbrance not covered (- budget balance); -1000

carried forward to 1234567
Capital Equipment 7000 N1 1000 800 200 300
Action: 200 carried forward to 1234567 to cover part of

encumbrance
Reserve 7900 N1 1000 500 500 400
Action: 400 carried forward to 1234567 to cover

encumbrance; 100 reverted to 1023295 for + balance
Transfer Out 5199 R2 500 500 0 200
Action: Encumbrance not covered; nothing reverted; nothing

carried forward
Transfer In 1699 R2 300 500 200 300

(income)
Action: Encumbrance not covered; 200 reverted to 1023295
Travel 6000 N1 1000 900 100 100

encumbrance; nothing else remains to revert or carry
forward
Other Expense 5000 N1 500 500 0 200
Action: Encumbrance not covered (0 budget balance);

nothing reverted; nothing carried forward.
Assess Expend 7900 C1 400 250 150 100

encumbrance; 50 carried forward to 1234567 from +
balance; nothing reverted
Revenue (income) 1800 N2 1200 1000 -200 800

Action: Encumbrance not covered (- budget balance); -200
carried forward to 1234567
Cash 8000 n/a 10000 4000 6000 n/a
Action: 6000 reverted to 1023299
Note that the object code for each category is used only if the Carry Forward by Object Code attribute of the
Organization Reversion table is set to 'Yes.' The Transactions Generated table (see below) illustrates both sets of results
—one set when the Carry Forward by Object Code Indicator is 'Yes' and another set when it is 'No').
Table 48 Transactions generated (example)
Transaction Account CF by Account Object Amount DrCr

Obj/ Code
Category
Budget Actual Any 1234567 7900 -3300

Reversion
Budget Reversio Any 1023295 7900 3300

Reversion n
Budget Carry Actual No 1234567 0110 -350

Forward Consoli-
dated
Budget Carry Actual No 1234567 7900 -350

Forward Consoli-
dated
Budget Carry Actual Yes 1234567 0110 -1000

Forward
Fin Aid

Forward
Fin Aid
Budget Carry Actual Yes 1234567 0110 200

Forward
Cap
Equip

Forward
Cap
Equip

Forward
Reserve

Forward
Reserve

Forward
Travel

Forward
Travel

Forward
Assess
Expend

Forward
Assess
Expend

Forward
Revenue

Forward
Revenue
Cash Actual Yes 1234567 8000 6000 Cr

Reversion
Cash Reversio Yes 1023299 8000 6000 Dr

Reversion n
Fund Actual Yes 1234567 9899 6000 Dr

Balance
Reversion
Fund Reversio Yes 1023299 9899 6000 Cr

Balance n
Reversion
For information about how to setup organization reversion tables, see Chart of Accounts in the Guide
to the KFS Maintenance Menu.

The year-end program's run-time parameters are:
 unallocated object code 7900
 beginning budget cash object code 0110
 fund balance object code 9899

Closing Nominal Activity
The close nominal activity process:
 aggregates the revenues earned and expenses incurred during the year and calculates the difference,
 posts the resultant deficit or surplus to the institution's net assets, and
 resets the revenue and expense buckets to zero for the new fiscal year.
All G/L balance entries for the fiscal year being closed are examined. These entries can be summarized by Chart of
Accounts code, account number, sub-account number, object code, sub-object code, balance type, and object type. Each
combination is considered as a unit of work in the application of the following business rules.
Business Rules
 Actual expenses and actual revenues balance types are eligible for close.
 Those representing expense and revenue object types are eligible for close.
 The annual balances that do not have a zero balance are eligible.
 If the unit of work qualifies for closing nominal activity, create a pending close nominal activity entry in an
object code defined in the NET_EXPENSE_OBJECT_CODE or NET_INCOME_OBJECT_CODE parameters.
An entry is also made to the corresponding fund balance offset.

Beginning Balances
The beginning balances process uses the ending balance from the previous fiscal year to establish beginning balances for
the new fiscal year. The beginning balances process creates an entry to establish the beginning balance for balance sheet
objects (assets, liabilities, fund balance) and to move net income/net expense balances to net assets (fund balance).
The beginning balances process also establishes cumulative beginning balances for each revenue and expense object
code, using the ending balance from the previous fiscal year as the beginning balance of the new fiscal year.
These cumulative balances are erroneously called 'Contract & Grant Beginning Balances' in
the G/L Balance table because those balances were all that was originally accounted for in
that field.
All G/L balance entries for the fiscal year being closed are examined. These entries can be summarized by Chart of
Accounts code, account number, sub-account number, object code, sub-object code, balance type, and object type. Each
combination is considered as a unit of work in the application of the following business rules.
Business Rules
For establishing beginning balances:
 From a pre-established list of balance types, actual and close nominal balances are eligible for beginning
balances. The balance types are defined in the parameter
BALANCE_TYPES_TO_ROLL_FORWARD_FOR_BALANCE_SHEET.
 Object types representing assets, liabilities, and fund balance defined in the Systems Options table are eligible
for beginning balances.
 The annual balance amount plus the Contracts and Grants balance amount plus the beginning balance amount
that is not zero are eligible. (Annual Balance + CG Balance Amount + Beginning Balance <> 0)
 If the unit of work qualifies for establishing beginning balances, a beginning balance entry is created as a G/L
pending entry.
For establishing cumulative balances:
 From a pre-established list of balance types, actual and current budget balances are eligible for cumulative
beginning balances. The balance types are defined in the parameter
BALANCE_TYPES_TO_ROLL_FORWARD_FOR_INCOME_EXPENSE?
 From a pre-established list of object types, those representing expense and revenue are eligible for cumulative
beginning balances.
 From a pre-established list of fund groups or sub-fund groups, balances related to CG accounts are eligible to be
carried forward into the new fiscal year.
Institutions have the option to set CG as a fund group or sub-fund group using the
FUND_GROUP_DENOTES_CG_IND parameter.
 The annual balance amount plus the Contracts and Grants balance amount that is not zero are eligible.
 If the unit of work qualifies for establishing cumulative balances, a cumulative beginning balance entry is
created as the G/L pending entry.

Batch Assurance Reports
As discussed in the previous sections, a number of text reports are generated by each step of the batch programs to give
you assurance that the transactions are processed in order. Each of the generated text reports is suffixed by the date and
time of run. The following table summarizes the batch assurance reports generated by the batch process:
Table 49 Batch assurance reports

No Report Title Text Report Name Description
1 GLPE Statistics glpe_ledger Summary total and record count

Report of approved General Ledger
(Figure 145) pending entries fed by balance
type, origin code, fiscal year and
period. Created by the
nightlyOutJob.
2 PENDING glpe_list Detailed listing of approved

LEDGER ENTRY General Ledger pending entries
TABLE fed. Created by the
(Figure 146) nightlyOutJob.
3 Scrubber Report scrubber Summary total number of

STATISTICS records scrubbed and automated
(Figure 151) entries generated (offset,
capitalization, liabilities, plant
indebtedness, and cost share).
Errors detected by the scrubber
are also listed in detail. Created
by the scrubberJob.
4 Ledger Report scrubber_ ledger Summary listing of transactions

(Figure 152) scrubbed, including GLPE and
external batch feed files by
balance type, origin code, fiscal
year and period. Created by the
scrubberJob.
5 Scrubber Input scrubber_ badbal Detailed listing of transactions

Transactions with with bad or blank balance types.
Bad Balance Type The scrubber replaces these
(Figure 153) with a balance type of AC.
Created by the scrubberJob.
6 Error Listing - scrubber_ errors Detailed listing of transactions

Transactions removed from 'Scrubber'
Remove From the including transactions pulled by
Scrubber (Figure 154) the 'Demerger' process. Also
includes subtotals for error
entries. Created by the
scrubberJob.

7 Demerger Report demerger Total number of valid and invalid
STATISTICS transactions and scrubber-
(Figure 156) generated entries (offset,
capitalization, plant
indebtedness, cost share)
bypassed. Created by the
scrubberJob.
8 Poster Report (post poster_main Total record count of rows

pending entries) deleted, inserted, and updated
STATISTICS from in the G/L tables updated
(Figure 160) by the poster. Created by the
PosterJob.
9 Main Poster Input poster_ Summary total and record count

Transactions main_ledger of transactions posted fed by
(Figure 161) balance type, origin code, fiscal
year and period. Created by the
PosterJob.
10 Main Poster Error poster_main_ Detailed listing of the error

Transaction Listing error_list transactions along with a
(Figure 160) summary total and record count
for transactions not posted.
Created by the PosterJob.
11 Poster Report (Post poster_ reversal Summary total and record count
reversal entries) of rows selected, deleted,
STATISTICS inserted, and updated in the G/L
(Figure 166) tables by the reversal poster.
12 Reversal Poster poster_reversal_list Detailed list of transactions

Transaction Listing generated by the reversal poster
(Figure 167) along with a summary total and
record count. Created by the
PosterJob.
13 Reversal Poster poster_ reversal_ Summary total and record count

Input Transactions ledger of transactions that generated
(Figure 168) reversals by balance type, origin
code, fiscal year and period.
14 Reversal Poster poster_ reversal_ Detailed listing of error reversal

Error Transaction error_list transactions along with a
Listing summary and record count for
(Figure 169) transactions not posted. Created
by the PosterJob.
15 ICR Generation icr_ generation Summary total and record count

Report of rows selected, deleted, and
STATISTICS (Figure kept from the G/L Expenditure
172) Transaction table and the record
count of ICR transactions

generated. Created by the
PosterJob.
16 Poster Report (Post poster_icr Total record count of rows

ICR entries) deleted, inserted, and updated in
STATISTICS the G/L tables by the ICR poster.
(Figure 170) Created by the PosterJob.
17 ICR Poster Input poster_icr_ ledger Summary total and record count
Transactions (Figure of ICR transactions generated by
171) the ICR poster by balance type,
origin code, fiscal year and
period. Created by the
PosterJob.
18 ICR Poster Error poster_icr_ error Detailed listing of ICR error

Transaction Listing transactions along with a
(Figure 173) summary and record count for
transactions not posted. Created
by the PosterJob.
19 Sufficient Funds sufficient_funds Detailed listing of sufficient funds

Rebuilder Report errors (if any) and a summary of
Statistics (Figure 159) records read, deleted, converted
or retained due to errors by the
sufficient funds rebuilder
process. Also records the
number of entries added, deleted
and updated in the sufficient
funds table. Total and record
count of Sufficient Balance Table
rows selected, deleted, updated,
and inserted. Created by the
sufficientFundsJob.
20 GL Summary for gl_summary_bud Beginning, annual, monthly and

Fiscal Year, accumulated balances by fund
Balance Type of group for budget balance types.
CB/BB/MB (Figure Created by the
164) posterSummaryReportJob.
21 GL Summary for gl_summary_act Beginning, annual, monthly and

Fiscal Year, accumulated balances by fund
Balance Type of group for the AC balance type.
AC Created by the
(Figure 163) posterSummaryReportJob.
22 GL Summary for gl_summary_enc YTD Balance by fund group for

Fiscal Year, the encumbrance balance types.
Balance Type of Created by the
EX/IE/PE/CE (Figure posterSummaryReportJob.
165)
23 Poster Output poster_ output_ Summary debit, credit, budget,

Summary and net amount total by balance

(Figure 174) summary type, fiscal year, period code and
fund group. Created by the
posterSummaryReportJob.
24 Collector Reports collector Summary of all files processed

(Figure 144) by the collector, a list of all errors
from collector transactions,
statistics for records read and in
error, and an input summary of
all valid transactions by balance
type, origin code, fiscal year and
period code. Created by the
CollectorJob.
The delivery mechanism of these reports depends on the implementing institution.

General Ledger Automated Balancing
KFS General Ledger reports can be used to manually verify balance and entry totals processed through the nightly batch
cycle. An automated balancing function simplifies this process and does much of the verification automatically. The
process builds a series of entry and balance tables that are synched with your General Ledger as they are created.
Thereafter, the process uses these history tables, adding transactions from each nightly batch cycle. It compares the
calculated table amounts and row counts back to your General Ledger counts and balances. Discrepancies are reported
along with summary statistics for row counts and errors.
The automated balancing report is generated by the posterBalancingJob, which may be run as part of your institution's
nightly batch cycle. The report it generates is called 'balancing' and is available in the GL Reports directory.
The first time the automated balancing process is initiated, it populates entry and balance history tables. A message
indicating to this effect is displayed at the top of the report.
Figure 177 - A message indicates that the Balance History & Entry History tables were populated.
During the first run, the process builds the history tables that future runs of the process will use. From then on, each time
the process generates the history tables, it includes entries from the most recent batch cycle.
Each run of the report generates statistics indicating the fiscal years included in the balancing along with summarized
counts for each table verified and any comparison failures detected.
Figure 178 - G/L Automated Balancing Statistics

Entries associated with other fiscal years will not be maintained in the history tables and will not
be compared to the General Ledger tables.
All fields displayed in the statistics are detailed in the table below.
Table 50 General Ledger Balancing Report Statistics fields

Statistic Label Description
FISCAL YEARS Specifies the years included in the automated comparisons.

INCLUDED IN The KFS-GL
BALANCING NUMBER_OF_PAST_FISCAL_YEARS_TO_INCLUDE
parameter controls the number of past fiscal years included.
HISTORY For the first run of the posterBalancingJob, the value is 'Yes,'
TABLES which indicates that the history tables required for future runs
INITIALIZED— of the automated balancing report have been populated.
UPDATES During subsequent balancing (after the tables have been
SKIPPED initialized), this value is 'No.'
OBSOLETE If a given fiscal year in the history tables is no longer within the
HISTORY range of years to be included in balancing, this entry indicates
DELETED the fiscal years that have been removed. If no fiscal years
were removed, the value is 'No.'
UPDATES If the most recent G/L nightly batch cycle included entries for
SKIPPED DUE fiscal years that are not within the range of years to be
TO OUT OF included in balancing, this field indicates how many updates to
RANGE FISCAL the balancing tables were skipped due to out-of-range fiscal
YEAR year entries.
GLEN AMOUNT The number of entries in the General Ledger Entry table that
FAILURES failed to match those in the entry history table.
(EntryHistory)
GLBL AMOUNT The number of entries in the General Ledger Balance table
FAILURES that failed to match those in the balance history table.
(BalanceHistory)
GLEN SUM The calculated row count from the Entry History table. This
(ROW COUNT) - number equals the number of entries in the history table prior
CALC. to the last batch cycle plus the number of entries from that last
(EntryHistory) cycle.
GLEN ROW The number of rows in the General Ledger Entry table. This
COUNT - PROD. value should match the GLEN SUM CALC row count from the
History table.
GLBL ROW The calculated row count from the Balance History table. This
COUNT - CALC. value equals the number of previous History table balance
(BalanceHistory) entries plus the number from the most recent batch cycle.
GLBL ROW The number of rows in the General Ledger Balance table. This
COUNT - PROD. number should match the GLBL ROW COUNT calculated from
the history tables.
ACBL AMOUNT The number of rows in the Production Account Balance table
FAILURES with balance amounts that fail to match to those in the Account
(AccountBalance Balance History table.

History)
GLEC AMOUNT The number of rows in the Production General Ledger
FAILURES Encumbrance table with amounts that fail to match to those in
(EncumbranceHis the Encumbrance History table.
tory)
ACBL ROW The calculated row count from the Account Balance History
COUNT - CALC. table. This number equals the number of Previous History
(AccountBalance table account balance entries plus those from the most recent
History) batch cycle.
ACBL ROW The row count from the Production Account Balance table.
COUNT - PROD. This should match the ACBL ROW COUNT calculated from
the History table.
GLEC ROW The calculated row count from the Encumbrance History table.
COUNT - CALC. This number equals the number of the previous Encumbrance
(EncumbranceHis History table entries plus the number from the most recent
tory) batch cycle.
GLEC ROW The row count from the Production Encumbrance table. This
COUNT - PROD. should match the GLEC ROW COUNT calculated from the
History table.
Errors encountered by the automated balancing process are displayed before the statistics. An error section is displayed
for each history table that failed to balance. Detail is displayed for each error, up to the configurable maximum number
of errors for the report.
The KFS-GL NUMBER_OF_COMPARISON_FAILURES_TO_PRINT_PER_REPORT

parameter controls the number of detailed comparison failures that can be printed. Your report
always includes the total number of errors, but details are shown only up to the number of errors
specified in this parameter.
Figure 179 - Balancing failures are reported for each history table.
Errors in the balancing should prompt you to investigate the other General Ledger batch reports to determine where the
problem(s) might lie. After errors are corrected, synchronize the history table with your General Ledger. The
posterBalancingHistorySyncJob can be run to re-synchronize the history tables to your General Ledger.

G/L Correction Process (GLCP)
The General Ledger Correction Process (GLCP) document is used by central administration to correct errors that occur
during General Ledger processing. The GLCP document allows users to correct errors in several different ways.
For more information about the GLCP document see General Ledger Correction Process in the
Guide to the KFS Main Menu.

Accounting Cycle Files
The G/L Correction Process (GLCP) document allows functional users to view accounting cycle files in the Origin Entry
Group list.
Figure 180 - Origin Entry Group list in the GLCP
The following table describes these files based on the file names displayed in the Origin Entry Group list.
Table 51 Accounting cycle file descriptions

File Name Description
Year-end entries to populate asset, liability, fund

balance, and inception-to-date balances for the
new fiscal year. Includes open and expired
balance_forwards accounts.
Year-end entries to populate asset, liability, fund

balance, and inception-to-date balances for the
balance_forwards_closed new fiscal year. Closed accounts only.
Year-end entries to close income and expense to

close_nominal_activity fund balance in the fiscal year ending.
Year-end entries to bring forward outstanding

encumbrance_forward encumbrances to the new fiscal year.
Expired and closed accounts identified during

expaccts data validation in 'Scrubber.'
Backup of all files from the Origin Entry directory

that will be fed into 'Scrubber' for processing.
Examples: Collector, Enterprise Feed, GLCP,
glbackup eDocs, PDP, etc.
Error correction and file uploads processed by the

General Ledger Correction Process for input into
glcp_output the accounting cycle.
Valid entries from the 'Collector' (which shares

glentry_coll
'Scrubber' validation and 'Demerger' logic).

Notification of entries with errors was sent back to
the submitting unit for re-processing.
Entries processed via the Enterprise Feed Upload

link in the KFS. Entries have not yet passed
glentry_entp 'Scrubber' validation.
Pending ledger entries from G/L eDocs. Created

glentry_kfs by the Nightly Out batch job.
Summarized labor entries passed to the G/L for

glentry_lab processing.
Entries from check and ACH disbursements,

cancels, and cancel-and-re-issues processed by
glentry_pdp the Pre-Disbursement Processor.
Errors found in the ICR Poster that did not update

icrerrs the ledgers.
All indirect cost recovery (ICR) entries generated

icrtrans from eligible posted transactions.
Pending ledger entries from Labor e-docs.

labentry_kfs Created by the Labor Nightly Out batch job.
Backup of all files from the Origin Entry directory

that will be fed into the Labor 'Scrubber' for
ldbackup processing.
Error correction and file uploads processed by the

Labor Ledger Correction Process for input into the
llcp_output accounting cycle.
Year-end entries to revert and carry forward

org_reversion_pre_closing, current budget and cash according to the
org_reversion_closing established reversion rules.
Errors found in the 'Main Poster' that did not

posterrs update the ledgers.
Error-only transactions identified by 'Scrubber'

scrberr1 (pre-'Demerger').
Error transactions identified by 'Scrubber' plus

valid transactions for the same document type,
origin code, and document number pulled by the
'Demerger.' These entries are not passed on to
the 'Main Poster.' This is the most common file
scrberr2 used for GLCP for error correction.
Valid-only entries from 'Scrubber'

scrbout1 (pre-'Demerger').
Valid entries from the 'Demerger' after pulling

entries for any documents with errors that will be
scrbout2 passed on to the 'Main Poster.'

sorticr Sorted icrtrans file for input into the ICR poster.
Sorted scrbout2 file for input into the 'Main

sortpost Poster.'
Sorted backup data used for validation in

sortscrb 'Scrubber.'
Errors found in the 'Reversal Poster' that did not

Workers update the ledgers.
All automated reversal entries selected for

Workfile processing by the 'Reversal Poster.'

B
Index balancing rules 74

basic e-doc operations 78
canceling 83
A closing 84
copying 80
account level routing (fiscal officer) 93 initiating 79
accounting cycle files 211 routing 85
accounting line import templates 124 saving 82
Accounting Line import templates searching 87
AD_CR_CCR_DV_SB_Import.xls 135 batch assurance reports 203
AV_Import.xls 136 beginning balances 202
BA_YEBA_Import.xls 137 Beginning Balances 208
CAM_MPAY_Account_Import.xls 152 blanket approving a document 108
DI_YEDI_IB_TF_PE_Encumbrance_Only_Import.xl budget carry forward 196
s 139 budget reversion 196
GEC_YEGEC_Import.xls 140 business rules
ICA_Import.xls 141 beginning balances 202
JV_Ext_Encumbr_Import.xls 142 closing encumbrances 195
JV_NonOffset_Bal_Type_Import.xls 143 closing nominal activity 201
JV_Offset_Bal_Type_Import.xls 144 cost share carry forward encumbrances 195
LLJV_Import.xls 146 ICR income and expense transactions 186
ND_Import.xls 148 offset generation 165
PE_Disencumbrance_Only_Import.xls 149 reversal poster 183
PURAP_Account_Import.xls 151 sufficient funds 177
PURAP_Item_Import.xls 150 validation 161
Accounting Lines tab 65
buttons 68
C
creating a .csv file 131
debit/credit entries 66 canceling a document 83
displaying account detail 67 Capital Asset Management (CAM) 37
double-sided entries 65 Capital Edit tab 71
Expired Override check box 68 Create New Assets section 72
fields, list of 66 Retrieve Asset to be Updated section 71
import lines 70 capitalization of assets and liabilities 165
restrictions 70 carry forwards 196
sales tax 69 cash reversion 196
single-sided entry 65 caveats about using documentation 13
Accounts Receivable (AR) 38 Chart of Accounts (COA) 27, 33
Acknowledge 86 Close button 47
acknowledging a document 109 closing a document 84
action list 106 closing encumbrances 195
Action List 86 closing nominal activity 201
action list,filtering the 113 collapse all button 51
Action Taken Tab 60 Collector 157
Actions Taken tab 102 commercial affiliate documentation and support
Ad Hoc Recipients tab 76 (user support) 12
ad hoc routing 94 continuation account for expired account 164
ad hoc routing recipient,adding a 94 contracts and grants 39
apply default 110 Copied from Document ID 80
approve 86 copying a document 80
architecture, KFS 28 copyright and licensing 17
asterisk 53 correction 164
AUTO FR 164 cost share encumbrances 167
AUTO-REVERSAL 183 cost share transfers 166
KFS v. 3.1 Overview Index · 221

creating a .csv file 131 flexible banking offsets 192
csv 58 flexible offset 191
cumulative balances 202 by account 193
Functional Councils 5
D Future Action Requests tab 103
future reversal update 175
data import templates 124 FYI 86, 109
data import templates,links to default 126
data validation 161
G
date fields 54
debit/credit entries 66 G/L
Decision Support 27, 31 batch process 155
De-Merge 171 overview 154
detailed vs. basic searches 115 G/L account balance posting 179
disapproving a document 108 G/L Account Balance Posting (“Main Poster”) 173
Document Body 49 G/L balance update 173
document header 50 G/L demerger process 171
Document Header 49 G/L encumbrance update 174
Document Overview tab 63 G/L posting
document search 115 account balances 179
documentation licensing 22 detail 180
documentation Wiki (user support) 12 poster report 180
document-specific searches 118 G/L Posting (“Poster”) 172
double-sided entries 65 G/L process
drilldown 59 Collector 157
document ID 59 initiation 156
G/L Transaction Filter (De-Merge) 171
E GASB 6
General Ledger (G/L) 27, 30, 153
e-doc fundamentals 48 General Ledger automated balancing 207
e-doc screen layout 49 General Ledger Correction Process (GLCP) 164, 210
e-docs 29 General Ledger G/L process 154
Effort Certification module 40 General Ledger Pending Entries tab 74
electronic documents 6 Generated Capitalization 166
encumbrances 195 Generated Liability 166
errors,correcting after approval 110 GLCP 164
Excel 58
expand all button 51
H
export option 58
exporting data 58 hide button 52
external systems 161
I
F
icons 55
FASB 6 icons and symbols, KFS user documentation 10
field lookup 55 ICR 172
Field Lookup 55 ICR Calculation and Posting (“ICR Poster”) 185
filter,action list 113 ICR encumbrances 188
final validation 173 ICR expense and income entries 185
financial transaction document tabs ICR transaction posting 188
Accounting Lines tab 65 import lines 70
Capital Edit tab 71 initiating a document 79
General Ledger Pending Entries tab 74
financial transaction documents K
balancing rules 74
Financial Transactions Processing 27 KEW 26, 89
KFS 27 open and closed encumbrance amounts 175
KFS user documentation, about the 7 organization and conventions, KFS user documentation
KNS 25 8
Kuali organization review (review hierarchy) routing 93
key components 24 Origin Entry Transactions 157
Kuali Commercial Affiliates (KCA) 4
Kuali Communities P
overview 2
Kuali Endowment Management (KEM) 3, 5 parameters
Kuali Enterprise Workflow (KEW) 26 SALES_TAX_APPLICABLE_ACCOUNTS_AND_
Kuali Enterprise Workflow (KEW), overview and key OBJECT_CODES 70
concepts 89 SALES_TAX_APPLICABLE_DOCUMENT_TYPE
Kuali Financial System (KFS) 3, 5, 27 S 70
Kuali Foundation (KF) 2, 4 PDF 203
Kuali Nervous System (KNS) 25 Pending Action Requests tab 102
Kuali Partners Program (KPP) 4 Pending Action Requests Tab 60
Kuali Research Administration (KRA) 3, 5 plant indebtedness 166
Kuali Rice (KR) 3, 5 Poster 172
Kuali Student (KS) 3, 5 Poster Output Summary 188
Kuali Technical Council (KTC) 5 poster report 180
Pre-Disbursement Processor (PDP) 36
pre-scrubber function 164
L
Project Boards 5
Labor Distribution module 41 Purchase Order (PO) encumbrance amounts 175
lapsing rules 196 Purchase Order (PO) encumbrances 175
licensing 17, 22 Purchasing and AP Module 35
links 55
log off 47 R
log on 47
lookup Requested Of 103
add multiple lines 56 required fields 53
field 55 Reversal Date 183
reversal poster 183
Reversal Poster 172
M
report 184
magnifying glass 55 reversions 196
Main Poster 172, 173 route levels 91
Message of the Day 45 route levels, typical 93
modules 24 Route Log 60
modules, KFS 32 Route Log tab 100
multiple value lookup 56 Route Log tab 77
route nodes 91
N route nodes,viewing 97
route status 105
named search 119 Routing a Document 85
Navigating through the KFS 42 routing details,viewing 104
navigation 46 routing, special condition 93
nominal activities 201 routing,account level (fiscal officer) 93
Notes and Attachments tab 75 routing,account level (review hierarchy) 93
routing,ad hoc 94
O routing,workflow 91
Offset Definition 193

Offset Definition Table 74
S
offset generation 164 sales tax 69
online collaboration (user support) 12
KFS v. 3.1 Overview Index · 223

SALES_TAX_APPLICABLE_ACCOUNTS_AND_O Workflow responsibilities 99
BJECT_CODES parameter 70 workflow routing 91
SALES_TAX_APPLICABLE_DOCUMENT_TYPES
parameter 70 X
saving a document 82
screen elements, KFS 43 XML 58, 157
Scrubber 161
search 115 Y
search,named 119
searches year-end processes 194
detailed vs. basic seaches 115
document-specific searches 118
saving 119
superuser vs. non-superuser searches 117
searching for a document 87
select all button 57
show button 52
single-sided entry 65
special condition routing 93
standard data entry, selection, action, and navigation
tools 46
standard links and icons 55
standard tabs 62
Sufficient Funds 189
balance update 176
rebuild 176
superuser functions 119
superuser vs. non-superuser searches 117
T
templates,accounting line import 124
third party contributions 20
transaction generation 165
transaction validation
reports 167
Transaction Validation 161
Transfer to Net Plant 166
typographic conventions, KFS user documentation 11
U
unselect all button 57
user support information 12
V
validation 161
Vendor 34
W
wildcards 55, 88
Workflow 89
Workflow action buttons 107
workflow preferences,setting 111

KFS Overview Master

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KFS Overview Master

Uploaded by

Copyright:

Available Formats

Kuali Financial System

KFS v. 3.1 Overview Contents · v

vi · Contents KFS v. 3.1 Overview

KFS v. 3.1 Overview Introduction · 1

Figure 1 - Kuali communities overview

Table 1 Kuali communities overview

Community Name Personnel Functions

Kuali Kuali Board of Collaboration infrastructure, copyright holding,

2 · Kuali Communities Overview KFS v. 3.1 Overview

Research Kuali Project Board, Proposal development, budget development,

Endowment Kuali Project Board, Investment tracking & reporting, investment

KFS v. 3.1 Overview Kuali Communities Overview · 3

4 · Kuali Communities Overview KFS v. 3.1 Overview

KFS v. 3.1 Overview Kuali Communities Overview · 5

 ª6PÁÀöIAæ@P¶€ã566 Institute Proposal / Negotiations, Report Tracking, Subcontracts, Cost Share

6 · Kuali Communities Overview KFS v. 3.1 Overview

KFS v. 3.1 Overview Kuali Communities Overview · 7

8 · Kuali Communities Overview KFS v. 3.1 Overview

KFS v. 3.1 Overview Kuali Communities Overview · 9

10 · Kuali Communities Overview KFS v. 3.1 Overview

Organization and Conventions 8

User Support Information 12

Caveats about Using this Documentation 13

Copyright and Licensing 17

KFS v. 3.1 Overview About the KFS User Documentation · 11

 Basic screen navigation

 Using the software to accomplish tasks

 Electronic document and workflow routing

12 · About the KFS User Documentation KFS v. 3.1 Overview

Figure 2 - KFS user documentation topic information architecture

KFS v. 3.1 Overview About the KFS User Documentation · 13

Table 3 Purpose of icons in KFS documentation

14 · About the KFS User Documentation KFS v. 3.1 Overview

KFS v. 3.1 Overview About the KFS User Documentation · 15

Online Collaboration (Community Documentation 'Remixing' and Sharing): https://collab.kuali.org/xsl-portal.

Commercial Affiliate Documentation & Support: http://www.kuali.org/support/. Commercial affiliate community

To contact the Kuali Foundation, see http://www.kuali.org/contact.

16 · About the KFS User Documentation KFS v. 3.1 Overview

KFS v. 3.1 Overview About the KFS User Documentation · 17

18 · About the KFS User Documentation KFS v. 3.1 Overview

KFS v. 3.1 Overview About the KFS User Documentation · 19

20 · About the KFS User Documentation KFS v. 3.1 Overview

Kuali ® is a registered trademark  of the Trustees of Indiana University.

KFS v. 3.1 Overview About the KFS User Documentation · 21

22 · About the KFS User Documentation KFS v. 3.1 Overview

KFS v. 3.1 Overview About the KFS User Documentation · 23

Refer to: https://test.kuali.org/confluence/display/KULFOUND/3rd+Party+Licenses for the most detailed, up-to-date

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 SAXPath Project (http://www.saxpath.org/).

This product includes software developed by the Working-Dogs.com (http://www.Working-Dogs.com/).

This product includes software licensed under Common Public License

24 · About the KFS User Documentation KFS v. 3.1 Overview

KFS v. 3.1 Overview About the KFS User Documentation · 25

Creative Commons License Deed

Attribution-Share Alike 3.0 United States

You are free:

to Remix - to make derivative works

Under the following conditions:

26 · About the KFS User Documentation KFS v. 3.1 Overview

KFS v. 3.1 Overview About the KFS User Documentation · 27

Kuali Nervous System (KNS) 25

Kuali Enterprise Workflow (KEW) 26

Kuali Financial System (KFS) 27