Transcript Sample Screen

Kuali Financial Systems
Barry Walsh, Indiana University
April 10, 2006
Community Source Projects
“Community source describes a model for the
purposeful coordinating of work in a
community. It is based on many of the
principles of open source development efforts,
but community source efforts rely more
explicitly on defined roles, responsibilities, and
funded commitments by community members
than some open source development models.”
…. from www.sakaiproject.org
Community Source Projects
“Community source describes a model for the
purposeful coordinating of work in a
community. It is based on many of the
principles of open source development efforts,
but community source efforts rely more
explicitly on defined roles, responsibilities, and
funded commitments by community members
than some open source development models.”
…. from www.sakaiproject.org
http://Kuali.org.
• Kuali Financial Systems is a community/open
source initiative to create a comprehensive
financial information system for higher
education
• Designed for any Carnegie Class institution,
from Community College to R1 institutions
– Indiana University is 8 campuses
• 2 R1 campuses
• 6 smaller campuses
• Has had significant review by NACUBO
colleagues
What is it all about?
New
System
Design ?
Refactor
The
Technology
Indiana
Financial
System
Limited
Enhancements
Defined by
Functional
Council
Project Costs
• $7.4 m total project cost
• 72+ person-year effort
• Core partners:
– $500,000  $2,000,000,
• depending on Size and Carnegie Class
• >$4,400,000 from Founding Partners
– Cash or tendered personnel resources
• March, 2005: $2.5m grant from the Andrew W. Mellon
Foundation
Founding Partners
• Currently have Six
Institutional
Founding Partners
• NACUBO is also a
Founding Partner
• r*smart is a
Founding Partner
Governance
• Kuali Board
–
–
–
–
Voting member from each Institution
NACUBO and r-smart
Chair from Indiana
Extended Board
• Project Manager
– Developers from each Institution
• Functional Council
– Members from each Institution
– NACUBO and r-smart
– Subcommittees
Governance/cont’d
• Kuali Foundation
– Ongoing governance
• Kuali Partners Program
– Free? Membership ‘fee’ ?
– Commercial Affiliates
Proposed Kuali Scope
Phase I
Chart of Accounts
General Ledger
Accounting e-Docs
Disbursement Voucher
On-line balance inquiries
Routing and Approval
Basic reports
Phase II
Labor Distribution
Budget Construction
Contracts & Grants (pre and post award)
Capital Assets
Accounts Receivable
FDRS (Decision Support)*
Purchasing
Accounts Payable
Endowment
IU infrastructure elements that are also available:
OneStart Workflow© (XML)
Portal Framework*
IUIE (Decision Support)*
*Optional
What’s not Included?
• Applications where each institution will
have very specific policies and needs:
– Decision Support Environment
– Security Structure
– Cash Disbursement Configuration, i.e.
“Check writers”
Kuali Features
•
•
•
•
•
Modular Design
Scalability
Distributed Access
Flexible Chart of Accounts
Robust Workflow Engine
Modular Design
“External” feeds
Payroll
Students Receivable
Physical Plant
Library fines etc.
Kuali
‘Transaction Engine’
--Workflow; Portal
Chart of
Accounts
General
Ledger
Decision
Support
System and adhoc
Queries and Reports
E-Forms
•
•
Reports
Data
Modular Design
• Clean “handshakes” between
functions
• Can implement some or all of the
modules
– Capital assets module may be more than is
needed for schools with limited research
activity
– The Endowment module may be attractive
for schools running other financial systems
Scalability
• No limit to the number of
– Users
– Accounts
– Data values
– Transactions
– Custom Attributes
• Two of IU’s campuses are major
research institutions, others are similar
in size to a liberal arts college
Distributed Access
• Department personnel initiate transactions
from their desktop web browser – the
software is not installed on their machines
• Initiator receives immediate feedback on the
validity of the transaction – both valid data
and compliance with business rules
• Past transactions can be retrieved and
reversed or “templated”
• Transaction data can up uploaded from
spreadsheets
Benefits for a Controller/CFO
• Chart of Accounts is custom made for higher
education
– Function Codes
– Fund Groups
– Restriction status
• Includes functionality missing in many vended
packages:
–
–
–
–
Encumbrances
Carry forwards and reversions
Special attributes/functionality for programs and appropriations
Fiscal year to date and project year to date balances
• System is scaleable for the level of complexity
required by individual institutions
Benefits for Controller/CFO – (continued)
• Workflow allows for individual
school/department/campus set up for
approvals/fyi
• Business rule configuration allows for
enhanced internal controls
• Kuali product will include tools for
effective financial management
– Template of core financial policies
– Training Series module for fiscal officers
Questions?
Chart of Accounts
Bill Overman, Indiana University
What is the Chart of Accounts?
•CoA is the set of tables that define the
codes and coding structures within Kuali.
Purpose of the Chart
What is the primary purpose of a chart of accounts?
To support and validate entries into a general
ledger
What other functions does the Kuali chart of accounts
serve?
•Reporting, both internal and external
•Internal controls and document routing
•Framework for budget construction
Key Attributes of the Chart
• multiple charts of accounts
• organizations and the organization
hierarchy
• accounts and sub-accounts
• object code and sub-object codes
• object level codes and object
consolidation codes
Chart of Accounts at IU
IU COA
UA COA
BL COA
IN COA
BA COA
IA COA
Regional COAs
Benefits of Multiple Charts
• Ability to handle complex reporting structures
• Campus charts are not required to contain object
codes unrelated to their activities (i.e. Cost of
Goods Sold, Inventory, etc.)
• Auxiliary Charts are not required to contain object
codes unrelated to their activities (i.e. Tuition,
State Appropriations)
• Increased Information and Knowledge at the
Campus Level
• Easy Access to Campus Level or Auxiliary
Reporting.
Organizations
• Organization
– Example: FMOP (FMS Administration)
– Collection of accounts or a collection of other
organizations.
– Some organization attributes:
• Chart of Accounts, Responsibility Center, Campus,
Department, Subunit
• Can include all fund groups
• Up to four alphanumeric characters (eg. FMOP)
• HRMS extension table
Organization Hierarchy at IU
UNIV
UA
VPPF
FMS
FMSY
FMOP
Accounts
• Account Number
– Specific identifier for a pool of funds
assigned to a specific organization for a
specific function.
• Example: 19-126-10 (FMS Administration)
Reports to org FMOP
– All accounts can be self-balancing
Account Attributes
• Account Number (continued)
– Attributes of an Account include:
•
•
•
•
•
Chart
Organization
Higher Education Function Code
Restricted/Unrestricted
Sub Fund Group and Fund Group
– Responsibility for an Account
• Fiscal Officer, Account Manager and Account Supervisor
• http://www.indiana.edu/~vpcfo/policies/accounting/i-1.html
Org Hierarchy with Accounts
IU
UA
VPPF
FMS
FMSY
1912631
FMOP
1912610
Sub-Accounts
• Sub-accounts achieve further division of an
account for internal reporting purposes.
• Example:
custr (FMS Customer Service)
Reports to 19-126-10
• Characteristics of a sub-account:
– Account specific
– Assumes all attributes of the account it reports to
Org Hier with Accounts/Sub-accounts
IU
UA
VPPF
FMS
FMSY
1912631
FMOP
1912610
aucap
custr
Object Codes
• Object Codes are detailed identifiers for Income,
Expense, Asset, Liability and Fund Balances.
– Chart specific
– Four numeric digits
– Example 1: BL-2000 “Academic Salaries”
IN-2000 “Academic Salaries”
– Example 2: BL-1504 “Animal Care Income”
IN-1504 “Card Services Income”
Sub-Object Codes
• Sub-object codes achieve further division of an
object code for internal reporting purposes
• Attributes of a sub-object include the following:
– Specific to an account and object code
– Assumes all attributes of the object code it reports to
• Example: In State Travel Object Code 6000
– Faculty Instate Travel, Fac
– Staff Instate Travel, Sta
– Student Instate Travel, Stu
Levels and Consolidations
• All object codes report to a higher Level code
and each Level code reports to a higher
Consolidation code
– Approximately 80 Levels (although no limit)
– Approximately 20 Consolidations (no limit)
– Example:
Object Code
Level
Consolidation
4100 “Office Supplies”
S&E
“Supplies and Expense”
GENX “General Expenses”
Enhancements to the Kuali chart
• Budget Year
– Work in multiple fiscal years at the same time
– Required for reporting uses of state appropriations in many states
• Flexible Claim on Cash
– Post cash offsets to control accounts rather than having each account be
self balancing
• Program Code
– A requirement for all community colleges in California
– Account attribute, will be displayed on each transaction line
• Custom Attributes
– Create additional attributes as necessary on any existing table
Management Control and COA
• How can I use the chart for organizational
management?
– Flexibility in Reporting
– Flexibility in making Routing decisions
– Hierarchy for Responsibility Management
– Facilitates internal controls by assigning fiscal
officers, account managers, supervisors and
delegates.
– Tool for measuring the performance of a
subunit
Management Control and COA
• What tools do I have to achieve my
reporting objectives?
– With the Approval of the Chart Manager
• Organizations
• Accounts
• Object codes
– Sub-accounts (budgeting / spending)
– Sub-object codes (budgeting / spending)
– FDRS Reports
– FIS
Questions?
General Ledger Overview
Sterling George, Indiana University
Vince Schimizzi, Michigan State University
Agenda Topics
• Overview of the accounting cycle from e-doc
creation to decision support
• Components of the accounting cycle (ledger
attributes, back office functionality, and yearend processes)
• Affect of system reference table updates &
chart of accounts e-docs on ledger data
• Kuali GL enhancements
• On-line GL balance inquiry screens
Overview of Accounting Cycle
Accounting Cycle Continued
General Ledger Detail
•
•
•
•
•
•
•
•
•
•
•
•
•
•
FIELD NAME
FORMAT
BUSINESS NAME
UNIV_FISCAL_YR
FIN_COA_CD
ACCOUNT_NBR
SUB_ACCT_NBR
FIN_OBJECT_CD
FIN_SUB_OBJ_CD
FIN_BALANCE_TYP_CD
FIN_OBJ_TYP_CD
UNIV_FISCAL_PRD_CD
FDOC_TYP_CD
FS_ORIGIN_CD
FDOC_NBR
TRN_ENTR_SEQ_NBR
TRN_LDGR_ENTR_DESC
VARCHAR2(4)
VARCHAR2(2)
VARCHAR2(7)
VARCHAR2(5)
VARCHAR2(4)
VARCHAR2(3)
VARCHAR2(2)
VARCHAR2(2)
VARCHAR2(2)
VARCHAR2(4)
VARCHAR2(2)
VARCHAR2(14)
NUMBER(5)
VARCHAR2(40)
FISCAL YEAR
CHART
ACCOUNT NUMBER
SUB ACCOUNT
OBJECT CODE
SUB OBJECT
BALANCE TYPE
OBJECT TYPE
FISCAL PERIOD
DOCUMENT TYPE
ORIGIN CODE
DOCUMENT NUMBER
SEQUENCE NUMBER
TRANSACTION DESCRIPTION
General Ledger Detail Continued
•
•
•
•
•
•
•
•
•
•
•
•
FIELD NAME
FORMAT
BUSINESS NAME
TRN_LDGR_ENTR_AMT
TRN_DEBIT_CRDT_CD
TRANSACTION_DT
ORG_DOC_NBR
PROJECT_CD
ORG_REFERENCE_ID
FDOC_REF_TYP_CD
FS_REF_ORIGIN_CD
FDOC_REF_NBR
FDOC_REVERSAL_DT
TRN_ENCUM_UPDT_CD
TRN_POST_DT
NUMBER(19,2)
VARCHAR2(1)
DATE
VARCHAR2(10)
VARCHAR2(10)
VARCHAR2(8)
VARCHAR2(4)
VARCHAR2(2)
VARCHAR2(9)
DATE
VARCHAR2(1)
DATE
TRANSACTION AMOUNT
DEBIT CREDIT CODE
TRANSACTION DATE
ORG DOCUMENT NUMBER
PROJECT CODE
ORG REFERENCE ID
REFERENCE DOCUMENT TYPE
REFERENCE ORIGIN CODE
REFERENCE DOCUMENT NUMBER
REVERSAL DATE
ENCUMBRANCE UPDATE CODE
POST DATE
General Ledger Balance
•
•
•
•
•
•
•
•
•
•
•
FIELD NAME
FORMAT
BUSINESS NAME
UNIV_FISCAL_YR
FIN_COA_CD
ACCOUNT_NBR
SUB_ACCT_NBR
FIN_OBJECT_CD
FIN_SUB_OBJ_CD
FIN_BALANCE_TYP_CD
FIN_OBJ_TYP_CD
ACLN_ANNL_BAL_AMT
FIN_BEG_BAL_LN_AMT
CONTR_GR_BB_AC_AMT
NUMBER(4)
VARCHAR2(2)
VARCHAR2(7)
VARCHAR2(5)
VARCHAR2(4)
VARCHAR2(3)
VARCHAR2(2)
VARCHAR2(2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
FISCAL YEAR
CHART
ACCOUNT NUMBER
SUB ACCOUNT
OBJECT CODE
SUB OBJECT
BALANCE TYPE
OBJECT TYPE
ANNUAL BALANCE
FINANCIAL BEGINNING BALANCE
C&G BEGINNING BALANCE
General Ledger Balance Continued
•
•
•
•
•
•
•
•
•
•
•
•
•
FIELD NAME
FORMAT
BUSINESS NAME
MO1_ACCT_LN_AMT
MO2_ACCT_LN_AMT
MO3_ACCT_LN_AMT
MO4_ACCT_LN_AMT
MO5_ACCT_LN_AMT
MO6_ACCT_LN_AMT
MO7_ACCT_LN_AMT
MO8_ACCT_LN_AMT
MO9_ACCT_LN_AMT
MO10_ACCT_LN_AMT
MO11_ACCT_LN_AMT
MO12_ACCT_LN_AMT
MO13_ACCT_LN_AMT
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
NUMBER(19,2)
MONTH 1 AMOUNT (JULY)
MONTH 2 AMOUNT (AUGUST)
MONTH 3 AMOUNT (SEPTEMBER)
MONTH 4 AMOUNT (OCTOBER)
MONTH 5 AMOUNT (NOVEMBER)
MONTH 6 AMOUNT (DECEMBER)
MONTH 7 AMOUNT (JANUARY)
MONTH 8 AMOUNT (FEBRUARY)
MONTH 9 AMOUNT (MARCH)
MONTH 10 AMOUNT (APRIL)
MONTH 11 AMOUNT (MAY)
MONTH 12 AMOUNT (JUNE)
MONTH 13 AMOUNT (CLOSING)
Accounting Cycle Components
•
Sufficient Funds Checking - In general, calculates an available amount and prevents
document approval in the event of insufficient funds (budget - actual expenses outstanding encumbrances - pending entries). An optional feature by account with five
variations - object code, level, consolidation, by account, and cash checking.
•
Pre-Scrubber and Scrubber – Perform the following major functions:
Validation of Data
• Application of select missing values
• Reference to chart of accounts for validation (non-free form fields)
• Continuation account logic
Generation of offsets
• Document balancing
• Capitalization of assets and liabilities
• Plant indebtedness
• Cost share transfers
• Cost share encumbrances
Error handling
• Most common source for error files for input into the GLCP e-doc (in conjunction
with De-Merge process)
Accounting Cycle Components Continued
•
De-Merge Process – Pulls all of the transactions for a document that the scrubber found
to have errors and backs out any scrubber generated offsets. This is the main source of
transactions for the General Ledger Correction Process (GLCP) e-doc.
•
GL Poster – Performs the following major functions:
Three instances of the poster
• Primary poster for the scrubbed transactions
• Automated reversal process
• Indirect Cost Recovery (ICR)
Limited validation of data (amount, account number, object type, balance type, fiscal
year, chart, debit/credit indicator, & reversal date)
Updates and inserts to GL tables
• GL Detail (GLEN)
• GL Balance (GLBL)
• Account Balance (ACBL)
• Sufficient Funds (SFBL)
• Open Encumbrances (GLEC)
• GL Reversals (GLRV)
Initial determination of expenses eligible for ICR
• GL Expense Transactions (GLEX) temporary table
Accounting Cycle Components Continued
•
Automated Reversal Process - Systematically reverses transactions that were
created with a reversal date. A copy of the original transaction remains in the GL
Reversal (GLRV) table until the reversal date is reached, at which time a
reversing entry is created and posted. The original entry is then removed from
the GLRV table.
•
Indirect Cost Recovery (ICR) – Calculates ICR based on the expenses found in
the GL Expense Transactions (GLEX) table. Generally, ICR is charged to the
account incurring the original charge and revenue is recorded in an associated
income stream account, usually a general fund Responsibility Center (RC)
account (table driven). The ICR process references attributes of account and
supporting reference tables to derive an amount.
– From account - financial series ID, ICR rate, ICR types, custom exclusions
by object code, and revenue chart and account
– From reference tables – ICR automated entry, ICR type, and account
exclusions
•
Accounting Cycle – Kuali Test Drive accounting cycle runs 11pm EDT Sunday –
Friday with refreshes of the test database each Saturday at 5:30am. Documents
fully approved by the 11pm accounting cycle will post to the General Ledger
tables.
Functionality and Chart Set-Up
•
Attributes of Account Numbers
– Sufficient funds checking on/off indicator and type of checking (object code,
level, consolidation, cash checking, account)
– Expiration date, closed indicator, and continuation accounting string for
continuation account processing
– Indirect cost rates, financial series ID’s, exclusions, and revenue accounts
for Indirect Cost Recovery (ICR) calculations
•
Attributes of Sub-Account Numbers
– Identifies cost share sub accounts and the source accounting string for cost
share transfers and cost share encumbrance processing
•
Attributes of Organizations
– Identify the plant fund account numbers for capitalization and plant
indebtedness
•
Offset Definition Reference Table
– Determines the appropriate offset in the event a balancing transaction is
needed
•
Many other examples for other GL fields and reference tables…
GL Correction Process (GLCP)
GL Enhancements - Turn On/Off
•
•
•
Flexible Offsets – Allows posting of generated offsets (cash, accounts payable,
salaries payable, etc…) to a specified offset accounting string. Each
implementing institution can determine if offsets should post to the same account
as the original transaction or to another defined accounting string. An offset
accounting string can be established by document type within an account.
Bank Specific Claim on Cash – At the document level, allows the association of
receipts and disbursements with a specific bank account. When activated users
can specify a specific bank on appropriate e-docs (DV, ND, CR, PREQ, etc…).
When specified an additional set of cash transactions will be generated which
reclassify the original cash entry to a bank specific cash entry, likely in an
institutional level account. The accounting string for the additional bank specific
entries is maintained via bank reference tables.
Indirect Cost Recovery (ICR) Encumbrances – An extension of the actual ICR
calculation for encumbrances. This is an optional feature, that when activated
will calculate ICR encumbrances based on the outstanding encumbrance
balances for an account. The intent is to provide a more complete view of an
account’s position.
GL Enhancements Continued
- Turn On/Off
•
Budget Year – Allows an institutions to associate individual transactions by a
budget year (for a given funding source), which may differ from the institution’s
fiscal year. Examples might include: annual appropriations from the federal
government to land-grant institutions; annual appropriations from state or local
governments; and funding for sponsored research projects, which may cover a
period of several years. When assigned the budget year attribute will post to
the general ledger detail (GLEN) table and additional budget year balance
tables. Additional features of the budget year enhancement include:
–
Multiple budget years for the same funding source may exist at various
stages of the budget year life cycle (future, open for budget, open,
restricted, extended, closing, and closed).
–
Business rules will govern the appropriateness of an assigned budget year
based on the budget year life cycle status and the document being
processed.
–
A default process will assign an appropriate budget year should an external
feed not provide a budget year value.
–
A budget year close process, driven by business rules, will govern how
unexpended funds are carried forward or lapsed back to a granting agency.
On-Line Balance Inquiries
Common Inquiry Features:
•
•
•
•
•
Drill Down Capability – Users can drill down from balances to detail transactions
and from detail transactions to e-docs.
Include/Exclude Pending Entries – Inquiry screens will have the ability to
include all pending ledger entries, approved pending ledger entries, or exclude
pending entries from the results.
Consolidation/Detail Option – Allows the users to accumulate results by SubAccount, Sub-Object Code, and Object Type or return each occurrence for
these fields.
Export Functions – The results of the balance inquiry screens may be
downloaded in CSV, Excel, or HTML formats.
Sort-able Results – The output may be sorted in ascending or descending order
by clicking on the appropriate columns.
On-Line Balance Inquiries
Continued
Balance Inquiry Screens:
•
•
•
•
•
•
•
Available Balances - Summary totals of Budget, Actual, Encumbrance, and Variance amounts
by Fiscal Year, Chart, Account Number, Sub-Account Number, Object Code, and Sub-Object
Code.
Balances by Consolidation - Summary totals of Budget, Actual, Encumbrance, and Variance
amounts by Fiscal Year, Chart, Account Number, Sub-Account Number, and Consolidation.
Users have the ability to drill down to Level and then to Object Code.
Cash Balances - Provides Beginning, Annual, and Ending Cash Balances by Fiscal Year, Chart,
Account Number, and Sub-Account Number.
General Ledger Balances - Summary totals of General Ledger balances by Fiscal Year, Chart,
Account Number, Sub-Account Number, Object Code, Sub-Object Code, Object Type, Balance
Type, and Accounting Period. Balances can be displayed individually for each Accounting
Period or accumulated and reported as year-to-date totals.
General Ledger Detail - Listing of transactions posted to the General Ledger.
Pending General Ledger Detail - Listing of Pending Ledger Entries for the General Ledger.
When a financial transaction E-Doc is initiated, Pending Ledger Entries are created. These
entries remain in the Pending Ledger Entry table until they are posted to the General Ledger.
Open Encumbrances - Listing of the open encumbrances for an Account Number. Both the
original encumbrance amount and the amount relieved to date are displayed.
Year-End Processing
•
•
•
•
•
Cancellation of select unapproved E-docs after June 30 accounting cycle
Activation of year-end documents for posting to fiscal periods 12 & 13
– Accounting transactions occur in two fiscal years
• Normal Kuali documents post in the period approved
– Prior to June 30 they post to the previous fiscal year
– After June 30 they post to the new fiscal year
• Year-end documents post to the prior fiscal year
– Through first closing they post to period 12
– After first closing through final closing they post to period 13
Snapshots of Account and Organization tables for year-end reporting
Generation of Business Manager Reports – General Fund Organization
Reversion, Negative/Positive Cash, Outstanding Encumbrances, Prior Year June
Activity, General Ledger, Fund Statements, Preliminary Balance Sheet – also
available as Pre-Defined Queries (PDQ’s) at Pre-Closing (June 6), First Closing
(July 6), Second Closing (July 14), and Final Closing (July 25)
Generation of Monthly Standard Reports for First and Final Closing
Year-End Processing Continued
Four primary year-end processes are run in sequence to properly close a fiscal year:
• Organization Reversions and Carry Forwards – Driven by the GL Balance (GLBL) table and
Organization Reversion reference table. Computes budget and cash reversion and carry
forward amounts based on a set of defined business rules. Business rules are established
for organizations within the General Fund and computations are performed by common
categories (Salaries and Wages, Financial Aid, Compensation, Travel, Capital, Other
Expenses, etc…). Following are two examples of possible business rules:
– Carry forward enough budget to cover outstanding encumbrances. Then carry forward
any remaining positive budget balances and revert any remaining negative budget
balances.
– Don’t carry forward enough budget to cover outstanding encumbrances. Then revert
remaining budget balances.
• Encumbrance Forwards – References the GL Open Encumbrance (GLEC) table and sets
up outstanding encumbrances for the new fiscal year.
• Close Out of Nominal Activity – Closes all nominal activity (Income and Expenses) to Fund
Balance based on amounts found in the GL Balance (GLBL) table.
• Beginning Balance Forwards – Establishes beginning balances for Assets, Liabilities, and
Fund Balance (as Financial Beginning Balances) and cumulative Income and Expenses (as
Contracts and Grants Beginning Balances). The latter is only performed for a select set of
Fund Groups.
Questions?
Basic Transaction
Documents
Joan Hagen, Indiana University
Kymber Horn, University of Arizona
TP Global Concepts
Transaction Processing
• Users create transactions with built-in
edits before transactions route for
approval.
• Fully approved transactions are sent to the
general ledger.
• Allows read-only access to transactions via
document search.
Electronic Documents
•
•
Document groups:
– Accounts Receivable
– Capital Assets
– Contract & Grants
– Financial Documents
– Labor Distribution
– Chart of Accounts Maintenance
Financial documents include:
– Budget Adjustment
– Cash Receipt
– Disbursement Voucher
– Distribution of Income/Expense
– General Error Correction
– Internal Billing
– Journal Voucher
– Disbursement Voucher
– Transfer of Funds
Edits and Rules
•
•
Validations
Restrictions
– Account
– Object code
•
•
•
Balancing rules
Special features/Specific documents
Authorizations/Routing
eDoc Account Edits
eDoc Object Code Edits
Kuali Business Rules
• Maintained by Financial System
Parameter Tables
• Allows Functional Users to maintain
and create business rules.
• Allows institutions to customize out of
the box business rules based on their
codes and policies.
Moving Expense Business Rule
Moving Expense Business Rule
Financial System Parameter
Editing Business Rules
Editing Business Rules
Offset Entries
• Users create transactions based on
what they know - From/To, etc.
• The system creates the offsets to the
appropriate balance sheet account.
• Flexibility of where cash is posted:
– Within the account to create self balancing
accounts
– To an institutional account
• Pending Entries are part of the
document.
General Ledger Pending Entries
After Validation
• Once an eDoc is validated it is routed
through workflow.
– Fiscal Officer Routing
– Organization Routing
– Special Conditions Routing
Questions?
Workflow
Damon Dorsey, Indiana University
What is Workflow?
Functionally . . .
Workflow is the art of moving transactions from one
place to another, requesting and recording actions
related to that transaction along the way.
Technically . . .
Workflow is a routing engine that works with Kuali.
Workflow functions by matching attributes of a
transaction to existing rules that indicate where a
transaction with those attributes should go. Most
commonly Workflow is used to collect approvals.
How does Workflow work?
After a transaction is initiated, Workflow electronically
routes the transaction to the proper approvers.
The path of approval can be influenced by:
– The type of transaction (example: a Cash Receipt document may
route differently than a Transfer of Funds)
and . . .
– The content of the transaction itself (example: a transaction
charging supplies to a grant account may need to route for
special approval)
What Workflow Actions are Available?
Workflow can send users action requests of various types. These requests
are collected in the user’s Workflow Action List.
Common types of action requests include:
Approve: Verify that the transaction is acceptable. Approved financial
documents will continue routing to additional approvers, or--if fully approved-be included in the next update to the General Ledger.
Acknowledge: A request to view and acknowledge a transaction without the
need for a formal approval.
FYI Review: A courtesy request allowing the user to view the transaction or
just clear the request from their action list without viewing it.
What Workflow Actions are Available?
Disapproval: Requests for approval can be
disapproved, indicating the transaction is incorrect or
unacceptable. Disapproved transactions cease further
routing and will not be sent to the general ledger.
The document initiator and any previous approvers
receive an Acknowledgement action request, letting
them know the document has been disapproved.
Disapproved documents (in fact, any documents) can
be copied and used as the basis for future documents.
This allows for easy correction and re-submission.
Financial Document Routing Overview
Documents pass through one or more route levels (also called
“route nodes”).
Route levels represent different sets of rules that will evaluate
a document to determine its routing.
Different documents may pass through different route levels.
Commonly, financial documents pass through the following
route levels:
– Account Level (Fiscal Officer)
– Organization Level (Review Hierarchy)
– Special Conditions Routing
Financial Document Routing Overview
Account Level (Fiscal Officer)
All accounts used on the document are identified and it routes
to a designated approver (in Kuali we call this person a
“Fiscal Officer”) for each of those accounts.
Example:
Sue is the Fiscal Officer for account 1012300. All financial
transactions involving that account will require her approval.
All approvals at this level must happen before the document
moves forward.
Financial Document Routing Overview
Organization Review (Review Hierarchy)
Every account belongs to an organization and customized routing to
individuals or workgroups can be established by each organization based on
document type and dollar amount. This routing can take advantage of the
Chart of Accounts Organization Hierarchy.
Examples:
The Dean of Biology wants a chance to approve every Transfer of Funds
document over $1,000 that involves a Biology account.
The Chancellor’s office wants to see Transfer of Funds documents over
$100,000 for all organizations that answer to a particular campus.
All approvals at this level must happen before the document moves forward.
Financial Document Routing Overview
Special Conditions Routing
This is a blanket-term for additional route levels that might be
triggered by various attributes of a transaction. They often
represent special administrative approvals that may be
required.
They can be based on the type of document, attributes of the
accounts being used, or other attributes of the transaction.
Examples:
Disbursement Vouchers for travel must be approved by
Travel Management.
A transaction using a grant account must be approved by a
central Contract & Grant Administration area.
Delegates
Fiscal Officers can delegate approval authority to
other users based on attributes of a specific
transaction such as document type and dollar
amount.
Delegates can approve documents at the “Account
Level” of routing as if they were the Fiscal Officer.
Two kinds of delegates exist: Primary delegates
and Secondary delegates.
Fiscal Officers can choose to establish either type
of delegate or both.
Delegates
Primary
Documents route directly to primary delegates
instead of routing to the Fiscal Officer.
Secondary
These delegates have a special “filter” option in
their action list that allows them to retrieve
documents for which they have been given
approval authority.
Fiscal Officers can still access any documents
they are responsible for.
Workgroups
A workgroup is a collection of approvers who
share a similar responsibility.
If a document routes to a workgroup, all
members of the workgroup will see that
document in their action lists.
Once any member of the workgroup takes
action on that document, the document is
removed from the action list of all other
members of that workgroup.
Ad-Hoc Routing
Ad-Hoc routing allows a document initiator or
approver to add additional individuals or workgroups
to the routing of a specific document.
Approvers inserted into the routing “interrupt” the
regular routing process.
Example:
If I initiate a financial document and ad-hoc
route it to my boss for approval it will go to her
before it goes to the Fiscal Officer.
You can request that an ad-hoc recipient Approve,
Acknowledge or FYI Review the transaction.
Blanket Approval
Users can be established as Administrators,
giving them the ability to blanket approve most
transactions they initiate or for which they are
an approver.
Blanket approval pushes a document to
“Approved” status.
All approvers who are skipped by the blanket
approval receive an Acknowledgement request
for that document—ensuring that they see it.
System Supervisor Approval
A user established as a System Supervisor
(“super user”) can take special workflow
actions:
–Fully Approve or Disapprove any document,
regardless of currently pending approvals.
–Approve a single action request for a particular user.
–Approve the document through to a different route
level (sending it straight to Organization Review, for
example).
Is it Flexible?
Routing can be configured in Workflow.
– Delegates / Organization Review / Ad-Hoc routing.
– Different rules can be constructed and associated
with specific document types or groups of
documents.
– Different attributes of transactions can be used to
trigger routing rules.
Questions?
Standard Reports
and
Balance Inquiry
David Lyons, NACUBO
Standard Reports
•
•
•
•
•
•
•
Account Status
Consolidated Account Status
Consolidated Object Codes
Account Transactions
Trial Balance
External Reports
Balance Inquiry
Account Status
• For Accounts with Budgets:
Budget, Actual to Date, Balance,
Commitments, and Final Balance
• For General Ledger Accounts and/or
Object Codes: Beginning Balances,
Actual to Date and Ending Balances for
Each Object Code
Consolidated Account Status
• Groups of Accounts by
Organization Unit
• Organization Unit Examples:
Academic Department, Dean, School,
Auxiliary Enterprise, Physical Plant,
Vice President
Consolidated Object Codes
• Groups of Object Codes by
Organization Unit
• Highest Level: Summary of Object
Codes for Entire College or University
Account Transaction
• Details the Individual Transactions
Shown in Summary in the Account
Status Report
• Descriptions and Document
Reference Numbers
• Actual and Encumbrances
Trial Balance
• For Each Account: Beginning
Fund/Net Equity Balances with
Additions, Deductions and Ending
Balances.
• Columns for Assets, Liabilities and
Cash Ownership to Complete the
Accounting Equation
External Reports
• FASB or GASB as Appropriate
• Use Kuali Attributes and Chart
Structure to Develop These
Reports
Balance Inquiry
• Include/Exclude Pending Entries
• Account, Sub-account, Object Code,
Sub-object Code
• Budget, Actual Encumbrance,
Variance
• Drill Down to Underlying Transaction
Document Number
Questions?