1. DATA WAREHOUSING AND REPORTING
Kuali Financial

2. Date Warehousing and Reporting
Bill Overman – Indiana University Dylan Cooper – University of Arizona Susan Moore – University of California, Davis

3. Date Warehousing and Reporting
Agenda
Overview of approach taken by each school
Hints on important data
Technical hints
Demonstrations
Note: These applications do NOT come with KFS

4. Indiana University Datagroups Important fields to consider
Both GL and reference tables
Denormalized
Important fields to consider
Returns data to spreadsheet

5. Datagroups from GL tables
General Ledger Entry
Transaction level detail
Includes a description
General Ledger Balance
Summary by accounting string

6. General Ledger Entry Balance Type Code – budget, actual, encumbrance
University Fiscal Period Code denotes month
Object Type, Amount and Debit/Credit Flag work together to determine positive/negative sign

7. General Ledger Balance
Balance Type Code
Buckets for monthly balances
Other buckets
Account Line Annual Balance Amount
Financial Beginning Balance Amount
Contract and Grant Beginning Balance Amount

8. Denormalizing Account Name Fiscal Officer Organization
Expiration Date, Closed Indicator
Sub-Fund Group  Fund Group
Higher Education Function Code

9. Denormalizing Object Code Object Level Code Object Consolidation Code
Reports to Object Code

10. Datagroups from Reference Tables
Account/Organization Datagroup
Object Code Datagroup
Sub Accounts
Sub Object Codes
Year End Snapshots

24. The University of Arizona
Dylan Cooper
Introduction of self and UA
Hi.  I’m Dylan Cooper from The University of Arizona. We are founding partners for both KFS and KC and are in the process of implementing both, although we have not set official go-live dates at this time.
-Display PowerPoint Notes-

25. KFS DW/BI Team
Doug Hester – Senior Technical Dylan Cooper – Senior Technical Nargis Memon – Junior Technical Ned Tomsheck – Accountant Nevil Pozholiparambil – Masters Student/Junior Technical
We have a team of five (more or less) working on DW/BI side of the KFS go-live.
SKIP: We have two senior tech people (Doug Hester and myself), one recent MIS Masters graduate from UA (Nargis Memon), one current MIS Masters student (Nevil John) and one accountant who has been at UA for over 20 years (Ned Tomsheck). Much of the work I am showing here was done by the other people on the team, especially by Doug Hester.
My primary role has been to architect the warehouse.  I have also trained our team on data warehousing topics, created template data structures and ETL jobs., and done a lot of modeling and ETL programming. I’ve also done a bit of BI modeling/content and will be turning more attention to it as we progress.

26. UAccess Analytics The University of Arizona Basics
Front end: Oracle Business Intelligence EE Plus
ETL: IBM DataStage
Back end: Oracle (PeopleSoft EPM)
Data
Star schemas
Data Marts (in development) - General Ledger, Chart of Accounts, Labor Ledger, Capital Assets and Purchasing
We will go live when KFS itself goes live. SKIP: Since our existing warehouse is old school and built on completely different data sources, we’ve started over with all new technology.
For the front end, we are using OBIEE+. I’ll show you a little of that in this talk. SKIP: That’s basically the old Siebel Analytics dashboard tool and Hyperion’s Interactive Studio ad hoc query tool bundled together. It also includes some other stuff stuff. For example, we’re using the old Oracle BI Publisher tool to deliver PDF files.
We’re doing all our ETL work with IBM DataStage. SKIP: We are intentionally not using Oracle MV or CDC stuff because I wanted to keep the skill set required for ETL development self-contained.
Our back end is Oracle. We are integrating our Kuali data into a PeopleSoft EPM warehouse that we just took live in September. SKIP: This warehouse has HR data in it and will soon have student data as well.
Unlike Indiana and UC Davis, we are creating a dimensional warehouse where everything is organized into facts and dimensions. I did teach a five session dimensional modeling class and workshop to help get the team started with that.
Lastly, since KFS doesn’t have much by way of built-in reporting, we are focusing first on operational reports that provide the same sort of information (more or less) that the functional offices and business managers are used to getting from the FRS system.

27. Trial Balance Report
Start out by showing one of these reports and then drilling back through the BI and DW layers to show you how it was built. This report shows activity by fund group. It is based on our FBM061 report in FRS.
I know you can’t really see it but the next few slides zoom in. I have the full thing up so you can see it has three parts: a drop-down at the top for selecting the fiscal period you are interested in, a trial balance report, and a net monthly activity report.
SKIIP: I’m showing screen shots because, not being live, I don’t trust our system to be up and working when I need it to.
Let me zoom in so you can see something…

28. Trial Balance Report
I should point out that this is development data and you shouldn’t draw any conclusions about UA’s finances from this. For example, when I do testing I tend to give myself million dollar bonus.
SKIP: The drop-downs for selecting the period default to the current period. When you change it, both the report I’ve zoomed on here and the period net activity report below it update with the results from that period.
I’ve also set up some drill downs in the report. For example, if you click on the “State” fund group.

29. Trial Balance Report
Drilled down from State fund group to the sub-fund level. This automatically uses the KFS sub-fund sort code when displaying the sub-funds. SKIP: I originally drilled from fund to sub-fund type but we have not configured useful categories in that yet so I skipped over to sub-fund.
From sub-fund you can drill down again…

30. Trial Balance Report Drilled down to account.
So that’s a basic report in our system. We do have more complicated ones but I wanted to stick to something I could show quickly
Once everything is set up, making such a report is really easy in OBI. Basically you just drag and drop columns into your report, set filters if you want any, drag in any drop-down you need, and change any formatting you don’t like. Our idea is that a whole lot of people in the campus community can make reports themselves and do not need to rely on IT staff to do it. To help make that happen, we have two people who have been providing OBI training to campus and have had over 500 people through the classes. It seems to be working out well.
To do the setting up that makes this so easy, we use the OBI Administration tool…

31. OBIEE Administration Tool
This is where you set up the joins, drill-down hierarchies, calculated columns, metadata and names and groupings that users see when creating and running reports.
I’ve opened up the account dimension in the repository here. On the right side is where you import table definitions from the warehouse. The left side is where you tweak the display characteristics. Middle is where you do most of the work. I’ve opened the drill-down on fund/subfund/account. This is where I set up the sort for the sub-fund sort. (SKIP: There is one drill-down for the fund name that goes to sub-fund name and another for the fund-code that goes to sub-fund code.)
SKIP: We’re doing this work in our group because 1) it is more difficult than the other OBI work 2) the multi-developer coordination on OBI could be a lot better and 3) a bad model can produce wrong results and/or bring the database to its knees.
Of course the real complexity in reporting is in setting up the warehouse so that the data that people need is easily available. So I am going to drill into our warehouse design…

32. Summary Account Activity Star
Dimension
Fiscal Period Dimension
Account Activity Fact
This is the star schema from which the example report was built.
How many of you—just a show of hands--are either doing dimensional modeling or are familiar with it?
IF LOTS OF PEOPLE NOT UP ON DIMENSIONAL MODELING: dimensional modeling is just a way of setting up your data in the warehouse. It is built around facts and dimensions. Facts are things you measure, like amounts on the GL or hours entered in payroll. Dimensions are the attributes that give those facts context, for example, account number or fund group description.
The central fact table in this star contained all the amounts displayed in the report. We pre-calculated those in our ETL process so people could drag and drop them into reports. The dimension tables provide the context to describe those amounts. In our example, the fund, sub-fund and account all came from the account dimension table. The drop-downs at the top of the report used the fiscal period dimension. Our report didn’t use the object code dimension. SKIP: I intend to add a project dimension.
To make this a bit more concrete, let’s look at the fact table…
Object Code Dimension

33. One row for each account, object code and fiscal period
Account Activity Fact
Keys for Dimensions
Summary Table
One row for each account, object code and fiscal period
combination
Month Net Measures
YTD Measures
This is a summary fact table. It is summary in two ways. First, it only contains transactions for actuals, no budget or encumbrance. Second, it has only one row for each account, object code and fiscal period combination in the general ledger. This helps performance but more importantly, provides the right level for pre-computing a lot of useful values.
For example, in addition to the net activity for the month, we create a set of columns with YTD information. The example report used the YTD columns. Additionally we have prior month and prior year columns to allow easy comparisons, graphing, etc.
Moreover we explode out the amounts columns in each of these sets into useful categories…
Prior Month Measures
Prior Year Measures

34. Account Activity Fact Transaction Data Pivoted Data Account
Acct Category
Amount
Income
Expense
10.00
100.00
50.00
500.00
12345
ABCDE
Account
Income Amt
Expense Amt
12345
20.00
200.00
ABCDE
100.00
500.00
For example, instead of having just one YTD amounts column, we make a separate one for each KFS basic accounting category. That way we have separate columns for fund balance, assets, liabilities, expenses, income, etc so that people can just drag those into their reports. In my diagram I’m showing just income and expense due to space constraints.
I don’t have time to go into the details of our data model, but if you’re interested just find me later on or send me an . I’d be happy to talk to you about it. I think we’re doing things in a way that is really working out.
SKIP: Of course, this summary table is built from a detail fact table. The detail table has one row for every entry in the GL and has more dimensions such as balance type, document type, and origination code. We aggregate the actuals from the detail table to make the summary table.
Now lets turn our attention to a dimension table…

35. Account Dimension Chart Info Slowly Changing Dimension
Organizational Unit Info
Tracks changes in account information
Account Type Info
Fund Info
The account dimension table brings together all the data about accounts into one place for reporting. We pull data from over 30 tables to make this dimension.
It is implemented as a slowly changing dimension, which means that we track changes to accounts in this table as they occur over time. For example, if an account moves from one organizational unit to another because the PI switched departments, we would make two records in the account dimension. All the transactions from before the move would be reported with the first department and all the transactions from after the move would be reported with the second department. For those of you familiar with dimensional modeling, we are using primarily Hybrid Type 1-2 SCDs.
Of course to build the facts and dimensions, we need to pull data out of KFS and that is the last step I will show you here…
Account Info
Sub-Account Info

36. KFS Staging Area Staging Tables COPY OF KFS CHANGES History Tables
FACTS & DIMENSIONS
Report Tables
We first copy almost all the KFS tables into the data warehouse on a nightly basis--after the batch jobs have run. Then since KFS has little tracking of changes built into it, we compare the current day’s data to the previous day’s data and record all the changes we find into history tables. We then use the changes to bring the fact and dimension tables up-to-date. SKIP: Lastly we record any errors we find – e.g. invalid user id in account supervisor column – into error tables.
I should note, we store the complete history of changes so that we can rebuild the dimensional tables—or create new ones—at any time without losing any information.
SKIP: To avoid a whole lot of work and maintenance effort, we built generic ETL jobs that use the ORA_ROWSCN pseudo-column and the OBJ_ID column in each table. This allows us to identify rows easily—by OBJ_ID—and detect changes by comparing ORA_ROWSCN values. The details of this are outside the scope of this presentation but feel free to ask me about it later.

37. Conclusions Dimensional Warehouse vs. Traditional Warehouse
Specialized Tools vs. General Purpose Tools
So that was a 15 minute tour of how we are building our reports for KFS at The University of Arizona. We started by looking at a report and then diving down through the BI and DW layers.
The two points that most stand out for me in our approach are that we are creating a dimensional warehouse and that we are using specialized ETL and BI tools.
I have worked on both dimensional warehouses and more traditional ones where you denormalize the operational tables and use snapshots for history. The main advantage of the dimensional approach, I think, is that you create a much richer data set that is easier for your users to access intuitively, especially with a tool such as OBI which removes many of the technical hurdles. It also sets you up very well for more in-depth analysis. The drawback is that it involves more of an up-front investment in both time and expertise. In order to build the data structures you need to understand both the data itself and the business processes involved as well as the dimensional modeling concepts.
Once again feel free to grab me any time during the conference to talk about this stuff.
But before I end, I would like to mention…

38. KFS Decision Support SIG
Tuesday: 6:15 – 6:45 Conference Room 17
Wednesday: 11:00 – noon Conference Room 12
James Singleton
Cornell University
Tina Golini Jessee
Indiana University
We have recently organized a Kuali Reporting SIG. Jim Singleton (from Cornell) and Tina Jessee (from Indiana) are the co-chairs. Get them to stand up or wave. The SIG is meeting right after this presentation in Room 17. Please come.
Now it’s my honor to introduce Bill Overman from Indiana University, whom you probably all know at least from the listserve. He is tremendously knowledgeable about how KFS works and is very helpful in sharing his knowledge. He will talk about Indiana’s reporting solution…

39. University of California, Davis

40. UC Davis Decision Support
Decision Support Basics
Front end: Cold Fusion
Bank end: Oracle
Data
Source - General Ledger and reference tables
Denormalized data
Month end snapshot – ensures reports are reproducible

41. UC Davis Decision Support
Access
Broad campus access
Few access restrictions
Account type limits budget provisions
Payroll detail limited to user’s organization

42. UC Davis Decision Support
Output
Options

43. UC Davis Decision Support
Demonstration
Demo:
1. Scheduling queries
2. Floating buttons
3. Advanced Criteria
4. Sort options
5. Data Options: pending transactions, encumbrances C&G History balances
6. Balance report
7. Transaction report
8. Reference reports
40 - documents initiated
211 – documents approved
9. Custom object groupings
10. Annual schedules –schedule B (uniform accounting codes and academic discipline)