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
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.
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.
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
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)
Student Kuali Student Functional Person, time, learning unit, learning result, learning
Community (KS) Steering plan, learning resources, concierge
Committee,
Technical
Steering
Committee
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.
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'è
ª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ÁÀ
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.
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
Action options
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.
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.
Caution/Warning/Error
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.
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.
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.
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).
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 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 licensed under GNU Lesser General Public License
(http://www.opensource.org/licenses/lgpl-license.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) 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.
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.
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.
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
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.
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).
TOPICS
E-Docs 29
General Ledger 30
Decision Support 31
Anyone who initiates, reviews or approves financial transactions may be a user of an e-doc, including:
Administrators
TOPICS
Chart of Accounts 33
Vendor 34
Effort Certification 40
Labor Distribution 41
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.
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.
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.
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.
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.
TOPICS
Screen Elements 43
Message of the Day...................................................................................................................45
Standard Data Entry, Selection, Action, and Navigation Tools................................................46
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.
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.
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.
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.
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.
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).
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.
TOPICS
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
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.
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.
Figure 10 - The show and hide buttons on each e-doc tab allow you to expand or collapse the tab.
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.
1 Fill in one or more search criteria or all the search criteria fields blank to retrieve all.
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
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.
(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.
Click unselect all to clear the check boxes for all values in the list.
Clicking the cancel button returns you to the tab you came from without populating the
tab.
1 Click the export option link for the format you want.
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.
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.
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.
ª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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Figure 32 - Clicking hide detail hides the COA titles in the Accounting Lines tab.
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.
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.
The system does not display the sales tax line until you enter the account and object
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.
Object Code Object Type, Object Sub-Type, Object Level, Consolidated Object
Code
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:
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.
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.
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.
Tag Number Optional. Enter the unique identification number issued by the
university and affixed 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.
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.
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.
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.
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.
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.
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.
Action Requested Required. Select the desired action from the Action
Requested list. The choices are APPROVE,
ACKNOWLEDGE, and FYI.
Figure 46 - The Route Log tab displays the workflow status and actions taken.
For more information about the Route Log, see Route Log.
For information about the requirements for a particular type of e-doc, see the help
documentation for the specific document type.
For information about how to retrieve a document, see Using Doc Search to Find a
Document.
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.
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.
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.
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 50 - The KFS message 'Document was successfully saved' confirms that the document was saved.
For information about how to retrieve an e-doc, see Using Doc Search to Find a Document.
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.
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.
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 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.
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.
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.
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.
TOPICS
KEW Overview 90
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.
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.
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
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.
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.
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.
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.
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.'
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.
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.
For example, you might scroll down to Transfer of Funds to view the rules of the Transfer of Funds document route
levels.
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.
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.
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.
Each responsibility includes several attributes (that is, values and details) that determine when it is triggered.
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.
Type The document type. The full name of the transaction used to
identify this document type in Workflow.
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
Finalized The time and date that the document reached' Final,'
'Canceled,' or 'Disapproved' status.
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.
Figure 75 - Drill down into the workflow action requestor information by clicking show.
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.
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.
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.
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.
The following table summarizes the meaning of various route statuses in the KEW.
Committed The document has been committed to the database. See note
below.
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.
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.
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.
Special attention should be paid when you select any of the workflow action buttons noted below.
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.
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.
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.
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.
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.
2 Click submit.
The header of the corrected document shows the 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 95 - Preferences allows you to change the display of your action list.
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
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
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.
1 To go to the Action List Filter dialog box, click the Filter button.
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 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.
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.
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.
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
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.
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.
From the superuser view, you may take various actions that are allowed only for the superuser.
The following describes the actions that can be taken by the superuser.
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.
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
TOPICS
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
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).
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.
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).
Required field headings are marked with an asterisk and appear in red.
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.
9 Click Browse and locate the file you have created from your computer.
10 From the Choose File window, select the .csv file to be imported and click Open.
11 Click add.
1 Open the saved Excel workbook with the data from Step 5 above.
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*
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 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.
Budget Adjustment
A Chart Code*
B Account Number*
C Sub-Account Number
D Object Code*
E Sub-Object Code
F Project Code
G Organization Reference Id
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 Amount*
A Chart Code*
B Account Number*
C Sub-Account Number
D Object Code*
E Sub-Object Code
F Project Code
G Organization Reference Id
I Reference Number*
J Line Description
K Amount*
A Chart Code*
B Account Number*
C Sub-Account Number
D Sub-Object Code
E Project Code
F Organization Reference Id
G Amount*
A Journal Voucher has three different accounting line formats, depending on its Balance Type. You
must choose the Balance Type before importing.
A Chart Code*
B Account Number*
C Sub-Account Number
D Object Code*
F Sub-Object Code
G Project Code
H Organization Reference Id
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.
A Journal Voucher has three different accounting line formats, depending on its balance type. You
must choose the balance type before importing.
BS - Budget Statistics
CB - Current Budget
JB - July 1 Budget
MB - Monthly Budget
A Chart Code*
B Account Number*
C Sub-Account Number
D Object Code*
F Sub-Object Code
G Project Code
H Organization Reference Id
I Amount*
A Journal Voucher has three different accounting line formats, depending on its balance type.
You must choose the balance type before importing.
PE - Pre-Encumbrance
TR - Transfers
A Chart Code*
B Account Number*
C Sub-Account Number
D Object Code*
F Sub-Object Code
G Project Code
H Organization Reference Id
I Debit*
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.
A Chart Code*
B Account Number*
C Sub-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
O Grade
P Run ID
Q Period End
S Pay Period*
T Pay Hours
U Original Chart
V Original Account
W Original Sub-Account
Z Company
AA Set ID
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 Reference Number*
I Line Description
J Amount*
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 Reference Number*
I Amount*
A Quantity
B UOM*
C Catalog Number
D Commodity Code
E Description*
F Cost*
A Chart*
B Account*
C Sub-Account
D Object Code*
E Sub-Object Code
F Project
G Org Ref ID
H %*
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*
TOPICS
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.
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
o Validation
o Offset Generation
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.
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
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.
Origin Entry
KFS Labor Scrubber
Directory
External
Enterprise
Systems
Feed Directory
(Non-KFS)
XML or Flat
File “Collector”
Transactions
The following summary and detail reports are generated when the G/L pending entries are collected:
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.
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.
1 Origin code must exist in the Origin ORIGIN CODE NOT IN THE ORIGIN
Code table. TABLE
3 Chart code must exist in the Chart CHART CODE NOT IN THE CHART
table. TABLE
9 Object code must exist in the Object OBJECT CODE IS NOT IN THE
Code table. OBJECT CODE 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
21 Transaction date must exist in the In this case the invalid date will be
University Date table. replaced with the current date.
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.
For information on the G/L Correction Process (GLCP) document, see G/L Correction Process
(GLCP).
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:
If otherwise eligible and offset generation attribute for the balance type of the pending entry is 'Y.'
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
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_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 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.
be associated with an expense object code type (defined in the COST_SHARE_OBJECT_TYPES parameter)
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.
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:
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.
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.
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.
Reversal Poster
ICR Poster
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:
1 Chart code must exist in the Chart ORIGIN CODE NOT IN THE ORIGIN
table. 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
AB Y Y +
AB Y N -
BB Y Y +
BB Y N -
Cumulative CB N n/a +
Beginning Balance
CB Y Y +
CB Y N -
01 through Y N -
13
Transaction encumbrance update code must be 'D' (document) or 'R' (reference document), and
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.
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.
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.
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
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
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.
'A' Account
'N' No Checking
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
C - (Subtract)
Balance type indicates encumbrance and object type does not indicate fund balance
Null/blank N + (Add)
Other - (Subtract)
Null/blank N + (Add)
Other - (Subtract)
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.
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.
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.
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.
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.
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.)
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.'
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 = Cash Balance - Liabilities - Encumbrances +/- Pending Ledger Entries
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.
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
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:
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.
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:
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.
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.
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.
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.
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.
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.
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.
Internal encumbrance, external encumbrance, and pre-encumbrance balance types are eligible.
Internal encumbrances for labor distribution balance type/origin code combinations are ineligible.
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.
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.
Reversion codes (Rules) and carry forward object codes are shown in the carry forward and reversion actions
summarized in the following table.
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').
For information about how to setup organization reversion tables, see Chart of Accounts in the Guide
to the KFS Maintenance Menu.
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.
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.
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.
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.
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.
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.
All fields displayed in the statistics are detailed in the table below.
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.
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.
For more information about the GLCP document see General Ledger Correction Process in the
Guide to the KFS Main Menu.
The following table describes these files based on the file names displayed in the Origin Entry Group list.
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