Advanced FDS Reporting Training Guide

Advanced FDS Reporting

COPYRIGHT & TRADEMARKS

Copyright © 1998, 2009, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names

may be trademarks of their respective owners.

This software and related documentation are provided under a license agreement

containing restrictions on use and disclosure and are protected by intellectual property

laws. Except as expressly permitted in your license agreement or allowed by law, you

may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute,

exhibit, perform, publish or display any part, in any form, or by any means. Reverse

engineering, disassembly, or decompilation of this software, unless required by law for

interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted

to be error-free. If you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S. Government or anyone

licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to

U.S. Government customers are “commercial computer software” or “commercial

technical data” pursuant to the applicable Federal Acquisition Regulation and agency-

specific supplemental regulations. As such, the use, duplication, disclosure, modification,

and adaptation shall be subject to the restrictions and license terms set forth in the

applicable Government contract, and, to the extent applicable by the terms of the

Government contract, the additional rights set forth in FAR 52.227-19, Commercial

Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway,

Redwood City, CA 94065.

This software is developed for general use in a variety of information management

applications. It is not developed or intended for use in any inherently dangerous

applications, including applications which may create a risk of personal injury. If you use

this software in dangerous applications, then you shall be responsible to take all

appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of

this software. Oracle Corporation and its affiliates disclaim any liability for any damages

caused by use of this software in dangerous applications.

This software and documentation may provide access to or information on content,

products and services from third parties. Oracle Corporation and its affiliates are not

responsible for and expressly disclaim all warranties of any kind with respect to third

party content, products and services. Oracle Corporation and its affiliates will not be

responsible for any loss, costs, or damages incurred due to your access to or use of third

party content, products or services.

Training Guide Advanced FDS Reporting

Page iii

Table of Contents Advanced FDS Reporting ................................................................................................ 1

Advanced FDS Reporting .......................................................................................................... 2 FDS Data Flow ....................................................................................................................................... 3

What's Changing? ............................................................................................................................................... 4 Introduction to the University Data Store (UDS) ................................................................................................ 5

Introduction to the Historical Data Store (HDS) ............................................................................................ 6 Introduction to the Financial Data Store (FDS) .............................................................................................. 7

ARC Data .................................................................................................................................................. 8 Introduction to the HR Data Store (HRDS) ................................................................................................... 9

Labor Accounting Data ........................................................................................................................... 10 PAC Data ................................................................................................................................................ 11

Introduction to the Student Data Store (SDS) .............................................................................................. 12 Components of the Data Architecture ............................................................................................................... 13 FDS Context Diagram ...................................................................................................................................... 14 FDS Data Flow ................................................................................................................................................. 15

How Secured Views Work ........................................................................................................................... 16 FDS Load and Blackout Period ........................................................................................................................ 17

FDS Data Content and Usage ............................................................................................................... 18 Authentication and Security .............................................................................................................................. 19

Components of Security ............................................................................................................................... 20 ChartField Security ...................................................................................................................................... 21 FDS Users (Power Users and Service Accounts) ......................................................................................... 22

ChartFields and Trees ....................................................................................................................................... 23 ChartField Summary Table .......................................................................................................................... 24 Department Trees ......................................................................................................................................... 25

COA Crosswalk Tool........................................................................................................................................ 27 Using the Crosswalk Tables in FDS or LDS..................................................................................................... 28 Effective Dating versus Current Dating ............................................................................................................ 30

Example ....................................................................................................................................................... 31 PS Department Table Definition .................................................................................................................. 32 Current Dating ............................................................................................................................................. 34 FDS Department Table Definition ............................................................................................................... 35

FDS Entity Relationship Diagrams (GL Data Model) ...................................................................................... 36 GL Ledger Data ........................................................................................................................................... 37 GL Summary Tables and Views .................................................................................................................. 38 GL Ledger with Current ChartField Descriptions ........................................................................................ 39 GL Secured Views ....................................................................................................................................... 40

Data Dictionary (GL) ........................................................................................................................................ 41 Entities ......................................................................................................................................................... 42 Entity Views ................................................................................................................................................ 43 Attribute Definitions .................................................................................................................................... 44 Attributes ..................................................................................................................................................... 45

Report Data Grid............................................................................................................................................... 46 FDS Connectivity ................................................................................................................................. 47

Access Request Form........................................................................................................................................ 48 Requesting Access to Query the FDS ............................................................................................................... 49 Final Steps ........................................................................................................................................................ 50 Tools ................................................................................................................................................................. 51

Course References ................................................................................................................................ 52 Knowledge Assessment ........................................................................................................................ 53

Glossary ........................................................................................................................... 54


Page 1


Training Guide


Page 2

Advanced FDS Reporting This is the Advanced FDS Reporting course within the Reporting curriculum.

If you need a reminder on how to navigate through this course using ARC's web-based training

tool (WBT), click here for a quick reference guide.


Page 3

FDS Data Flow This is the FDS Data Flow lesson of the Advanced FDS Reporting course. Upon completion of

this lesson, you will be able to:

Define the components that make up the University Data Store (UDS)

Identify the components of the FDS data architecture

Describe the FDS Context Diagram

Explain what is happening during the FDS Load Process

Estimated Time to Complete Lesson: 15 minutes

Training Guide


Page 4

What's Changing?

The concept of the Data Warehouse will be changing and will now be organized into a set of

database known as the University Data Store.


Page 5

Introduction to the University Data Store (UDS)

The University Data Store (UDS) is the new central repository where data from ARC, PAC/LA,

Student, Integrated and Historical/Legacy systems is stored. The data within the UDS is

organized into 'functional' data stores to be used by reporting applications, for application extract

feeds and Ad-hoc user queries as represented in the following diagram.

Training Guide


Page 6

Introduction to the Historical Data Store (HDS)

The Historical Data Store (HDS) will contain data thru June 30, 2012 and will become static after

FY’12. It will be available for historical reporting and inquiry, FAS, CAPS, and AP/CAR data

previously provided for the old Chart of Accounts (COA) will continue to be available for read-

only. This historical data will not be converted to reflect ARC's new Chart of Accounts. All

current financial reports will be available thru June 30, 2012.


Page 7

Introduction to the Financial Data Store (FDS)

The objective of the Financial Data Store (FDS) is to provide a reporting database that contains

integrated financial and non-financial data from multiple sources that are needed for reports,

queries, and extracts. Because the data originates from multiple sources, the integration often

involves cleaning, resolving redundancy and checking against business rules for integrity. An

FDS is usually designed to contain low-levels of atomic data (such as transactions and prices).

Updates to the FDS are typically captured either in a complete or incremental refresh.

The ARC financial database is a series of data silos organized by the modules that are being

implemented:

General Ledger/Budgeting

Commitment Control (KK)

Accounts Payable (AP)

Procurement

Project Costing (PC)

The data in these silos is not easy to report on without building customized views or other

mechanisms to link the data. Thus, the FDS is designed to integrate the data more easily.

Additionally, many financial reports are integrated with HR/Labor Accounting data, such as

payroll. The data extracted for these types of reports are accessed from the FDS.

Training Guide


Page 8

ARC Data

The data from each ARC module is used by specific systems and user groups.

General Ledger Data

The General Ledger (GL) data is used by the following systems and user groups:

Alumni

Facilities and Management (FM)

'Shadow' Systems

American Recovery and Reinvestment Act (ARRA)

National Science Foundation (NSF)

Effort Reporting and Certification System (ECRT)

The full complement of GL data is also available to FDS users by way of secured views, and is

also used as source data from the FDS to populate customized subject area databases such as

ARRA and NSF. In addition, GL data is interfaced to the Data Warehouse for use in preparing

data for ECRT.

Project Costing Data

The Project Costing (PC) data is used by the following systems and user groups:




PC data is read from the FDS to populate customized subject area databases such as ARRA and

NSF, and is then interfaced to the Data Warehouse for use in preparing data for ECRT.

Accounts Payable Data

The Accounts Payable (AP) data is used by the following systems and groups:


The full complement of AP data is also available to FDS users by way of secured views.

Purchase Order Data

The Purchase Order (PO) data is used by the following systems and user groups:


The full complement of PO data is also available to FDS users by way of secured views.


Page 9

Introduction to the HR Data Store (HRDS)

The data from PAC/LA is used by specific systems and user groups.

Training Guide


Page 10

Labor Accounting Data

The Labor Accounting (LA) data is used by the following systems and user groups:




Labor accounting data is used as source data from the FDS Labor database to populate

customized subject area databases such as ARRA and NSF, and will continue to interface to the

Data Warehouse for use in preparing data for ECRT. In addition, the full complement of LA data

is available to FDS users by way secured views.


Page 11

PAC Data

The People@Columbia (PAC) data is used by the following systems and user groups:




HR reports in the Data Warehouse

PAC data is interfaced to the HR database and used to populate customized subject area databases

such as ARRA and NSF. PAC data will continue to be interfaced to the Data Warehouse as in the

current state for continued use for HR reporting as well as preparing data for ECRT.

Training Guide


Page 12

Introduction to the Student Data Store (SDS)

The data from the Student Information System (SIS), PowerFaids, Apply Yourself and R25

applications makes up the Student Data Store.

The data in the SDS is used by the following systems and user groups:


SIS Reporting in the Data Warehouse

SIS Reporting from SDR (Student Desktop Reports)

SIS data interfaces to the HR database from the Data Warehouse and is used to populate the

customized subject area database for NSF. Historical SIS data will be available via 'Old FAS

COA'. As of ARC Go-Live, SIS data will then be available with new 'ARC COA'.


Page 13

Components of the Data Architecture

Good data architecture is vital to a reporting system's ability to provide easy to build reports,

extracts, and queries, for the timely loading of data each night (to have reports available each

morning), and for the rapid retrieval of reports. Data architecture includes the following

components:

Logical data model - includes the design of the financial tables and the organization and linkage

of data within the FDS.

Source-to-target data mapping - the process of identifying among the 10's of thousands of

fields in ARC, the data needed for FDS reporting and extracts.

Data movement - all tools and processes needed to accurately move the data on a nightly basis to

the FDS (e.g. the ARC/FDS use of Materialized Views).

Data dictionary (a.k.a. metadata repository) - a collection of the business definition of each table

and field in the FDS. These definitions will be stored in a CUIT metadata repository and made

available to users of the FDS.

Physical data model - the physical implementation of the logical data model in Oracle, including

indexes, surrogate keys, partitioning, cube development, the creation of other database objects,

and changes needed for tuning purposes.

Training Guide


Page 14

FDS Context Diagram

The image below shows the data that flows from ARC Financials database and PAC to the

Financial Data Store (FDS). FDS reports and extracts will then access the data directly from the

FDS.


Page 15

FDS Data Flow

The following diagram shows the data flow from source system inputs into the FDS and finally to

reports, target systems and views:

Training Guide


Page 16

How Secured Views Work

Secured Views in FDS

A data dictionary will be made available to users and interested stakeholders who require a more

complete understanding of the contents of the FDS. The secured views will be implemented using

security tables sourced from ARC to ensure that only authorized users and systems have access to

the data being referenced.

The following diagram shows how the FDS data will be made available to downstream users and

systems by way of secured views:

Role Level Security (a.k.a ChartField Security)


Page 17

FDS Load and Blackout Period

The Load and Blackout Period is a daily period of time, 12 AM - 6:59 AM, when the FDS will be

'Unavailable' to the user community. During this time the FDS will be loaded and refreshed with

current ARC data. The refresh and load process is a two step process. First, data from ARC is

loaded into the FDS Staging environment. In this process the data is loaded and validated for

completeness before moving forward. The second step in the process is the refresh of the FDS

Target environment, which occurs only on successful completion of the FDS Staging load

process. The FDS Target environment contains the FDS Reporting tables. A successful load of

the FDS Target environment will contain a 'day old' data. An unsuccessful load/refresh process of

the FDS will have 'two day old' data available in the FDS Reporting tables. The daily status of the

FDS will be communicated via: ARC Portal, Finance Gateway and Service Now Alerts.

Training Guide


Page 18

FDS Data Content and Usage This is the FDS Data Content and Usage lesson of the Advanced FDS Reporting course. Upon

completion of this lesson, you will be able to:

Define secured views and roles (and service accounts)

Define ChartFields and Trees

Use of Cross Walk in FDS or LDS

Understand the difference between Effective Dating vs Current Dating

Describe the FDS Entity Relationship Diagrams (Data Model)

Describe the GL Tables, GL Summary Tables and Attributes

Describe the Data Dictionary for GL

Describe the Report Data Grid



Page 19

Authentication and Security

Accessing SQL

Training Guide


Page 20

Components of Security

A user's system access is granted for distinct and different aspects of how they will interact with

the system:

Page-level security: Transactions in ARC will occur on various pages (examples: voucher

pages, journal entry pages). Page-level security gives you access to begin or approve those types

of transactions on specific “pages” in ARC. Page-level security also determines whether or not a

user will have access to run ARC inquiries and/or FDS reports. A user must be granted the

CU_ALL_PG_FIN_INQUIRY role to have inquiry/report access.

Business unit & ledger security: Ledger security will give you access to a set of data. Most

users will have access to transact affecting the “Actuals” ledger.

ChartField security (role-based security): ChartField security helps determine what data you

should see within the system and in system-generated reports. Generally, security is set-up so

that you can only see in a report certain data for your department.

If you are a system user, these components will be set up based on your business need and they

will govern what you can and cannot see in ARC.


Page 21

ChartField Security

ChartField Security

Employees granted access to FDS reports will be entered into roles through ARC Financial

windows. Their UNI will be associated with one or more roles, and this role based data will be

sent from the ARC system to the BOXI system in an extract file. Roles will be associated with

BOXI "groups", the groups will be given access to select folders in InfoView.

Training Guide


Page 22

FDS Users (Power Users and Service Accounts)

A service account is an ID granted access to the FDS per application system requirements (e.g.

Facilities, CUMC). A service account can be used by an application group to schedule batch

reports, queries and extracts during the FDS Load and Blackout Period. Completion of FDS

Access Request will be required (see Requesting Access to Query the FDS topic).


Page 23

ChartFields and Trees

All financial ChartFields and associated trees are copied from ARC and included in the FDS.

ChartFields

In the ARC General Ledger application, the fields that make up the chart of accounts and provide

it with an overall structure are called ChartFields. Each transaction is posted to on or more of

these ChartFields that allow the user flexibility to report on their financial information by any of

these designated data groups.

Trees

Trees are used in multiple ARC applications such as General Ledger and Purchasing as well as

for reporting across any ARC application.

A tree is a graphic representation of a hierarchy or reporting structure based on a GL ChartField.

Trees organize and provide a visual summarization of information on the large amount of detailed

data that the application stores.

Trees are very helpful when it comes to reporting. A tree can specify how the data should be

summarized or "rolled-up" for reporting purposes.

These ARC application reporting and security trees get moved to the FDS using materialized

view to utilize these trees for reports and to apply row-level security.

Training Guide


Page 24

ChartField Summary Table

The following table summarizes the eleven ChartFields and the FAS components they are

replacing:

If you would like to print this table, click here.


Page 25

Department Trees

Department Trees

Trees are very powerful and we will show an example here by showing the University’s

Department Tree. There are at least 2,000 detailed department values that could be selected

under the Department ChartField. In order to make sense of this, we have built the Department

Tree for the University that consists of eight levels (or “Tree Nodes”).

As you can see, the Department Tree is a hierarchy. As an organization chart, it would look

something like this (through level 4):

The following image shows how the Department Tree looks in ARC when it is expanded to a

detailed value within Columbia University Medical Center (CUMC):

Training Guide


Page 26


Page 27

COA Crosswalk Tool

A Chart of Accounts (COA) Crosswalk Tool has been developed to help you translate between

FAS accounts (GL/SL) and the new ARC ChartString as well as between FAS sub-code/account

control and ARC accounts.

This Crosswalk Tool will be available from the new ARC Portal: The screenshot below shows

you where to find and access the COA Crosswalk Tool:

Click here (https://forms.finance.columbia.edu/crosswalk/) to access the COA Crosswalk Tool.

The COA Crosswalk Tool has a straightforward interface to translate between FAS and ARC.

https://forms.finance.columbia.edu/crosswalk/

Training Guide


Page 28

Using the Crosswalk Tables in FDS or LDS

ARC conversion functional and technical teams created three tables to map current FAS COA

fields to ARC (PeopleSoft Financial) application COA fields.

These three tables are:

PS_ZCU_FAS_SC_MAP: This table is used to map between FAS sub code/Account

control to ARC account. This table has the following columns.

ZCU_FAS_ACCT_TYPE: To indicate whether it is for FAS “GL” or “SL” type.

ZCU_FAS_SUBCODE: To indicate FAS subcode

ZCU_FAS_REV_SOURCE: To indicate Revenue/Source information.

ZCU_FAS_DEBT_CREDT: To indicate Debit or Credit flag information

ZCU_SUBCODE_DESC: To indicate FAS Subcode descriptions

ACCOUNT: To indicate ARC account information.

ZCU_SC_OVERRIDE: This flag is on then user should refer other table for this FAS

subcode.

PS_ZCU_FAS_ACCT_MAP: This table is used to map between FAS Account to ARC

Chartfields except ARC account.

ZCU_FAS_ACCOUNT: To indicate FAS account information.

ZCU_FAS_ACCT_DESC: To indicate FAS account description.

ZCU_MAP_CODE:

ZCU_FUND_GROUP:

ZCU_FAS_BU : To indicate FAS BU information.

ZCU_FAS_BU_DESC : To indicate FAS BU description

ZCU_FAS_MU: To indicate FAS MU information.

ZCU_FAS_MU_DESC : To indicate FAS MU Description

ZCU_FAS_DEPT: To indicate FAS Department.

ZCU_FAS_DEPT_DESC : Indicate FAS Department Description.

ZCU_FAS_SUB_DEPT : Indicate FAS sub department

ZCU_SUB_SUB_DEPT : Indicate FAS sub sub department.


ZCU_REVSOURCE_DESC: To indicate Revenue Source description.

ZCU_FAS_EXP_CAT_CD:

ZCU_EXP_CAT_DESC:

ZCU_RESP_PERSON_1

BUSINESS_UNIT : To indicate ARC business Unit

FUND_CODE: To indicate ARC fund code.

DEPTID: To indicate ARC Department.

BUSINESS_UNIT_PC: To indicate ARC PC business unit.

PROJECT_ID: To indicate ARC project id.

ACTIVITY_ID: To indicate ARC Activity Id

PROGRAM_CODE: To indicate ARC Initiative value.

CHARTFIELD1: To indicate ARC Segment value.

CHARTFIELD2: To indicate ARC Site value.

CLASS_FLD: To indicate ARC Function value.

ZCU_BLDG

ZCU_DELETE_FLAG


Page 29

ZCU_FAS_NAV

ZCU_FAS_POOL_SET

ZCU_FAS_SHARES

ZCU_FREEZE_FLAG

ZCU_FY_ACCOUNT

ZCU_COA_STAT_XLAT

DUE_DATE

COMMENT1

OPRID

ENTERED_DTTM

LASTUPDDTTM

PS_ZCU_FAS_ACCT_MAP: This table is used to map from FAS COA fields ( FAS

Account, FAS subcode) to ARC all Chartfields if override flag is on any FAS account

value in PS_ZCU_FAS_ACCT_MAP table.

ZCU_FAS_ACCT_TYPE: To indicate whether it is for FAS “GL” or “SL” type.

ZCU_FAS_SUBCODE: To indicate FAS subcode


ZCU_FAS_DEBT_CREDT: To indicate Debit or Credit flag information

ZCU_FAS_ACCOUNT: To indicate FAS account information.

BUSINESS_UNIT: To indicate ARC business unit value.

ACCOUNT: To indicate ARC account value.

DEPTID: To indicate ARC department value.

FUND_CODE: To indicate ARC fund code value.

BUSINESS_UNIT_PC: To indicate ARC PC business unit value.

PROJECT_ID: To indicate ARC project id value.

ACTIVITY_ID: To indicate ARC activity id value.

PROGRAM_CODE: To indicate ARC Initiative value.

CHARTFIELD1: To indicate ARC Segment value.

CHARTFIELD2: To indicate ARC Site value.

CLASS_FLD: To indicate ARC Function value.

Training Guide


Page 30

Effective Dating versus Current Dating

Effective Dating

Effective Dating on setup/configuration data (e.g. ChartFields, tree definitions, etc.,) is one of the

key features for PeopleSoft application systems (ARC and PAC). It enables to maintain and view

a complete chronological record of historical, current and future data.

When entering setup data on PeopleSoft application pages that include an Effective Date field,

the existing data is not replaced. Instead, a new data row is created by specifying the date the data

goes into effect: an Effective Date. By default, when a new data row is created, today’s date

enters as the Effective Date. It is possible to ‘future date’ information in order to enter it before it

actually goes into effect. For example, if you know a vendor’s address will change from the

current mailing address to a new address in October 2012, rather than replace the existing data,

simply create a new data row, apply a future Effective Date and the new mailing address will

become active and available on the specified date.

There are three categories of effective-dated records:

Future - All rows that have an effective date greater than today.

Current -The row with the effective date closest to, but not greater than, today. It is the row the

system recognizes as the "current active" row.

History - All rows with an effective date less than the effective date on the current row.

When the date of a future row arrives, it becomes the current row. What was the current row then

becomes history.

ARC effective dated setup data gets pulled into FDS on a nightly basis. Users should apply

effective dated logic in their select statements to avoid incorrect data results.


Page 31

Example

Example 1. User wants to select ledger data with latest description as of today for department

0010000.

The first select SQL statement produces the wrong result. It contains three times the rows than

expected because the department setup table has three rows for department 0010000.

Select A.business_unit, A.Fiscal_Year, A.accounting_period, b.deptid, b.descr,

a.posted_amount

From fds_ledger_sec_vw A, ps_dept_tbl B

Where A.deptid=B.deptid

And B.setid = ‘CUSET’

And B.deptid=’0010000’;

The corrected and ‘effective dated’ query returns the expected result by restricting department

description selection ‘as of today’.


a.posted_amount

From fds_ledger_sec_vw A, ps_dept_tbl B



And B.deptid=’0010000’

And B.effdt = (select max(c.effdt) from ps_dept_tbl C

where C.setid=B.setid

and C.deptid=B.deptid

and C.effdt <=sysdate);

Training Guide


Page 32

PS Department Table Definition

PS (PeopleSoft) Department Table Definition (must use ‘effective’ date).

PS_DEPT_TBL

DEPTID

SETID

EFFDT

EFF_STATUS

DESCR

DESCRSHORT

COMPANY

SETID_LOCATION

LOCATION

TAX_LOCATION_CD

MANAGER_ID

MANAGER_POSN

BUDGET_YR_END_DT

BUDGET_LVL

GL_EXPENSE

EEO4_FUNCTION

CAN_IND_SECTOR

ACCIDENT_INS

SI_ACCIDENT_NUM

HAZARD

ESTABID

RISKCD

GVT_DESCR40

GVT_SUB_AGENCY

GVT_PAR_LINE2

GVT_PAR_LINE3

GVT_PAR_LINE4

GVT_PAR_LINE5

GVT_PAR_DESCR2

GVT_PAR_DESCR3

GVT_PAR_DESCR4

GVT_PAR_DESCR5

CLASS_UNIT_NZL

ORG_UNIT_AUS

WORK_SECTOR_AUS

APS_AGENT_CD_AUS

IND_COMMITTEE_BEL

NACE_CD_BEL

FTE_EDIT_INDC

DEPT_TENURE_FLG

TL_DISTRIB_INFO

USE_BUDGETS

USE_ENCUMBRANCES

USE_DISTRIBUTION

BUDGET_DEPTID


Page 33

DIST_PRORATE_OPTN

HP_STATS_DEPT_CD

HP_STATS_FACULTY

MANAGER_NAME

ACCOUNTING_OWNER

COUNTRY_GRP

BUDGETARY_ONLY

SYNCID

SYNCDTTM

DESCRLONG

Training Guide


Page 34

Current Dating

The FDS creates ‘Current’ ChartField tables on a nightly basis in order to facilitate queries for

‘Current’ ChartField information. Using FDS ‘Current’ tables, the query can be written as

follows:


a.posted_amount

From fds_ledger_sec_vw A, fds_dept_cur_tbl B



And B.deptid=’0010000’;


Page 35

FDS Department Table Definition

FDS ‘Current’ Department Table Definition

FDS_DEPT_CUR_TBL DEPTID

SETID

DESCR

DESCRSHORT

MANAGER_NAME

Click here to open the Department Tree Flatten File.

Training Guide


Page 36

FDS Entity Relationship Diagrams (GL Data Model)

Entity Relationship Diagrams illustrate the logical structure of objects (eg. Databases). It

describes the requirements and data assumptions in the system from a top down perspective.

There are three basic elements in ER models:

1. Entities are the "things" about which we seek information (nouns in the system).

2. Attributes are the data we collect about the entities.

3. Relationships provide the structure needed to draw information from multiple entities

(verbs in the system).

Click here (https://pshome.cuit.columbia.edu/PWA/finerp/default.aspx) to access the FIN ERP

Sharepoint folder.

https://pshome.cuit.columbia.edu/PWA/finerp/default.aspx


Page 37

GL Ledger Data

GL Ledger Data

For a pdf version of this image click here.

Training Guide


Page 38

GL Summary Tables and Views

GL Summary Tables and Views



Page 39

GL Ledger with Current ChartField Descriptions

GL Ledger With Current ChartField Descriptions


Training Guide


Page 40

GL Secured Views

GL Secured Views


Click here to access the Security Role Job Aid.


Page 41

Data Dictionary (GL)

The data dictionary, aka, metadata, is a central repository for the descriptive information about

the ‘system data’. It contains detailed information on the content, format and structure of each

data element in the system. It can also indicate which applications use the data so that when a

change in a data structure is contemplated, a list of affected programs/systems can be generated.

Some data dictionaries also provide authorization for access of each data element in the database.

Training Guide


Page 42

Entities

Entities

Click here to access the complete list of entities.


Page 43

Entity Views

Entity Views

Click here to access the complete list of entity views.

Training Guide


Page 44

Attribute Definitions

Attribute Definitions

Click here to access the complete list of attribute definitions.


Page 45

Attributes

Attributes

Click here to access the complete list of attributes.

Training Guide


Page 46

Report Data Grid

Report Grid

Click here to access the Report Data Grid job aid.


Page 47

FDS Connectivity This is the FDS Connectivity lesson of the Advanced FDS Reporting course. Upon completion of

this lesson, you will be able to:

Request access to query the FDS


Training Guide


Page 48

Access Request Form

To gain access to FDS the following criteria must be met:

Prerequisites course requirements must be completed

Manager approval must be granted

FDS Security Request Form must be submitted

Click here to access the FDS Security Request form.


Page 49

Requesting Access to Query the FDS

A valid business justification will be required for access to query the FDS. Also, various

prerequisite ARC training and SQL proficiency is needed.

The following diagram shows the current ‘Manual’ process flow which will be in place until later

2012.

Training Guide


Page 50

Final Steps

Below are the final steps required to obtain access to the FDS:

FDS Security Request Form submitted and approved

CUIT Support

o Ensure Ad-hoc user prerequisites have been completed

o User/Application ID set-up

o Software verification (Oracle drivers, etc.,)

o Hardware verification (Minimum PC requirements are met)

Click here to access the PC and Web Browser requirements job aid.


Page 51

Tools

Enterprise Business Intelligence Solutions (EBIS) must approve of the query or reporting tool

that is used to access the FDS. CUIT seeks to protect the user’s investment, as well as to put the

user on a path compatible with the overall technology direction of CUIT.

Examples of acceptable query and reporting tools and connection methods:

ODBC or Oracle Client

MS Access

Crystal Reports

The CUIT Standard, Webi, is a query and analysis tool available from CUIT’s enterprise

reporting platform called Business Objects. Business Objects provides a complete suite of

Business Intelligence (BI) tools for standard reporting, dashboards and scorecards, and Universe

development. Various ARC/FDS reports are deployed on this platform. Contact

[email protected] (mailto:[email protected]) for more information.

mailto:[email protected]

Training Guide


Page 52

Course References Please find links to all of the Job Aids, Policies, and Procedures that were referenced throughout

this course:

Job Aid: Getting Started With the Web-Based Tool

Job Aid: Department Tree Flatten File

Job Aid: GL Ledger Data

Job Aid: GL Summary Tables and Views

Job Aid: GL Ledger with ChartField Descriptions

Job Aid: Secured Views

Job Aid: Security Role

Job Aid: Attributes

Job Aid: Entity Description

Job Aid: Report Data Grid

Job Aid: FDS Security Request Form

Job Aid: PC and Web Browser Requirements for Reporting

Advanced FDS Reporting Training Guide

Enterprise Business Intelligence Solutions (EBIS) website

(http://enterprisereporting.cuit.columbia.edu/)

http://enterprisereporting.cuit.columbia.edu/


Page 53

Knowledge Assessment If you are taking this course to obtain security access to one of Columbia University’s Financial

Systems, please ensure you have completed the following:

1. Security Application Request: All security roles must be requested by the user through

the Columbia University Financial Systems Security Application which can be found in

the Service Catalog of ServiceNow (https://columbiadev.service-now.com/navpage.do

(https://columbiadev.service-now.com/navpage.do)). Note: All security roles must be

approved by both the user’s manager and Department Security Administrator (DSA) for

the School/Admin Unit to which access is being requested.

2. Training Requirements: Security access will only be granted once all training

requirements have been fulfilled. After a user has reviewed all of the applicable training

material for a particular role, users must complete the Knowledge Assessment associated

with that training course with a score of 90% or higher. The Knowledge Assessments

can be found in New CourseWorks,

(https://newcourseworks.columbia.edu/portal/site/Finance_Training

(https://newcourseworks.columbia.edu/portal/site/Finance_Training)). If you have any

questions about the training required for any security role, click here (http://gateway-

7.webservices.lamptest.columbia.edu/files/gateway/content/training/job_aids/Job_Aid_R

ole_to_Course_Directory.pdf) for the Role to Course Directory job aid.

If you are taking this course for information purposes only, i.e., you are not requesting a security

role, no Knowledge Assessment is required.

https://columbiadev.service-now.com/navpage.do

https://newcourseworks.columbia.edu/portal/site/Finance_Training

http://gateway-7.webservices.lamptest.columbia.edu/files/gateway/content/training/job_aids/Job_Aid_Role_to_Course_Directory.pdf



Training Guide


Page 54

Glossary ARC Accounting and Reporting at Columbia. Columbia University's new financial

system.

Chart of

Accounts Columbia's Chart of Accounts is comprised of 11 ChartFields that are used to

organize and record financial activity at the University.

ChartFields The fields that make Columbia's Chart of Accounts and provide it with an

overall structure. ARC has a total of eleven ChartFields which are recorded

on every transaction.

ChartString The combination of ChartFields and the level at which accounting charges

and credits are applied.

Commitment

Control Functionality in ARC that enables users to manage expenditures actively

against predefined, authorized budgets. An example is budget checking.

Crosswalk The translation of a legacy value to a PeopleSoft value.

ERP Enterprise resource planning. ERP refers to a category of business software

that is designed to integrate functions across an organization into a single

computer system.

FAS Financial Accounting System - the University’s existing accounting system

that will be replaced by the FIN ERP solution in July 2012.

Field An area on a page that displays or requires data.

Financial Data

Store Columbia's new financial data warehouse. (Previously referred to as ODS --

Operational Data Store).

General Ledger The ‘Book of Record’ which holds all financial transactions in detail or

summary and is used for financial reporting and financial management.

Inquiries Online search engine used to view data on a real-time basis within ARC, not

intended for printing/formatting.

Journal Entry The recording of financial data pertaining to business transactions in a journal

such that the debits equal credits.

Nodes Nodes define the hierarchical relationship within the tree. Nodes can be either

categories (as in a group of assets) or items that need to be placed in a

relationship with other items, such as an item in a catalog.

PeopleSoft Oracle's PeopleSoft system is an integrated software package that provides a

wide variety of business applications to assist in the day-to-day execution and

operation of business processes. Each individual application, such as

Financial's and Human Resources, interacts with each other to offer an

effective and efficient means of working and reporting in an integrated

fashion across the enterprise.

ARC and PeopleSoft are used interchangeably when referring to Columbia's

new financial system.

Project Associates expenses with a specific funding source.

Purchase Order Based on a request by a Department indicating good/service, catalog number,

price and quantity. When accepted by a supplier, a purchase order forms a

binding contract.

Queries A request against the ARC, ARC Reporting, or UDS database to obtain a set

of data that match a specified search criteria.

Security Controls what level of access a user can have to pages, dollar thresholds,


Page 55

data, and allowable actions in the system. Security ensures that users have the

appropriate page access and access to data required to perform their job

functions.

Trees Trees are used to organize ChartField data into hierarchies which can be used

for security, reporting and managing organizational structure.

University Data

Store The new data warehouse repository (UDS). The place where data from ARC,

HR / Labor Accounting, Student, and Historical / Legacy system data will be

stored.

Documents

Advanced FDS Reporting Training Guide