people soft

BusinessObjects PeopleSoft General Ledger Rapid Mart User’s Guide

Version 11.5

Patents Business Objects owns the following U.S. patents, which may cover products that are offered and sold by Business Objects: 5,555,403, 6,247,008 B1, 6,578,027 B2, 6,490,593 and 6,289,352.

Trademarks Business Objects, the Business Objects logo, Crystal Reports, and Crystal Enterprise are trademarks or registered trademarks of Business Objects SA or its affiliated companies in the United States and other countries. All other names mentioned herein may be trademarks of their respective owners.

Copyright Copyright © 2005 Business Objects. All rights reserved.

Contents
Chapter 1 Introduction 9
What is a Rapid Mart? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Rapid Marts Accelerate Time to Value . . . . . . . . . . . . . . . . . . . . . . . . 10BusinessObjects Rapid Mart architecture . . . . . . . . . . . . . . . . . . . . . . 11

About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 2 Overview 13Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14What you can do with this Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Supported analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Related Rapid Marts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Sharing components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Rapid Mart schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Where the Rapid Mart fits in General Ledger Accounting Cycle . . . . . . . . 19

Chapter 3 Subject Areas 21Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Journal Entry section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

PeopleSoft processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Rapid Mart processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Rapid Mart data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Fact table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

General Ledger Balances section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28PeopleSoft processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Rapid Mart processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Rapid Mart data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Fact table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

BusinessObjects PeopleSoft General Ledger Rapid Mart User’s Guide 3

Contents

Budgeting section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32PeopleSoft processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Rapid Mart processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Rapid Mart data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Fact table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 4 Reports 39Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Journal Entry section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Journal Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Recommended table joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42GL Balances section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Asset Account Trial Balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Period Net Activity Drill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Actuals Profit and Loss Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Recommended table joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Budgets section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Actual V Budget Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Budget Profit and Loss Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Recommended table joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapter 5 Installing the Rapid Mart 57Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58System prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Rapid Mart product components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Preparing your environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Installation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Installation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Completing the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 BusinessObjects PeopleSoft General Ledger Rapid Mart User’s Guide

Contents

Installing Rapid Mart Reporting Content . . . . . . . . . . . . . . . . . . . . . . . . . . 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapter 6 Using the Rapid Mart 69Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Recovery framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Data Integrator automatic recovery feature . . . . . . . . . . . . . . . . . . . . . 70Rapid Mart recovery framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Execution status framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72The execution status table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

How job status is maintained . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72The execution status API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Executing a job with the reset option . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Extraction, transformation and loading process . . . . . . . . . . . . . . . . . . . . . 74Batch configuration variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Executing the jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Customizing the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Chapter 7 Technical Implementation 83Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Journal Entry section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Initial load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Dimension table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Fact table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Incremental load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Load dimension tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Load fact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

GL Balance section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Initial load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Dimension table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95


Contents

Fact table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Incremental load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Load dimension tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Load fact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Budget section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Initial load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Dimension table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Fact table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Incremental load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Load dimension tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Load fact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Dealing with NULL values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Fact table stored procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Appendix A Rapid Mart Data Schema 111Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Fact tables in the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Dimension tables in the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Other tables in the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113ACCOUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113ACCOUNT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114ACCOUNT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116ACCOUNT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117ACCOUNT_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118AFFILIATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119ALTACCOUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119ALTACCOUNT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120ALTACCOUNT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122ALTACCOUNT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123AW_JOBEXECUTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124BUDGET_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124


Contents

BUSINESS_UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126COMPANY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126CURRENCY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127DEPARTMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127DEPARTMENT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128DEPARTMENT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131DEPARTMENT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131FISCAL_CALENDAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132JOURNAL_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133LEDGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135LEDGER_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135MONTH_DIMENSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137OPERATING_UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137OPERATING_UNIT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138OPERATING_UNIT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140OPERATING_UNIT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141PRODUCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142PRODUCT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142PRODUCT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144PRODUCT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145PROJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146SCENARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147STAGE_BUDGET_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148STAGE_JOURNAL_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149STAGE_LEDGER_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150STATISTIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151TEMP_DEPARTMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152TIME_DIMENSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152


Contents



Introduction

chapter

IntroductionWhat is a Rapid Mart?1
What is a Rapid Mart?
BusinessObjects™ Rapid Marts provide packaged extraction of operational data to accelerate the deployment of business intelligence (BI). They are add-on products to BusinessObjects™ Data Integrator that combine domain knowledge with data integration best practices to deliver pre-built data models, transformation logic, and data flows for extracting data from enterprise applications from SAP, PeopleSoft, Oracle, J. D. Edwards, Siebel and Salesforce.com.Rapid Marts deliver pre-packaged business content and data flows in a single data platform optimized for BI and analytic applications. Rapid Marts enable business users to report on and gain insight into their enterprise information. Most include prebuilt Business Objects reports and universes that deliver domain knowledge on operational systems.BI tools and analytic tools can access Rapid Mart data directly through SQL queries or indirectly through a Data Integrator RealTime request-response system. Rapid Marts can be implemented individually, or in any combination, to form a single platform that delivers the infrastructure for your company’s internal and external information needs. They can also serve as a staging area for enterprise analytic applications.Rapid Marts provide IT with an accelerated time to value through rapid BI deployments because you can implement them quickly and easily customize them to meet specific analytic requirement.

Rapid Marts Accelerate Time to ValueRapid Marts are packaged data solutions that you can quickly deploy to address specific areas of business analysis. Available Rapid Marts include:• BusinessObjects Sales Rapid Mart• BusinessObjects Cost Center Rapid Mart• BusinessObjects Profitability Rapid Mart• BusinessObjects General Ledger Rapid Mart• BusinessObjects Accounts Receivable Rapid Mart• BusinessObjects Accounts Payable Rapid Mart• BusinessObjects Federal Financials Rapid Mart• BusinessObjects Fixed Assets Rapid Mart• BusinessObjects Purchasing Rapid Mart• BusinessObjects Inventory Rapid Mart


IntroductionAbout this document 1

• BusinessObjects Plant Maintenance Rapid Mart• BusinessObjects HR Rapid Mart• BusinessObjects Production Planning Rapid Mart• BusinessObjects Project Systems Rapid Mart• BusinessObjects Pipeline Rapid Mart• BusinessObjects Call Center Rapid Mart• BusinessObjects Campaign Rapid MartYou can combine multiple Rapid Marts into a single environment to build the foundation for your data warehouse or use them as a staging area for BusinessObjects Analytic Applications.

BusinessObjects Rapid Mart architectureRapid Marts provide a powerful jumpstart for building source-specific data marts for operational reporting and packaged data integration for enterprise analytic applications. The following diagram shows where Rapid Marts fit in the deployemt of business intelligence process:

About this documentThis document describes the BusinessObjects General Ledger Rapid Mart for PeopleSoft. This document contains information for a variety of users—information that helps you understand the use of the Rapid Mart, the data in the Rapid Mart, the queries you can answer with the Rapid Mart, and how to run, update, and maintain the Rapid Mart.


IntroductionAbout this document1

This document contains the following chapters:• Chapter 2: Overview — Describes the business problems you can solve

and the types of analyses you can do with this Rapid Mart• Chapter 3: Subject Areas — Contains detailed information about each

section that is part of the batch extraction in the Rapid Mart, including the processes each section captures

• Chapter 4: Reports — Provides examples of reports you can produce• Chapter 5: Installing the Rapid Mart — Contains the information you need

to install the Rapid Mart• Chapter 6: Using the Rapid Mart —Describes how to execute the Rapid

Mart, including information about initializing variables and what you need to consider when customizing the Rapid Mart

• Chapter 7: Technical Implementation —Describes each section and the work flows that run to load that section

• Appendix A: Rapid Mart Data Schema — Contains a detailed list of the tables and views in the Rapid Mart


Overview

chapter

OverviewOverview2
Overview
This chapter describes the business problems you can solve with the BusinessObjects PeopleSoft General Ledger Rapid Mart and the types of analyses you can do with this Rapid Mart. The information in this chapter is useful for those who want a business-level overview of the Rapid Mart and its benefits. This chapter contains the following sections:• What you can do with this Rapid Mart• Supported analyses• Related Rapid Marts• Rapid Mart schema• Where the Rapid Mart fits in General Ledger Accounting Cycle

What you can do with this Rapid MartThe BusinessObjects PeopleSoft General Ledger Rapid Mart supports analysis of data in the General Ledger module of PeopleSoft. The PeopleSoft General Ledger module helps to manage financial reporting for an organization. The General Ledger provides an accurate and cost-effective way of organizing, maintaining, recording, and analyzing financial information. This information, whether gathered from one site or multiple sites around the world, provides streamlined transaction processing for timely analysis and ease of reporting. It allows users to review, analyze, evaluate, and control the key financial results and activities of the company. Using this Rapid Mart, you can: • Create and analyze financial statements• View multiple budget versions• Review financial and operational results throughout the fiscal year drilling

down to accounting transaction level• Investigate variances between actual, budgeted and forecasted amounts• Perform Ad hoc financial analysis• Enable analysis of Cost and Project accounting• Perform audit and control analysis


OverviewWhat you can do with this Rapid Mart 2

The Rapid Mart addresses the following three sub-modules:• Journal Entries• General Ledger Balances• BudgetingWith this Rapid Mart, you can answer the following kinds of questions:• How are the actual expenses compared to the budget?• What is the revenue by a specified product or operating unit or territory?• Which cost centers have overspent their budgets last quarter?• What were the capital expenditures last quarter in comparison with the

same quarter last year?• Which business units are currently under-performing from a profitability

point of view?The BusinessObjects PeopleSoft General Ledger Rapid Mart is made up of several sections. Each section supports a subject related to analysis of financial information:• Journal Entry section — Contains journal entries posted manually and

imported from other sub-modules, such as accounts payables and accounts receivables.

• General Ledger Balances section — Stores period-end snapshots of the company’s assets, liabilities, and capital structure position in the form of posted journal entries.

• Budgeting section — If PeopleSoft budgeting has been employed actual and budget values can be stored and compared.

Chapter 3: Subject Areas discusses each of these sections in more detail.


OverviewSupported analyses2
Supported analyses
The BusinessObjects PeopleSoft General Ledger Rapid Mart supports several types of analyses.

Business function Types of analysis Measures available in the Rapid Mart

Journal Entry Financial Accounting • Account analysis• Analysis of expenses/revenues by

Cost Center, Project, Product, Account, Operating Unit and Territory.

• Profitability analysis• Time Period comparisons such as

this year vs. last yearGL Balances Balance • Analyses of Balance Sheets

• Reporting on actual and statistical amounts posted to General Ledger

• Intercompany transaction detailsVariance Analysis • Actual vs. Budget amounts

comparison for the same or different accounting periods

• Actual vs. Actual amounts for different accounting periods

Budgeting Budget • Reporitng on actual and budgeted amounts posted to General Ledger


OverviewRelated Rapid Marts 2

Related Rapid MartsEach Rapid Mart is composed of multiple components. A component is a stand-alone work flow that completes a particular task, such as loading a specific dimension table. Components can contain other components. A section is a set of components that address a particular business problem or subject area. A section is itself a component.The BusinessObjects PeopleSoft General Ledger Rapid Mart shares some components with the PeopleSoft Human Resources Rapid Mart.• Common dimensions are an example of component sharing between

Rapid Marts. The Department, Currency, Company, Calendar, time dimensions and to some extent Business Unit are components that are also included as part of the Human Resources Rapid Mart.

Sharing components The same components can be used in multiple Rapid Marts. For example, a component that extracts information about materials bought, produced, and sold is needed for a Rapid Mart that supports sales analysis and also for a Rapid Mart that supports inventory analysis. Work flows that extract star schema “dimensions” are components. You can add a component to any Rapid Mart using a simple import procedure. A Data Integrator job can include multiple instances of a component. For example, each section includes all the required dimension components. Therefore, a job with several sections may include several instances of a particular dimension component. Components are set to execute only once within a job. This “execute once” feature ensures that shared components do not cause duplicate data extraction from PeopleSoft. For more information about the “execute once” feature, see the Data Integrator Designer Guide.Each of the sections listed in “What you can do with this Rapid Mart” on page 14 is considered a component. You can identify a component within a Data Integrator job by a “C_” prefix before its name. For example, the component that contains sales order and the associated reporting dimensions is named C_JournalEntry_Section_PSF.


OverviewRapid Mart schema2
Rapid Mart schema
The following diagram shows the tables in the BusinessObjects PeopleSoft General Ledger Rapid Mart. The larger boxes contain the fact tables corresponding to componentized sections; the smaller boxes indicate dimensional components that may apply to multiple sections.


OverviewWhere the Rapid Mart fits in General Ledger Accounting Cycle 2

Where the Rapid Mart fits in General Ledger Accounting Cycle

The General Ledger Accounting Cycle is part of the PeopleSoft Financials suite. Its purpose is to enter, maintain, and report on actual accounting information for the enterprise.

The General Ledger accounting cycle consists of the following elements:• Opening of an accounting period• Entering journal entries manually or importing them from subledgers

(such as Accounts Receivables, Accounts Payables, Global Intercompany System, etc.)

• Reviewing and editing of unposted journal entries until posting is complete.. Balances are updated automatically

• Translating of actual account balances to any foreign currency for reporting purposes

• Reveiwing current account balances• Producing financial reports• Closing the current accounting periodThe BusinessObjects PeopleSoft General Ledger Rapid Mart addresses all the analysis of the transactions posted to the General Ledger.


OverviewWhere the Rapid Mart fits in General Ledger Accounting Cycle2


Subject Areas

chapter

Subject AreasOverview3
Overview
Each section in the BusinessObjects PeopleSoft General Ledger Rapid Mart pertains to a particular subject area. This chapter describes each section and the processes each section captures. The information in this chapter is useful for readers who use the Rapid Mart and need to understand the data in the Rapid Mart and how it relates to PeopleSoft.This chapter discusses: • Journal Entry section• General Ledger Balances section• Budgeting section

Journal Entry sectionGeneral Ledger contains financial transactions posted manually and imported from various modules of the PeopleSoft such as Accounts Receivables, Accounts Payables, Fixed Assets, Project Systems, Inventory, and so forth.The BusinessObjects PeopleSoft General Ledger Rapid Mart extracts data from Journal Entry related tables in PeopleSoft. The Journal Entry section is a comprehensive source for information related to actual financial transactions posted to the General Ledger.

PeopleSoft processingThe Journal Entry sub-module is a part of the PeopleSoft General Ledger Accounting Cycle. Journal Entry has the following features:• Journal Batches - organize journal entries with common attributes. All

journal entries in a batch share the same fiscal period. When a journal entry is entered directly, a batch for the entry will be created automatically.

• Journal Approval - the approval process obtains the necessary management approvals for manual journal batches. The process validates the journal batch, determines if approval is required, submits the batch to approvers (if required), then notifies appropriate individuals of the approval results (‘Approval Not Required’, ‘Approved’, ‘Rejected’, ‘Validation Failed’).

• Recurring Journals - transactions that are repeated every accounting period, such as accruals, depreciation charges, and allocations.


Subject AreasJournal Entry section 3

• Journal Import - allows to integrate information from other PeopleSoft such as payroll, accounts receivable, accounts payable and fixed assets. For each accounting period, accounting data from these feeder systems can be imported, then reviewed, updated and posted the journal entries. Data can be imported from multiple interface tables. Each particular source/group ID combination will only have data in one interface table at a time. Journal import will process data from one table at a time.

• Posting Journals - posting is processed by batches in the Scheduler. The posting process updates relevant account balances.

• Reversing Journals - used to reverse a journal, a journal batch, accruals, estimates, errors, or temporary adjustment and reclassifications.

• Year-End Closing Journals - Many organizations follow specific procedures to generate special journal entries to close and open fiscal years. These closing entries apply to both the income statement and balance sheet. Auditable closing procedures vary considerably, depending on country reporting requirements, generally accepted accounting practices in a country, and organization business needs.

Rapid Mart processingThe Journal Entry section extracts data from journal entry header and line item PeopleSoft transactional tables. The section stores actual transactions posted to the general ledger in a fact table JOURNAL_FACT.


Subject AreasJournal Entry section3
Rapid Mart data
The following diagram shows tables that the Journal Entry section extracts.

Fact table columnsThe JOURNAL_FACT table contains transaction amounts related to financial transactions posted to the General Ledger and a few journal and journal line attributes. Only transactions of status ‘posted’ are selected. The columns in the table are described below.• BUSINESS_UNIT_KEY

Identifies the legal entity business unit to which the journal relates. This column holds the surrogate key reference to the business unit dimension.

• JOURNAL_ID, JOURNAL_DATE, JOURNAL_LINEJOURNAL_ID is an internal identifier assigned to a particular journal by PeopleSoft and JOURNAL_DATE is the date when it was posted. JOURNAL_LINE specifies which line of the journal a transaction record occured on.



• UNPOST_SEQJournal unpost sequence number

• LEDGER_KEYThe name of the ledger that journal entry transactions have been assigned to. This column holds the surrogate key reference to the ledger dimension

• ACCOUNT_KEYThe name of the account a journal entry has been posted against. This column holds the surrogate key reference to the account dimension

• ALTACCOUNT_KEYThe name of the alternate account a journal entry has been posted against. PeopleSoft does not mandate alternate accounts to be used. This column holds the surrogate key reference to the alternate account dimension.DEPARTMENT_KEY, OPERATING_UNIT_KEYThe name of the department and operating unit that a journal has been posted against. PeopleSoft does not mandate either of these columns to be used. The columns hold the surrogate key references to the department and operating unit dimensions.

• PRODUCT_KEY, PROJECT_KEYThe name of the product and project that a journal has been posted against. PeopleSoft does not mandate either of these columns to be used. The columns hold the surrogate key references to the product and project dimensions.

• AFFILIATE_KEYThere are two ways that intercompany transactions can be recorded. Affiliate codes can be used to identify the parties involved in the transaction or specific account codes can be defined that signify intercompany transactions and identify the participating companies. The AFFILIATE_KEY column holds the surrogate key reference to the affiliate dimension.

• SCENARIO_KEYSpecifies which data scenario a transaction is associated with.The SCENARIO_KEY column holds the surrogate key reference to the scenario dimension.


Subject AreasJournal Entry section3

• CURRENCY_KEYSpecifies which currency is held against the transaction amounts contained in the journal. The CURRENCY_KEY column holds the surrogate key reference to the currency dimension.

• STATISTICS_KEYIndicates whether the journal entry is a statistical amount (i.e. floorspace, headcount etc) This column holds the surrogate key reference to the statistics dimension

• SOURCE_KEYSpecifies the source of the journal record. This column holds the surrogate key reference to the source dimension.

• COMPANY_KEYSpecifies to which company the journal pertains. Company is mapped to department using a company lookup in the department source table. This column holds the surrogate key reference to the company dimension

• ACCOUNT_TYPE_KEYSpecifies the type of acount (Revenue, Asset, Expense, Liability, Equity etc) that the transaction is made against. This column holds the surrogate key reference to the account type dimension.

• TIME_KEYThis is a smart key reference that can be used to associate the DAY field in TIME_DIMENSION with the journal date.

• JRNL_LN_REF, LINE_DESCRThese columns can be used for journal descriptions such as invoice or purchase order references and field references.

• JRNL_LINE_STATUSContains a 1 or 0 depending upon whether the journal entry is valid (0) or in error (1).

• FOREIGN_CURRENCYBase currency of the transaction.

• RT_TYPETransaction rate type

• FOREIGN_AMOUNTTransaction Amount held in local currency



• FISCAL YEAR, ACCOUNTING PERIODThe accounting period and fiscal year into which the journal entry posted date falls.

• JRNL_EDIT_ERR_STATFailed journals will contain an error status that indicates what error occured. Valid journals will contain ‘Valid - No Edit Errors’.

• JRNL_HDR_STATUSThe status of the journal as indicated by the journal header record.

• LOAD_DATE, LOAD_TIMEThe Rapid Mart populates these fields with the date and time of the start of the data extraction from PeopleSoft. For Oracle, the Rapid Mart stores the date as a string in the format of 'YYYY.MM.DD HH24:MI:SS'. For other target databases, the Rapid Mart stores the date as a string in the 'YYYY.MM.DD' format. Similarly, the Rapid Mart stores the time in an 8-character string appropriate for your target database. LOAD_DATE and LOAD_TIME can be helpful when using the fact tables in other applications for further data manipulation.

AnalysisWith the tables in this section, you can analyze journal entries along several dimensions:• By department and associated hierarchies (account, alternate account,

department, operating unit and product)• By ledger category and source• By journal batch• By time period vs. previous period, year vs. previous yearTypical queries include:• Which business division is under-performing at the net income level?• Which products are the most profitable this year? • Why is return on equity/assets deteriorating?• What were the levels of returns after year end compared to average?• Did any cost centers experience a greater than 50% increase in total

postings?• Were there any large releases or reserves or additions to suspense

accounts before year end?


Subject AreasGeneral Ledger Balances section3
General Ledger Balances section
The General ledger contains all the financial transactions posted from various modules of PeopleSoft such as Accounts Receivables, Account Payables Fixed Assets and so forth.PeopleSoft automatically update its balance transactional table when a posting to the general ledger occurs.

PeopleSoft processingActual account balances are stored by PeopleSoft in the PS_LEDGER table. The PeopleSoft Scheduler creates or updates records in this table for a given accounting period. The records created or updated store the initial balance, period net debit, and period net credit in the translated currency for each account that has balances in the period. PS_LEDGER stores functional currency, foreign currency, and statistical balances. It additionally stores activity amounts alongside actual balance.s.The General Ledger module allows pre–expenditures to be recorded commonly known as encumbrances. The primary purpose of tracking encumbrances is to avoid overspending a budget.

Rapid Mart processingThe Balances section extracts balances from the PS_LEDGER PeopleSoft transactional table. The section stores the balance data in the LEDGER_FACT fact table.


Subject AreasGeneral Ledger Balances section 3

Rapid Mart dataThe following diagram shows tables for the GL Balances section.

Fact table columnsThe LEDGER_FACT table contains the transaction amounts related to the financial transactions posted to the General Ledger. The columns in the table are described below.• BUSINESS_UNIT_KEY

Identifies the legal entity business unit to which the balance transaction relates. This column holds the surrogate key reference to the business unit dimension.

• LEDGER_KEYThe name of the ledger that balance transactions have been assigned to. This column holds the surrogate key reference to the ledger dimension

• ACCOUNT_KEYThe name of the account a balance transaction has been posted against. This column holds the surrogate key reference to the account dimension


Subject AreasGeneral Ledger Balances section3

• ALTACCOUNT_KEYThe name of the alternate account a balance transaction has been posted against. PeopleSoft does not mandate alternate accounts to be used. This column holds the surrogate key reference to the alternate account dimension.DEPARTMENT_KEY, OPERATING_UNIT_KEYThe name of the department and operating unit that a balance transaction has been posted against. PeopleSoft does not mandate either of these columns to be used. The columns hold the surrogate key references to the department and operating unit dimensions.

• PRODUCT_KEY, PROJECT_KEYThe name of the product and project that a balance transaction has been posted against. PeopleSoft does not mandate either of these columns to be used. The columns hold the surrogate key references to the product and project dimensions.


• CURRENCY_KEYSpecifies which currency is held against the balance transaction amounts. The CURRENCY_KEY column holds the surrogate key reference to the currency dimension.

• STATISTICS_KEYIndicates whether the balance transaction is a statistical amount (i.e. floorspace, headcount etc) This column holds the surrogate key reference to the statistics dimension

• COMPANY_KEYSpecifies to which company the balance transaction pertains. Company is mapped to department using a company lookup in the department source table. This column holds the surrogate key reference to the company dimension



Subject AreasGeneral Ledger Balances section 3

• TIME_KEYThis is a smart key reference that can be used to associate the DAY field in TIME_DIMENSION with the journal date. Although this key is provided,care has to be taken when joining between LEDGER_FACT and TIME_DIMENSION as the TIME_KEY can only be linked to DAY using DTTM_STAMP_SEC. This date and time stamp signifies when the transaction was posted to the General Ledger but does not trully represent the accounting period for which the transaction is intended. Therefore discrepencies can be experienced between the ACCOUNTING_PERIOD column in LEDGER_FACT and that in TIME_DIMENSION. It is recommended that joins should be made to the FISCAL_YEAR table through the FISCAL_YEAR and ACCOUNTING_PERIOD columns to ensure compatibility is maintained.

• FISCAL_YEAR and ACCOUNTING PERIODThe accounting period and fiscal year into which the balance transactions will occur.

• POSTED_TOTAL_AMOUNTThe transaction amount posted to the general ledger in reporting currency.

• POSTED_BASE_AMOUNTThe transaction amount posted to the general ledger in base currency

• POSTED_TRAN_AMOUNTThe transaction amount posted to the general ledger in local currency

• BASE_CURRENCY_KEYBase currency of the transaction. This column holds the surrogate key reference to the currency dimension.

• DTTM_STAMP_SECThe date and timestamp indicating when the transaction was posted

• LOAD_DATE, LOAD_TIME• The Rapid Mart populates these fields with the date and time of the start

of the data extraction from PeopleSoft. For Oracle, the Rapid Mart stores the date as a string in the format of 'YYYY.MM.DD HH24:MI:SS'. For other target databases, the Rapid Mart stores the date as a string in the 'YYYY.MM.DD' format. Similarly, the Rapid Mart stores the time in an 8-character string appropriate for your target database.. LOAD_DATE and LOAD_TIME can be helpful when using the fact tables in other applications for further data manipulation.


Subject AreasBudgeting section3
Analysis
With the tables in this section, you can analyze actual balances along several dimensions:• By department and associated hierarchies (account, alternate account,

department, operating unit and product)• By ledger category and source• By currency• By time period vs. previous period, year vs. previous yearTypical queries include:• Which legal entities have a weak balance sheet?• Where were costs higher than expected?• Why is return on equity/assets deteriorating?• The current value of assets and liabilities• What was the breakdown for the profit variance by cost?

Budgeting sectionBudgeting is used to enter estimated account balances for a specified range of periods. The estimated amounts are used to compare actual balances with projected results or to control actual and anticipated expenditures.

PeopleSoft processingThe General Ledger module in PeopleSoft provides a variety of tools to create, maintain, and track multiple budgets, including the ability to upload budget amounts from spreadsheet software. Budget and Actual balances can be stored in the PS_LEDGER_BUDG table and the Scenario field used to control which budget version or actual a transaction relates to.The General Ledger budgeting process consists of the folowing steps:• A budget is defined to represent specific estimated cost and revenue

amounts for a range of accounting periods. Multiple budget versions can be created and maintained.

• Budget organizations are defined to represent the departments, cost centers, operating units or other groups for which budget data is entered. It is possible to define one general budget organization that includes all accounts.


Subject AreasBudgeting section 3

• Budget amounts are entered. There are multiple methods to enter the budget amounts: manually, by copying amounts from existing budgets, or by importing from external systems.

Rapid Mart processingThe Budgeting section extracts budgert and actual balances from PS_LEDGER_BUDG PeopleSoft transactional tables. The section stores the source data in the BUDGET_FACT fact table.

Rapid Mart dataThe following diagram shows tables that the Budgeting section extracts.


Fact table columns
The BUDGET_FACT fact table contains actual and budget balances for multiple budget versions. The columns in the table are described below.• BUSINESS_UNIT_KEY

Identifies the legal entity business unit to which the balance transaction relates. This column holds the surrogate key reference to the business unit dimension.

• LEDGER_KEYThe name of the ledger that balance transactions have been assigned to. This column holds the surrogate key reference to the ledger dimension

• ACCOUNT_KEYThe name of the account a balance transaction has been posted against. This column holds the surrogate key reference to the account dimension

• ALTACCOUNT_KEYThe name of the alternate account a balance transaction has been posted against. PeopleSoft does not mandate alternate accounts to be used. This column holds the surrogate key reference to the alternate account dimension.DEPARTMENT_KEY, OPERATING_UNIT_KEYThe name of the department and operating unit that a balance transaction has been posted against. PeopleSoft does not mandate either of these columns to be used. The columns hold the surrogate key references to the department and operating unit dimensions.

• PRODUCT_KEY, PROJECT_KEYThe name of the product and project that a balance transaction has been posted against. PeopleSoft does not mandate either of these columns to be used. The columns hold the surrogate key references to the product and project dimensions.




• SCENARIO_KEYSpecifies which data scenario a transaction is associated with. The SCENARIO_KEY column holds the surrogate key reference to the scenario dimension.

• CURRENCY_KEYSpecifies which currency is held against the balance transaction amounts. The CURRENCY_KEY column holds the surrogate key reference to the currency dimension.

• STATISTICS_KEYIndicates whether the balance transaction is a statistical amount (i.e. floorspace, headcount etc) This column holds the surrogate key reference to the statistics dimension

• COMPANY_KEYSpecifies to which company the balance transaction pertains. Company is mapped to department using a company lookup in the department source table. This column holds the surrogate key reference to the company dimension


• BUDGET_PERIODSpecifies the budget period applicable to the transaction.Note: The BUDGET_PERIOD column does not exist in PeopleSoft 8.0 but exists in versions 8.4 and 8.8. To ensure this rapid mart works in PeopleSoft 8.0 upwards the column is set to $G_DEFAULT_TEXT in dataflow DF_BudgetFact_Rename_PSF. If PeopleSoft 8.04 or 8.8 are implemented the BUDGET_FACT column can be assigned to the source table in the two dataflows DF_BudgetFact_Stage_PSF and DF_BudgetFact_Rename_PSF.

• TIME_KEYThis is a smart key reference that can be used to associate the DAY field in TIME_DIMENSION with the journal date. Although this key is provided, care has to be taken when joining between BUDGET_FACT and TIME_DIMENSION as the TIME_KEY can only be linked to DAY using DTTM_STAMP_SEC. This date and time stamp signifies when the transaction was posted to the General Ledger but does not trully represent the accounting period for which the transaction is intended.



Therefore discrepencies can be experienced between the ACCOUNTING_PERIOD column in BUDGET_FACT and that in TIME_DIMENSION. It is recommended that joins should be made to the FISCAL_YEAR table through the FISCAL_YEAR and ACCOUNTING_PERIOD columns to ensure compatibility is maintained.

• FISCAL_YEAR and ACCOUNTING PERIODThe accounting period and fiscal year into which the balance transactions will occur.

• POSTED_TOTAL_AMOUNTThe transaction amount posted to the general ledger in reporting currency.

• POSTED_BASE_AMOUNTThe transaction amount posted to the general ledger in base currency

• POSTED_TRAN_AMOUNTThe transaction amount posted to the general ledger in local currency

• BASE_CURRENCY_KEYBase currency of the transaction. This column holds the surrogate key reference to the currency dimension.

• DTTM_STAMP_SECThe date and timestamp indicating when the transaction was posted

• LOAD_DATE, LOAD_TIMEThe Rapid Mart populates these fields with the date and time of the start of the data extraction from PeopleSoft. For Oracle, the Rapid Mart stores the date as a string in the format of 'YYYY.MM.DD HH24:MI:SS'. For other target databases, the Rapid Mart stores the date as a string in the 'YYYY.MM.DD' format. Similarly, the Rapid Mart stores the time in an 8-character string appropriate for your target database.. LOAD_DATE and LOAD_TIME can be helpful when using the fact tables in other applications for further data manipulation.



AnalysisWith the tables in this section, you can analyze actual and budget balances along several dimensions:• By department and associated hierarchies (account, alternate account,

department, operating unit and product)• By ledger category and source• By currency• By time period vs. previous period, year vs. previous year• By budget version• By actuals vs. budgetsTypical queries include:• Which country/product was below budget for sales?• Which business units are at risk of meeting budgets for the year?• Which departments are historically good or poor at utilizing their budget?


Reports

chapter

ReportsOverview4
Overview
The BusinessObjects General Ledger Rapid Mart for PeopleSoft comes with a sample universe covering each subject area (Journal Entry, GL Balances, and Budgets). You can use the Rapid Mart to produce many kinds of reports. This chapter provides examples of reports built on top of the sample universe. The information in this chapter is useful for those who analyze and produce reports with the Rapid Mart data.This chapter provides few sample reports and the recommended joins for each section in the Rapid Mart:• Journal Entry section• GL Balances section• Budgets section

Journal Entry sectionThe journal entry section captures actual financial transactions at line item level posted to the company general ledger.

Sample reportsUsing the journal entry information, you can complete numerous financial analyses and generate different reports. An example report you can generate is the Journal Detail report.


ReportsJournal Entry section 4

Journal Detail ReportThis report displays department activity by legal entity for the selected period.

You can generate the data for this report using SQL logic, such as the following Oracle SQL statement:

SELECT FISCAL_CALENDAR.FISCAL_YEAR, BUSINESS_UNIT.BUSINESS_UNIT, DEPARTMENT.DEPTID, SUM(CASE JOURNAL_FACT.ACCOUNTING_PERIOD WHEN 6 THEN JOURNAL_FACT.MONETARY_AMOUNT END), JOURNAL_FACT.JOURNAL_ID, JOURNAL_FACT.JOURNAL_LINE, JOURNAL_FACT.LINE_DESCR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR


ReportsJournal Entry section4
FROMFISCAL_CALENDAR, BUSINESS_UNIT, DEPARTMENT, JOURNAL_FACT, ACCOUNTWHERE ( DEPARTMENT.DEPARTMENT_KEY=JOURNAL_FACT.DEPARTMENT_KEY ) AND ( ACCOUNT.ACCOUNT_KEY=JOURNAL_FACT.ACCOUNT_KEY ) AND ( JOURNAL_FACT.BUSINESS_UNIT_KEY=BUSINESS_UNIT.BUSINESS_UNIT_KEY ) AND ( JOURNAL_FACT.ACCOUNTING_PERIOD=FISCAL_CALENDAR.ACCOUNTING_PERIOD AND JOURNAL_FACT.FISCAL_YEAR=FISCAL_CALENDAR.FISCAL_YEAR )GROUP BY FISCAL_CALENDAR.FISCAL_YEAR, BUSINESS_UNIT.BUSINESS_UNIT, DEPARTMENT.DEPTID, JOURNAL_FACT.JOURNAL_ID, JOURNAL_FACT.JOURNAL_LINE, JOURNAL_FACT.LINE_DESCR, ACCOUNT.ACCOUNT, ACCOUNT.DESCRHAVING ( SUM(CASE JOURNAL_FACT.ACCOUNTING_PERIOD WHEN 6 THEN JOURNAL_FACT.MONETARY_AMOUNT END) > 0 )
Recommended table joins When analyzing data from the journal entry section, you need to create joins between fact and dimension tables. Specifically, you need to create joins between the JOURNAL_FACT table and other dimension tables in the Rapid Mart.

Fact table Column name Dimension table Column name

JOURNAL_FACT BUSINESS_UNIT_KEY

BUSINESS_UNIT BUSINESS_UNIT_KEY

JOURNAL_FACT LEDGER_KEY LEDGER LEDGER_KEYJOURNAL_FACT ACCOUNT_KEY ACCOUNT ACCOUNT_KEYJOURNAL_FACT ALTACCOUNT_KEY ALTACCOUNT ALTACCOUNT_KEYJOURNAL_FACT DEPARTMENT_KEY DEPARTMENT DEPARTMENT_KEYJOURNAL_FACT OPERATING_UNIT_K

EYOPERATING_UNIT OPERATING_UNIT_K

EYJOURNAL_FACT PRODUCT_KEY PRODUCT PRODUCT_KEY


ReportsGL Balances section 4

GL Balances sectionThe balances section stores balance amounts for general ledger detail accounts.

Sample reportsUsing the balances information, you can complete numerous variance analyses and generate different reports. For example, reports you can generate include:• Asset Account Trial Balance• Period Net Activity Drill• Actuals Profit and Loss Report

JOURNAL_FACT PROJECT_KEY PROJECT PROJECT_KEYJOURNAL_FACT AFFILIATE_KEY AFFILIATE AFFILIATE_KEYJOURNAL_FACT SCENARIO_KEY SCENARIO SCENARIO_KEYJOURNAL_FACT CURRENCY_KEY CURRENCY CURRENCY_KEYJOURNAL_FACT STATISTIC_KEY STATISTIC STATISTIC_KEYJOURNAL_FACT SOURCE_KEY SOURCE SOURCE_KEYJOURNAL_FACT COMPANY_KEY COMPANY COMPANY_KEYJOURNAL_FACT ACCOUNT_TYPE_KE

YACCOUNT_TYPE ACCOUNT_TYPE_KE

YJOURNAL_FACT TIME_KEY TIME_DIMENSION TIME_KEYJOURNAL_FACT ACCOUNTING_PERI

ODFISCAL_YEAR ACCOUNTING_PERIO

DJOURNAL_FACT FISCAL_YEAR FISCAL_YEAR FISCAL_YEAR



ReportsGL Balances section4
Asset Account Trial Balance
This report supports account code analysis by period opening balance, period net activity and period end balance for the selected legal entity and selected period.


SELECT FISCAL_CALENDAR.FISCAL_YEAR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR, SUM(case LEDGER_FACT.ACCOUNTING_PERIOD WHEN 0 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 1 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 2 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 3 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 4 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 5 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 6 THEN LEDGER_FACT.POSTED_TOTAL_AMT END), SUM(case LEDGER_FACT.ACCOUNTING_PERIOD WHEN 0 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 1 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 2 THEN LEDGER_FACT.POSTED_TOTAL_AMT



WHEN 3 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 4 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 5 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 6 THEN LEDGER_FACT.POSTED_TOTAL_AMT WHEN 7 THEN LEDGER_FACT.POSTED_TOTAL_AMT END)FROM FISCAL_CALENDAR, ACCOUNT, LEDGER_FACT, ACCOUNT_TYPEWHERE ( ACCOUNT.ACCOUNT_KEY=LEDGER_FACT.ACCOUNT_KEY ) AND ( ACCOUNT_TYPE.ACCOUNT_TYPE_KEY=LEDGER_FACT.ACCOUNT_TYPE_KEY ) AND ( LEDGER_FACT.ACCOUNTING_PERIOD=FISCAL_CALENDAR.ACCOUNTING_PERIOD and LEDGER_FACT.FISCAL_YEAR=FISCAL_CALENDAR.FISCAL_YEAR ) AND ( ACCOUNT_TYPE.ACCOUNT_TYPE = 'A' )GROUP BY FISCAL_CALENDAR.FISCAL_YEAR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR


Period Net Activity Drill
This report displays period net activity for specific account types in the balance sheet..




SELECT ACCOUNT_TYPE.DESCR, ACCOUNT.ACCOUNT, SUM(LEDGER_FACT.POSTED_TOTAL_AMT), ACCOUNT.DESCR, ACCOUNT.DESCRSHORTFROM ACCOUNT_TYPE, ACCOUNT, LEDGER_FACT, FISCAL_CALENDARWHERE ( ACCOUNT.ACCOUNT_KEY=LEDGER_FACT.ACCOUNT_KEY ) AND ( ACCOUNT_TYPE.ACCOUNT_TYPE_KEY=LEDGER_FACT.ACCOUNT_TYPE_KEY ) AND ( LEDGER_FACT.ACCOUNTING_PERIOD=FISCAL_CALENDAR.ACCOUNTING_PERIOD AND LEDGER_FACT.FISCAL_YEAR=FISCAL_CALENDAR.FISCAL_YEAR ) AND ( FISCAL_CALENDAR.FISCAL_YEAR = 2004 )GROUP BY ACCOUNT_TYPE.DESCR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR, ACCOUNT.DESCRSHORT


Actuals Profit and Loss Report
This report displays expense items for particular P&L account codes for a selected legal entity, operating unit and department..




SELECT LEDGER.LEDGER, LEDGER.DESCR, BUSINESS_UNIT.BUSINESS_UNIT, BUSINESS_UNIT.DESCR, OPERATING_UNIT.OPERATING_UNIT, OPERATING_UNIT.DESCR, DEPARTMENT.DEPTID, DEPARTMENT.DESCR, CURRENCY.CURRENCY, CURRENCY.DESCR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR, SUM(CASE LEDGER_FACT.ACCOUNTING_PERIOD WHEN 1 THEN LEDGER_FACT.POSTED_TOTAL_AMT END), SUM(CASE LEDGER_FACT.ACCOUNTING_PERIOD WHEN 2 THEN LEDGER_FACT.POSTED_TOTAL_AMT END), SUM(CASE LEDGER_FACT.ACCOUNTING_PERIOD WHEN 3 THEN LEDGER_FACT.POSTED_TOTAL_AMT END), SUM(CASE LEDGER_FACT.ACCOUNTING_PERIOD WHEN 4 THEN LEDGER_FACT.POSTED_TOTAL_AMT END), SUM(CASE LEDGER_FACT.ACCOUNTING_PERIOD WHEN 5 THEN LEDGER_FACT.POSTED_TOTAL_AMT END), SUM(CASE LEDGER_FACT.ACCOUNTING_PERIOD WHEN 6 THEN LEDGER_FACT.POSTED_TOTAL_AMT END), SUM(CASE LEDGER_FACT.ACCOUNTING_PERIOD WHEN 7 THEN LEDGER_FACT.POSTED_TOTAL_AMT END)FROM LEDGER, BUSINESS_UNIT, OPERATING_UNIT, DEPARTMENT, CURRENCY, ACCOUNT, LEDGER_FACTWHERE ( DEPARTMENT.DEPARTMENT_KEY=LEDGER_FACT.DEPARTMENT_KEY ) AND ( ACCOUNT.ACCOUNT_KEY=LEDGER_FACT.ACCOUNT_KEY ) AND ( LEDGER.LEDGER_KEY=LEDGER_FACT.LEDGER_KEY ) AND ( CURRENCY.CURRENCY_KEY=LEDGER_FACT.CURRENCY_KEY ) AND ( LEDGER_FACT.BUSINESS_UNIT_KEY=BUSINESS_UNIT.BUSINESS_UNIT_KEY ) AND ( OPERATING_UNIT.OPERATING_UNIT_KEY=LEDGER_FACT.OPERATING_UNIT_KEY ) AND ( BUSINESS_UNIT.BUSINESS_UNIT = 'GB001' AND OPERATING_UNIT.OPERATING_UNIT = '2110' AND DEPARTMENT.DEPTID = '105001' AND CURRENCY.CURRENCY = 'GBP' )


GROUP BY LEDGER.LEDGER, LEDGER.DESCR, BUSINESS_UNIT.BUSINESS_UNIT, BUSINESS_UNIT.DESCR, OPERATING_UNIT.OPERATING_UNIT, OPERATING_UNIT.DESCR, DEPARTMENT.DEPTID, DEPARTMENT.DESCR, CURRENCY.CURRENCY, CURRENCY.DESCR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR
Recommended table joins When analyzing data from the balances section, you need to create joins between fact and dimension tables. Specifically, you need to create joins between the GL_BALANCE_FACT table and other dimension tables in the Rapid Mart.


LEDGER_FACT BUSINESS_UNIT_KEY


LEDGER_FACT LEDGER_KEY LEDGER LEDGER_KEYLEDGER_FACT ACCOUNT_KEY ACCOUNT ACCOUNT_KEYLEDGER_FACT ALTACCOUNT_KEY ALTACCOUNT ALTACCOUNT_KEYLEDGER_FACT DEPARTMENT_KEY DEPARTMENT DEPARTMENT_KEYLEDGER_FACT OPERATING_UNIT_K


EYLEDGER_FACT PRODUCT_KEY PRODUCT PRODUCT_KEYLEDGER_FACT PROJECT_KEY PROJECT PROJECT_KEYLEDGER_FACT AFFILIATE_KEY AFFILIATE AFFILIATE_KEYLEDGER_FACT CURRENCY_KEY CURRENCY CURRENCY_KEYLEDGER_FACT STATISTIC_KEY STATISTIC STATISTIC_KEYLEDGER_FACT SOURCE_KEY SOURCE SOURCE_KEYLEDGER_FACT COMPANY_KEY COMPANY COMPANY_KEYLEDGER_FACT ACCOUNT_TYPE_KE


YLEDGER_FACT TIME_KEY TIME_DIMENSION TIME_KEY


ReportsBudgets section 4

Budgets sectionThe budget section stores actual and budget version transactions for general ledger budget proposals.

Sample reportsUsing the budget information, you can complete numerous analyses and generate different reports. For example, reports you can generate include:• Actual V Budget Report• Budget Profit and Loss Report

Actual V Budget ReportThis report shows actual YTD, budget YTD and variance data for the selected legal entity, department and fiscal period.

LEDGER_FACT ACCOUNTING_PERIOD

FISCAL_YEAR ACCOUNTING_PERIOD

LEDGER_FACT FISCAL_YEAR FISCAL_YEAR FISCAL_YEAR



ReportsBudgets section4




SELECT BUSINESS_UNIT.BUSINESS_UNIT, DEPARTMENT.DEPTID, ACCOUNT.ACCOUNT, ACCOUNT.DESCR, DEPARTMENT.DESCR, SUM(CASE WHEN FISCAL_CALENDAR.CURRENT_FISCAL_YEAR = 'Y' AND SCENARIO.SCENARIO = 'A' THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE WHEN FISCAL_CALENDAR.CURRENT_FISCAL_YEAR = 'Y' AND SCENARIO.SCENARIO = 'B' THEN BUDGET_FACT.POSTED_TOTAL_AMT END)FROM BUSINESS_UNIT, DEPARTMENT, ACCOUNT, BUDGET_FACT, SCENARIO, FISCAL_CALENDARWHERE ( DEPARTMENT.DEPARTMENT_KEY=BUDGET_FACT.DEPARTMENT_KEY ) AND ( ACCOUNT.ACCOUNT_KEY=BUDGET_FACT.ACCOUNT_KEY ) AND ( BUDGET_FACT.BUSINESS_UNIT_KEY=BUSINESS_UNIT.BUSINESS_UNIT_KEY ) AND ( BUDGET_FACT.SCENARIO_KEY=SCENARIO.SCENARIO_KEY ) AND ( BUDGET_FACT.ACCOUNTING_PERIOD=FISCAL_CALENDAR.ACCOUNTING_PERIOD AND BUDGET_FACT.FISCAL_YEAR=FISCAL_CALENDAR.FISCAL_YEAR ) AND ( FISCAL_CALENDAR.FISCAL_YEAR = 2004 )GROUP BY BUSINESS_UNIT.BUSINESS_UNIT, DEPARTMENT.DEPTID, ACCOUNT.ACCOUNT, ACCOUNT.DESCR, DEPARTMENT.DESCR


Budget Profit and Loss Report
This report displays budget version expense items for particular P&L account codes for a selected legal entity, operating unit and department..


SELECT LEDGER.LEDGER, LEDGER.DESCR, BUSINESS_UNIT.BUSINESS_UNIT, BUSINESS_UNIT.DESCR, OPERATING_UNIT.OPERATING_UNIT, OPERATING_UNIT.DESCR, DEPARTMENT.DEPTID, DEPARTMENT.DESCR, CURRENCY.CURRENCY, CURRENCY.DESCR, ACCOUNT.ACCOUNT,



ACCOUNT.DESCR, SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 1 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 2 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 3 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 4 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 5 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 6 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 7 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 8 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 9 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 10 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 11 THEN BUDGET_FACT.POSTED_TOTAL_AMT END), SUM(CASE BUDGET_FACT.ACCOUNTING_PERIOD WHEN 12 THEN BUDGET_FACT.POSTED_TOTAL_AMT END)FROM LEDGER, BUSINESS_UNIT, OPERATING_UNIT, DEPARTMENT, CURRENCY, ACCOUNT, BUDGET_FACTWHERE ( DEPARTMENT.DEPARTMENT_KEY=BUDGET_FACT.DEPARTMENT_KEY ) AND ( ACCOUNT.ACCOUNT_KEY=BUDGET_FACT.ACCOUNT_KEY ) AND ( LEDGER.LEDGER_KEY=BUDGET_FACT.LEDGER_KEY ) AND ( CURRENCY.CURRENCY_KEY=BUDGET_FACT.CURRENCY_KEY ) AND ( BUDGET_FACT.BUSINESS_UNIT_KEY=BUSINESS_UNIT.BUSINESS_UNIT_KEY ) AND ( OPERATING_UNIT.OPERATING_UNIT_KEY=BUDGET_FACT.OPERATING_UNIT_KEY ) AND ( BUSINESS_UNIT.BUSINESS_UNIT = 'GB001' AND OPERATING_UNIT.OPERATING_UNIT = '2110' AND DEPARTMENT.DEPTID = '105001' AND CURRENCY.CURRENCY = 'GBP' )GROUP BY LEDGER.LEDGER, LEDGER.DESCR, BUSINESS_UNIT.BUSINESS_UNIT,


BUSINESS_UNIT.DESCR, OPERATING_UNIT.OPERATING_UNIT, OPERATING_UNIT.DESCR, DEPARTMENT.DEPTID, DEPARTMENT.DESCR, CURRENCY.CURRENCY, CURRENCY.DESCR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR
Recommended table joins When analyzing data from the budget section, you need to create joins between fact and dimension tables. Specifically, you need to create joins between the BUDGET_FACT table and other dimension tables in the Rapid Mart.


BUDGET_FACT BUSINESS_UNIT_KEY


BUDGET_FACT LEDGER_KEY LEDGER LEDGER_KEYBUDGET_FACT ACCOUNT_KEY ACCOUNT ACCOUNT_KEYBUDGET_FACT ALTACCOUNT_KEY ALTACCOUNT ALTACCOUNT_KEYBUDGET_FACT DEPARTMENT_KEY DEPARTMENT DEPARTMENT_KEYBUDGET_FACT OPERATING_UNIT_K


EYBUDGET_FACT PRODUCT_KEY PRODUCT PRODUCT_KEYBUDGET_FACT PROJECT_KEY PROJECT PROJECT_KEYBUDGET_FACT AFFILIATE_KEY AFFILIATE AFFILIATE_KEYBUDGET_FACT CURRENCY_KEY CURRENCY CURRENCY_KEYBUDGET_FACT STATISTIC_KEY STATISTIC STATISTIC_KEYBUDGET_FACT SOURCE_KEY SOURCE SOURCE_KEYBUDGET_FACT COMPANY_KEY COMPANY COMPANY_KEYBUDGET_FACT ACCOUNT_TYPE_KE


YBUDGET_FACT TIME_KEY TIME_DIMENSION TIME_KEYBUDGET_FACT ACCOUNTING_PERI

ODFISCAL_YEAR ACCOUNTING_PERI

ODBUDGET_FACT FISCAL_YEAR FISCAL_YEAR FISCAL_YEAR



Installing the Rapid Mart

chapter

Installing the Rapid MartOverview5
Overview
This chapter contains the information you need to install the BusinessObjects General Ledger Rapid Mart for PeopleSoft. The information in this chapter is useful for system administrators or others who install the Rapid Mart.This chapter contains the following sections:• System prerequisites• Rapid Mart product components• Preparing your environment• Installation overview• Installation procedure• Completing the installation• Installing Rapid Mart Reporting Content

System prerequisitesTo run the BusinessObjects General Ledger Rapid Mart for PeopleSoft, your system requires:• Data Integrator version 11.5.2 or higher compatible version• An Oracle 9i database or Microsoft SQL Server or IBM DB2 UDB 8

database or compatible version. • PeopleSoft release 8.8 or higher compatible version• BusinessObjects Enterprise XIR2 if you want to install Rapid Mart

Reporting Content.If you have questions about system prerequisites, contact Business Objects Technical Support.

Rapid Mart product componentsThe Rapid Mart includes several major product components:• A SQL script for defining the Rapid Mart tables• A SQL script for dropping the Rapid Mart tables• An Data Integrator metadata repository that specifies the full load and

incremental update jobs for the following:• Data extract from PeopleSoft • Data load into the Rapid Mart

• SQL scripts to drop and re-create indexes after loading the Rapid Mart


Installing the Rapid MartPreparing your environment 5

• SQL scripts to create database stored procedures. Dummy procedures are created during installation and procedure samples (for oracle only) are available in Sample\DDL directory.

• An ERWin diagram of the data schema• Set of documents which includes business guide, user guide and release

notes • An option to install rapid mart reporting contents that includes

BusinessObjects Enterprise XIR2 WebIntelligence reports and a universe. See “Installing Rapid Mart Reporting Content” on page 64 for details.

Preparing your environmentFollow these steps to prepare your environment for the Rapid Mart installation:1. Install Data Integrator, if it is not already installed.

Refer to the Data Integrator Getting Started Guide for detailed installation instructions.Make sure that you install the Data Integrator Designer and that you install and configure a Job Server and an Access Server.The default Data Integrator installation creates a repository that you can use for your Rapid Mart. You can also create a separate repository for Rapid Mart after the Data Integrator installation using the Repository Manager.Though you need Data Integrator job server to run Rapid Mart jobs, you need just Data Integrator Designer to install Rapid Mart. This designer can connect to any other job server to process jobs.

2. Start Data Integrator and log on to the repository where you are going to install the Rapid Mart.This step ensures that your default connection is set appropriately.

3. Exit Data Integrator.4. Prepare your target data warehouse environment. Currently the Rapid

Mart supports Oracle, MS SQL Server and DB2 as target databases. You have to supply target database connection informations including username and password if you want to create target schema.

5. Confirm your source application version. Some of the Rapid Mart does special processing depending upon the source application version. You are now ready to install the Rapid Mart.


Installing the Rapid MartInstallation overview5

Follow these steps to prepare your environment for the Rapid Mart Reporting Content installation:1. You need to define an environment variable JAVA_HOME to point to

where java.exe exists. Otherwise you will get error message like “Either JAVA_HOME is not defined or the Installer could not find JAVA_HOME. Please define JAVA_HOME upto /bin dir and try again.” For example if you have Business Objects installed in your machine, it generally puts java executable in C:\Program Files\Business Objects\j2sdk1.4.2_08\bin directory. In this case, the JAVA_HOME should be C:\Program Files\Business Objects\j2sdk1.4.2_08

Installation overviewThe installation program:• Ensures that a compatible version of Data Integrator is installed.• Prompts you for information about your system and Rapid Mart

environment.The installation program uses this information to customize the Rapid Mart to conform to your environment before loading the Rapid Mart into the repository.

• Creates the files in the RapidMart\PeopleSoftGL sub-directory of your installation directory, including:• SQL files to create and drop tables, indexes and stored procedures.• Source atl files to import into Data Integrator• Files containing messages and warnings.

• Drops and creates the tables in the target database, if requested.This includes the data tables, staging tables, and a Rapid Mart system table, called AW_JOBEXECUTION, which maintains execution status information.

• Loads and customizes the repository.After the installation program completes, follow the post installation instructions available in the log file (inslog.txt) found in installation directory.

Installation procedureFollow these steps to install the Rapid Mart:


Installing the Rapid MartInstallation procedure 5

1. Put the Rapid Mart CD in your CD drive (on the computer where the Data Integrator Designer is installed). Generally CD pops up the Autorun screen. Otherwise use Windows explorer to go to your CD drive, and then double-click Autorun.exe.

2. This opens up the autorun screen. Select “Install Rapid Mart” option to install Rapid Mart.

3. The Welcome window opens. Read its contents to double confirm the name and version of the Rapid Mart that you are installing and then click Next.

4. The License Agreement window opens. Read its contents and click Yes to indicate that you agree to the product terms and conditions.

5. The Rapid Mart Destination Folder window opens. Verify that the window lists your preferred installation location. To install in the indicated directory, click Next.To install in a different directory, click Browse and select the desired directory.

6. The Repository Logon window opens.Fields vary by the type of database that stores the repository. For information about repository logon fields, see the Data Integrator Designer Guide.Enter the information needed to connect and log on to your Data Integrator repository. You can also “Test” the repository connection. This test will make sure that the connection parameters are correct and a valid Data Integrator repository exists in that connection. Once you are satisfied with the connection parameters click Next.

7. The Rapid Mart Configuration Information window opens.


Installing the Rapid MartInstallation procedure5

Enter or select the configuration for the source datastore, target datastore.

Prompt Description

Source DatastoreName Select or enter the name of the source

datastore from which the Rapid Mart extracts data. For BusinessObjects General Ledger Rapid Mart for PeopleSoft, the default value is PS_DS. Installer will create this data store even if the datastore does not exist in the repository.

Application Type Select the type and version of the application server to which you will be connecting. BusinessObjects General Ledger Rapid Mart for PeopleSoft decides about further processing based on this input.

Target DatastoreName Select or enter the name of the target

datastore into which the Rapid Mart loads data. For BusinessObjects General Ledger Rapid Mart for PeopleSoft, the default value is RM_DS. Installer will create this data store even if the datastore does not exist in the repository.

Target Database InformationDrop and Create DB Objects.

This option will drop (if exists) and create all database objects - tables, indexes and procedures - required for target database schema during the installation process.

Database Type Select the target database type from one of the available types. Depending upon the selected type other options change.

Database connection Name Appears in the case of oracle database type. Enter the tns connection name to connect to target database.

Database Server Name Appears in the case of MS SQL Server database type. Enter the server name on which the SQL server database runs. In case of named instances you may need to add the instance names properly.


Installing the Rapid MartInstallation procedure 5

8. If the source or target datastore that you entered does not currently exist in the repository, the Installation process will create these datastores for you.

9. If you select the available source and/or target datastores from the drop down list, the installation process will add the repository objects to these data stores but the existing datastore connection parameters would be lost. In other words, the installation process will overwrite the connection parameters if you select existing datastores.

10. You need to check box on Drop and Create DB Objects in case you want to create target database objects (tables, indexes and procedures) to load the data from the source.

11. If you check the Drop and Create DB Object, then you have to enter target database Information. Test the connection parameters and then click Next.

12. Now the “Review” screen appears. You can verify all the parameters - the repository information, the source and target datastore information and the target data warehouse database information. If you want to modify any of the parameters, you can browse Back, or if you are satisfied click Next.

13. The Setup Status window shows the progress of the installation program, displaying messages as the program prepares files, creates tables, and loads the repository.

14. The Final Instructions window lists steps you must consider before running and using the Rapid Mart in your environment. Read these steps, then click Next.

15. The Installation Succeeded window opens.To see the installation log, click the check box and click Finish.

Database Name Appears in the case of MS SQL Server database type. Enter the target database name in the SQL Server database.

DB2 Datasource Appears in the case of DB2 database type. Enter the DB2 data source information.

Username Database connection Username. Make sure that the user got privileges to create/drop table, indexes and procedures

Password Database connection Password.

Prompt Description


Installing the Rapid MartCompleting the installation5

The installation log (inslog.txt) is stored in the Rapid Mart installation directory that you have selected during the installation process. The file lists the steps that the installation program completed. Scroll to the bottom of the file to see information about the latest install.

Completing the installationTo complete the installation, start Data Integrator and log in to the Rapid Mart repository. Before using and running the Rapid Mart in your environment, you must complete several steps:• Make sure that you have completed all the steps in the install instructions

(found in the inslog.txt in Rapid Mart installation directory).• If your Job Server runs on a UNIX system, adjust the directory paths in all

Rapid Mart file format definitions to follow the UNIX convention (that is, change “/” to “\”).

• Adjust the properties of your Application Datastore and target datastore using the Data Integrator Designer:• using Datastore Configurations, select the appropriate Database

Type as Default Configuration• adjust the Connection properties, such as database name, user

name, password • Set up local and global variables as required using the Data Integrator

Designer as described in Chapter 6: Using the Rapid Mart.The Projects tab in the object library shows the defined projects.The PSFT_GL_Rapid_Mart project contains the job for loading the Rapid Mart—both the initial load and the incremental load. Before running the job that loads the Rapid Mart, you must initialize some variables. For information about executing the Rapid Mart, see Chapter 6: Using the Rapid Mart.

Installing Rapid Mart Reporting ContentRapid Marts come with its own Reporting Content. In order to use these Reporting Content (i.e. supplied WebIntelligence reports and a universe), you must first install them to your BusinessObjects Enterprise XI R2 system and configure a connection to your Rapid Mart target database.If the BusinessObjects Enterprise XI R2 server is located on a different machine, you need to have BusinessObjects Enterprise XI R2 client installed.


Installing the Rapid MartInstalling Rapid Mart Reporting Content 5

1. Put the Rapid Mart CD in your CD drive. Generally CD pops up the Autorun screen. Otherwise use Windows explorer to go to your CD drive, and then double-click Autorun.exe.

2. This opens up the autorun screen. Select “Install Reporting Content” option to install the Reporting Content.

3. The Welcome window opens. Read its contents to double confirm the name and version of the Rapid Mart Reporting Content that you are installing and then click Next.

4. Select the directory to use in which the Rapid Mart Reporting Content will be installed. By default this is set to <PROGRAM FILES>\Business Objects\Rapid Marts\HR. Click Next.Note: The folder specified is used only as temporary storage during installation. Once the installation is complete, this folder can be removed by re-running the setup program, Setup.exe.

5. Enter a valid login for the BusinessObjects Enterprise XI R2 system to which you wish to publish the Rapid Mart Reporting Content. Click Next.Note: The user name is set to ‘Administrator’ and cannot be changed. The authentication mode is set to ‘secEnterprise’ and cannot be changed.

6. Click Next at the confirmation screen to start installation.7. Now the installer will unpack and release the reporting contents into your

BusinessObjects Enterprise system.8. Click Finish to complete the installation. Remember, you must configure

the universe connection before attempting to run any of the reports.9. You can see any installation issues in the installation log

(visuals_inslog.txt) found in the installation directory. Note: Please make sure that the BIAR files are installed successfully by confirming the line “[InstallEntSdkWrapper.main] BIAR File Imported successfully“ in the log file. Note: Also if you re-installing the Reporting Content, make sure that you removed the Rapid Mart Reporting Content supplied objects and universes before re-installing. Note: You can also import the BIAR file manually using BusinessObjects Enterprise XI R2 Import Wizard. The BIAR file can be found in the specified installation directory.


Installing the Rapid MartInstalling Rapid Mart Reporting Content5

10. Rapid Mart Reporting Content are published to a folder called ‘Rapid Mart Reporting Content’ in your BusinessObjects Enterprise XI R2 system. In this folder you will find a sub-folder with a name that corresponds to the Rapid Mart you have installed. In this sub-folder you will find the reports.


Installing the Rapid Mart 5


Installing the Rapid Mart5



Using the Rapid Mart

chapter

Using the Rapid MartOverview6
Overview
This chapter describes how to execute the Rapid Mart, including information about the variables that the Rapid Mart uses. This chapter also discusses considerations you need to make when customizing the Rapid Mart. The information in this chapter is useful for administrators and others who run or modify the Rapid Mart.Specific topics include:• Recovery framework• Execution status framework• Extraction, transformation and loading process• Batch configuration variables• Customizing the Rapid Mart

Recovery frameworkWhen executing the Rapid Mart, it is important that you do not load any duplicate data and that you do not extract data redundantly, even in cases of failure. There are two mechanisms to ensure that you do not load duplicate data:• Data Integrator automatic recovery feature• Rapid Mart recovery framework

Data Integrator automatic recovery featureWith automatic recovery, Data Integrator records the result of each successfully completed step in a job. If a job fails, you can choose to run the job again in recovery mode. During recovery mode, Data Integrator retrieves the results for successfully completed steps and reruns uncompleted or failed steps under the same conditions as the original job. For recovery purposes, Data Integrator considers steps that raise exceptions as failed steps, even if the step is caught in a try/catch block.To use the automatic recovery feature, you must enable the feature during the initial execution of a job. In the Execution Properties window, select the Enable Recovery check box. The automatic recovery option is useful during testing and development phases. However, use caution with this feature during a production run because the data may lose its integrity if significant changes in PeopleSoft source tables occur between the failed run and the recovery run.


Using the Rapid MartRecovery framework 6

For example, suppose two tables contain related data but are loaded in separate work flows. In this case, the job can fail after successfully completing the work flow that loads the first table but before completing the work flow that loads the second table. During recovery, Data Integrator does not re-run a successfully completed work flow; therefore, the first table is not loaded again. However, Data Integrator will run the work flow that loads the second table during the recovery job. If the work flow loads the entire table regardless of dates, the second table will contain data added to PeopleSoft between the initial run and the recovery run, but the first table will not contain this data. As a result, the two tables will be inconsistent.

Rapid Mart recovery frameworkThe Rapid Mart contains an external execution status table (AW_JOBEXECUTION) that tracks the status of a job’s execution and the time data was extracted. By using the execution status table, the Rapid Mart ensures that data for the proper dates is extracted from the source datastore.With each execution, the Rapid Mart job extracts data between a start date and an end date. If the job fails and is rerun on the same or a subsequent day, the new job uses the failed job’s start date to ensure that all the data is extracted contiguously.Upon execution, a job first checks the status of the last execution of the job. If the last execution failed, the job determines the ending date of the last successful execution. This date becomes the starting date of the next execution of the job. All work flows are re-executed using the same starting date to ensure consistency. For example, if a failed job is restarted on the same day (without using the automatic recovery feature), the restarted job refreshes all tables because the last execution of the job on that day was not successful. If a job continues to fail over several days, the job would continue using the same start date used on the first failed attempt. This ensures that when the job is eventually successful, it extracts the complete set of data that changed since the start date.To maintain consistency with data flowing to PeopleSoft, the Rapid Mart always overlaps one day’s worth of data in incremental loads. For example, if the end date is June 3, the incremental load job extracts data entered or changed on June 3. The next incremental load job extracts data starting with the June 3 date. Up to one day’s worth of duplicate data may be extracted each time the job runs; however, work flows are designed to detect and delete duplicate data from the target data table before reloading the refreshed data. To do this,


Using the Rapid MartExecution status framework6

many work flows use the auto correct load option. The auto correct load option checks for an existing row with the same key as each row flagged as an insert or update activity. If the row exists, this option updates the row. If the row does not exist, this option inserts the row.

Execution status framework The Rapid Mart uses two mechanisms to check the job execution status and control execution: • An execution status table that stores one record for each job. That record

contains:• Status of previous job execution• Starting and ending times of the last attempted execution of the job

• An application programming interface (API) that updates the status table and supports the implementation of restartable jobs and flows

The execution status tableThe Rapid Mart installation procedure creates a table named AW_JOBEXECUTION in the target database.The execution status table has four columns.

How job status is maintainedThe Rapid Mart records a job status for each invocation of a particular job. There are three possible values for job status: • None — The job status is none when the job has never been executed.• Started — Job status is set to started when a new invocation of a job

starts.• Done — Job status is set to done when a job completes successfully.

Table column Description

NAME The name of the job being executed. If the same target datastore is used for more than one repository, you must ensure that all job names are unique.

STATUS The status of this job after the last execution. Possible status values are: started, done, or none.

EXTRACTLOW Last attempted start date of data retrieval. This date is also the ending date of the last successful run of the job.

EXTRACTHIGH Last attempted end date of data retrieval.


Using the Rapid MartExecution status framework 6

When a job is started, the Rapid Mart checks the job’s existing status. If the previous execution of the job did not complete successfully—that is, the job status is not done—the Rapid Mart resets the starting date for data extraction ($G_SDATE) from the value specified in the job initialization script to the ending date of the last successful run (EXTRACTHIGH). You can override the reassignment of the starting date by forcing the starting date to be reset. See “Executing a job with the reset option” on page 74. The Rapid Mart never changes the ending value ($G_EDATE) from the value specified in the initialization script.After checking the job’s existing status, the Rapid Mart sets the status of the job to started, and starts a new execution of the job.When a job successfully completes, the Rapid Mart sets the job’s status to done. If the job does not complete successfully, the job’s status remains set to started. The EXTRACTLOW and EXTRACTHIGH dates remain set to the current values.

The execution status APIThe execution status API updates the execution status table to control gaps in the time sequence of data extraction.The API contains two external functions. These functions mark the start and termination of jobs.• AW_StartJob ($jobname input, $run_mode input, $load_type input, extractlow input/

output, extracthigh date input/output) The InitializeJob script calls this function to initialize a job and check the last execution status. When called for a new job execution, the function inserts a new row into table AW_JOBEXECUTION. When called for a restarted job execution, the function: • Checks the run mode to see if you set the reset option.

If $G_RUN_MODE is RESET, the function resets EXTRACTLOW and EXTRACTHIGH to the $G_SDATE and $G_EDATE values specified in the initialization script.

• Checks the last execution status of the job. If the job status is done, the function sets EXTRACTLOW to the previous value of EXTRACTHIGH, the last successful end date; next, the function sets EXTRACTHIGH to the value of $G_EDATE,


Using the Rapid MartExtraction, transformation and loading process6

which you set in the initialization script. The function returns the values in EXTRACTLOW and EXTRACTHIGH and the Rapid Mart uses these values to update $G_SDATE and $G_EDATE.If the job status is started, the function does not change the value of EXTRACTLOW. Instead, this value remains the end date of the last successful execution. The function does change EXTRACTHIGH to the new value set in $G_EDATE. The function returns the EXTRACTLOW and EXTRACTHIGH values, and the Rapid Mart uses these values to update $G_SDATE and $G_EDATE.

• AW_EndJob(job name) The EndJob script calls this function to change the job status value in the AW_JOBEXECUTION table to done when the job executes successfully.

Executing a job with the reset optionYou can use the reset mode to force the Rapid Mart to assign a new starting extract time for data extracts. Use reset mode to force the starting and ending dates to remain the same as the values set in the initialization script. Note: Using this option may cause gaps in the time sequence of data loaded into target tables. To specify reset mode, edit the job’s initialization script and uncomment the line that sets $G_RUN_MODE to RESET. When using reset mode, be sure that the variable $G_SDATE is set to the appropriate starting date so that no gaps occur.

Extraction, transformation and loading process

The job PSFT_GL_Load executes objects that load the BusinessObjects General Ledger Rapid Mart for PeopleSoft. This job contains:


Using the Rapid MartExtraction, transformation and loading process 6

• Job global variable properties. This window can be accessed by right-clicking on the PSFT_GL_Load job and selecting the Properties command from the drop-down list. Most of the General Ledger Rapid Mart global variables are initialized here.

• An initialization script. The script contains description of each global variable set in the job Properties window. It also completes several steps: • Sets the initial values of the Rapid Mart framework variables that the

job uses• Initiates the execution status framework

• Sections that load a set of tables you can use to analyze and report on a particular subject area in the Rapid Mart. A section consists of: • A work flow that loads the reporting dimensions applicable to the

subject area.• Work flows that load holding tables, intermediate tables, and auxiliary

tables that support loading the main subject area tables. Some of these flows might be reusable components, which can be incorporated into multiple sections of Rapid Marts. Components have the “execute once” feature enabled.


Using the Rapid MartBatch configuration variables6

• A conditional object that determines whether the job executes the initial or incremental loading logic.

• Work flows that load the main tables for the subject area. These tables are generally called “fact” tables in relational modeling terminology. A section loads a single fact table and any additional fact tables that depend on it. For example, an order analysis section might load an order table and an order summary table.

• A script that updates the job execution status table

Batch configuration variablesThe job that load the BusinessObjects General Ledger Rapid Mart for PeopleSoft uses several variables:• Global Variables• Local Variables

Global VariablesGlobal variables are commonly used in other Rapid Marts. You can identify global variables by a “G_” prefix in their names. The InitializeJob script initializes these variables.

Variable name Format Description

$G_LANGUAGE char(30) Language to be Used throughout the Rapid Mart

$G_LOAD_TYPE char(7) Controls initial versus incremental loading. Each component includes a conditional that checks the $LOAD_TYPE value. If $LOAD_TYPE is set to FIRST, the initial load logic is executed. If $LOAD_TYPE is DELTA, the incremental load logic is executed. To change from initial load value to incremental load, remove the comment delimiter (#) from statement #$LOAD_TYPE = 'DELTA' and add a comment delimiter to statement $LOAD_TYPE= 'FIRST'


Using the Rapid MartBatch configuration variables 6

$G_SDATE YYYY.MM.DD

The start date for time-dependent data extraction.During an initial extract, the job does not extract data that was entered into your PeopleSoft system prior to $SDATE. For example, if your start date is January 26, 2000, the initial extract job does not extract data that was entered on January 25, 2000 or earlier.During incremental extractions, the job only extracts data modified or entered on or after this date. The incremental load job only uses the $SDATE when one of these conditions is true:• Execution status table

AW_JOBEXECUTION has no rows that correspond to the current job. See “The execution status table” on page 72.

• The variable $RUN_MODE is set to RESET in the initialization script for the job. See “Executing a job with the reset option” on page 74.

$G_EDATE YYYY.MM.DD

The ending date for time-dependent data extraction.The recommended value for first load is yesterday (sysdate -1). The recommended value for an incremental load is today (sysdate).Jobs do not extract data entered into your PeopleSoft system after this date. For example, if your end date is June 4, 1999, the extract will not extract data for June 5, 1999

$G_LOAD_DATE datetime Set to current system date$G_LOAD_TIME char(8) Set to character representation of current

system time$G_DEFAULT_DATE date Default value for a date field when it is NULL.

The default value is ‘9999.12.31’$G_DEFAULT_NUMBER int Default value for a number field when it is

NULL or when it is a foreign key. The default value is -1



Using the Rapid MartBatch configuration variables6

Local VariablesLocal variables are also used in other Rapid Marts. They do not have a specific prefix in their names as global variables have. The InitializeJob script initializes these variables.

Executing the jobsThe steps you complete when executing the PSFT_GL_Load job depend on the type of job:• Initial extraction • Incremental extraction

To execute the initial extraction and load1. In the project area right-click in the PSFT_GL_Load job to access the

Properties window.2. Edit the job Global Variable properties:

a. Make sure that the value for the $G_LOAD_TYPE variable is set to ‘FIRST’.

b. Set the starting and ending time periods for the initial load.

$G_DEFAULT_TEXT char(1) Default value for a character field when it is NULL and when it is not a foreign key. The default value is ‘?’

$G_CALENDAR_ID char(15) Name of the Period Set to be used to populate TIME_DIM only. The default value is ‘Accounting’

$G_CALENDAR_SETID char(15) Type of the Period Set to be used to populate TIME_DIM only. Default is ‘Month’.

$G_REBUILD_INDEXES char(1) Controls whether the fact table index is rebuilt after data loading has taken place



$RUN_MODE char(7) When set to RESET and not commented out, this variable forces the Rapid Mart to assign a new starting extract time ($G_SDATE) for data extracts. By default it is commented

$P_FAILURES int Contains the pass or failure status returned by the fact table post-processing script


Using the Rapid MartBatch configuration variables 6

c. Set the starting date (the value for $G_SDATE) low enough to select the earliest data desired for all target tables. Set the ending date (the value for $G_EDATE) to the current date.

d. Set values for the rest of global variables in the Properties window and click OK to accept the set properties and to close the window.

You can also set global variable values after you select Execute command from the drop-down menu in the project area.For more information about the variables see “Batch configuration variables” on page 76.

3. Run the job.

a. In the project area, right-click the job and choose Execute.Data Integrator opens the Execution Properties window.

b. Select the desired execution properties.At this point, you must decide whether or not to enable automatic recovery. See Data Integrator User Guide for more information.If you enabled automatic recovery and a job failed, you can recover from the failed job at this time.

c. Click OK to accept the selected properties and start the job.The job completes several steps:• Initializes the variables to the values you set in the initialization

script.• Calls components to load the tables. Generally, the job truncates

the tables before loading them during the initial job.Some components, such as work flows that load dimension tables, are repeated. The job only executes these components the first time because these work flows and data flows are set to “execute only once.”

4. Check the error log and the execution status table to make sure the job ran successfully.

To execute the incremental extraction and load1. Open the Properties window for job PSFT_GL_Load by right-clicking on

the job in the project area and selecting Properties command. Edit the job Global Variable properties:a. Make sure that the value for the $G_LOAD_TYPE variable is set to

‘DELTA’.


Using the Rapid MartCustomizing the Rapid Mart6

b. Set the starting and ending time periods for the delta load. The standard setting is the current date for both the starting and ending date.

c. Set values for the rest of global variables in the Properties window. d. Click OK to accept the set properties and to close the window.

2. Run the job.a. In the project area, right-click the job and choose Execute.

Data Integrator opens the Execution Properties window. b. Select the desired execution properties.

At this point, you must decide whether or not to enable automatic recovery. See Data Integrator User Guide for more information about automatic recovery. If you enabled automatic recovery and a job failed, you can recover from the failed job at this time.

c. Click OK to accept the selected properties and start the job.The job completes several steps:• Initializes the variables to the values you set in the initialization

script.• Calls components to load the tables incrementally, inserting new

and changed data since the last job execution. The job deletes outdated data from the target tables, and reloads the target tables with new and changed data. The incremental load uses the append option to load most tables.Some components, such as work flows that load dimension tables, are repeated. The job only executes these components the first time because these work flows and data flows are set to “execute only once.”

3. Check the error log and the execution status table to make sure the job ran successfully.

Customizing the Rapid MartRapid Marts are easy to customize. You can easily:• Customize the Rapid Mart data schema to meet your specific needs.• Expand the Rapid Mart to be used with various integrated query,

reporting, and data analysis applications.


Using the Rapid Mart 6
• Transport Rapid Mart components and sections to different Rapid Marts
using the Data Integrator export and import facilities.For example, to customize the Rapid Mart, you might:• Change column names to be more meaningful in your business

environment.• Remove columns or tables you do not need in your business

environment.• Add:

• Columns from tables already sourced• New columns from tables not extracted • Aggregates• Calculated or scrubbed data

You change your Rapid Mart in exactly the same way you would change any Data Integrator application. For information about how to make such changes, see the Data Integrator product documentation.Note: In general, whenever you make a change, you need to perform impact analysis. Impacts to consider include: • Initial load• Incremental load• Target tables• Integrity of existing Rapid Mart data• Integrity between batch extraction and real time jobs• Downstream analysis and reporting and Web applications• Variable settings used by imported components and sections• Other Rapid Mart (in a multi-Rapid Mart environment) If you are implementing the Rapid Mart on Oracle 8i or Oracle 9i platforms, you can take advantage of pre-processing and post-processing performance tuning stored procedures described in “Fact table stored procedures” on page 109 and in the Rapid Mart Deployment Guide.


Using the Rapid Mart6


Technical Implementation

chapter

Technical ImplementationOverview7
Overview
This chapter provides technical details about how the BusinessObjects General Ledger Rapid Mart for PeopleSoft is implemented. This chapter describes each section and the work flows that run to load that section. The information in this chapter is particularly useful for readers who customize the General Ledger Rapid Mart for their use.This chapter discusses: • Journal Entry section• GL Balance section• Budget section• Dealing with NULL values• Fact table stored procedures

Journal Entry section The journal entry section of the General Ledger Rapid Mart stores actual financial transactions at line item level posted to the company general ledger.The Rapid Mart calls the C_JournalEntry_Section_PSF work flow to load journal entry dimension and fact tables from PeopleSoft. The following diagram shows the tables that the journal entry section loads.


Technical ImplementationJournal Entry section 7

Initial loadThe Rapid Mart uses the same algorithms for the initial load and incremental load of the journal entry fact table and also the dimension tables. The initial load job extracts a full snapshot of the appropriate PeopleSoft data without constraints on created or changed dates of the source records.The Rapid Mart runs the initial load when a variable $G_LOAD_TYPE is set to ‘FIRST’. (See “Batch configuration variables” on page 76 for descriptions of variables used to initialize jobs.)

Dimension table loadFirst, the section loads the required dimension components. If these dimensions have already been loaded during the current job, the job will not reload them. The section uses work flow components to load dimension tables

Work flow Description Tables loaded

C_AccountType_PSF General Ledger account category (Revenue, Expense, Liability, Asset, Equity)

ACCOUNT_TYPE

C_Account_PSF Account codes and descriptions ACCOUNT


Technical ImplementationJournal Entry section7

C_Affiliate_PSF Intercompany codes and descriptions AFFILIATEC_AltAccount_PSF Alternate account codes and descriptions ALTACCOUNTC_BusinessUnit_PSF Business unit codes and descriptions.

This workflow is shared with the PeopleSoft HR Rapid Mart

BUSINESS_UNIT

C_Company_PSF Company codes and descriptions. This workflow is shared with the PeopleSoft HR Rapid Mart

COMPANY

C_Currency_PSF Currency abbreviations and texts.This workflow is shared with the PeopleSoft HR Rapid Mart

CURRENCY

C_TimeDim_PSF Generated time periods with PeopleSoft calendar parameters with a granularity of a calendar day. Besides creating TIME_DIMENSION this work flow also creates MONTH_DIMENSION and FISCAL_CALENDAR at a monthly granularity. This workflow is shared with the PeopleSoft HR Rapid Mart

TIME_DIMENSION,MONTH_DIMENSION,FISCAL_CALENDAR

C_Department_PSF Department codes and descriptions. This workflow is shared with the PeopleSoft HR Rapid Mart

DEPARTMENT

C_Ledger_PSF Ledger codes and descriptions. LEDGERC_OperatingUnit_PSF Operating Unit codes and descriptions OPERATING_UNITC_Product_PSF Product codes and descriptions. PRODUCTC_Project_PSF Project codes and descriptions PROJECTC_Scenario_PSF Budget scenario codes and descriptions SCENARIOC_Source_PSF Journal source codes and descriptions SOURCE




The Rapid Mart is based upon using surrogate keys for dimension dimension table-fact table joins. Surrogate keys provide processing efficiency when linking dimension tables to fact tables in a star schema. These surrogate keys are created when dimension tables are built and the keys are looked up and inserted into the target fact table when it is created.The PeopleSoftGeneral Ledger Rapid Mart has complications linking dimension tables to fact tables due to the usage of the PeopleSoft SETID feature.. Unique codes in certain dimensions are only achieved by a combination of the dimension code field and SETID; as it is possible to use the same dimension natural key code a number of times against different SETID’s. SETID is related to Business Unit to enable the same dimension codes to be set up with different attributes depending upon which Business Unit the code is associated with. The fact tables do not require a SETID because the Business Unit identifier exists, with the result that unless the

C_Statistic_PSF Statistic account codes and descriptions STATISTICC_GLHierarchy_PSF Vertically, parent/child and horizontally

flattened hierarchy for Account, AltAccount, Department, Operating Unit and Product

ACCOUNT_HIER_PCACCOUNT_HIER_HZACCOUNT_HIER_VRALTACCOUNT_HIER_PCALTACCOUNT_HIER_HZALTACCOUNT_HIER_VRDEPARTMENT_HIER_PCDEPARTMENT_HIER_HZDEPARTMENT_HIER_VROPERATING_UNIT_HIER_PCOPERATING_UNIT_HIER_HZOPERATING_UNIT_HIER_VRPRODUCT_HIER_PCPRODUCT_HIER_HZPRODUCT_HIER_VR




Business Unit is decoded to its related SETID, multiple or incorrect dimension code look ups would result. The PeopleSoft source table PS_SET_CNTRL_REC contains the relationships between each dimension table SETID and Business Unit and this table must be looked up to determine the correct dimension code to insert in the target fact table.. Because the PeopleSoftGeneral Ledger Rapid Mart uses surrogate keys PS_SET_CNTRL_REC is used as a integral part of the surrogate key lookup for relevant dimensions. The dimensions affected by the control table lookup for Journal Entry (i.e. those that incorporate a SETID column in the dimension) are as follows:• ACCOUNT• ACCOUNT_TYPE• ALTACCOUNT• COMPANY• DEPARTMENT• LEDGER• OPERATING_UNIT• PRODUCT• PROJECT• SCENARIO• SOURCE• STATISTIC



The SQL required to determine the dimension surrogate key for each of the above dimensions has a degree of complexity. The SETID/Business Unit relationship must be derived from looking up Business Unit in the fact table record in the PS_SET_CNTRL_REC table. Owing to this complexity it has been necessary to build the relevant lookup_ext() function using the Custom SQL feature.. The custom SQL creates a virtual table of all the SETID/Business Unit combinations possible for the dimension lookup in question. This table is then filtered by the Business Unit for the fact table record within the body of the lookup_ext() function to provide the correct dimension surrogate key.An example of this lookup_ext() custom SQL can be found in the Account dimension lookup as follows:

SELECT ACCOUNT.EFFDT ,PS_SET_CNTRL_REC.SETCNTRLVALUE DESCRSHORT ,ACCOUNT.TO_EFFDT ,ACCOUNT.ACCOUNT_KEY ,ACCOUNT.ACCOUNT FROM PS_SET_CNTRL_REC, ACCOUNTWHERE ACCOUNT.SETID = PS_SET_CNTRL_REC.SETIDAND PS_SET_CNTRL_REC.RECNAME = \'GL_ACCOUNT_TBL\'

The list of possible Business Units for an account code is returned in the DESCRSHORT column of the SQL and is filtered against Business Unit in the condition section of the lookup_ext() dialog:DESCRSHORT = STAGE_JOURNAL_FACT.BUSINESS_UNIT



The following diagram details the lookup_ext() dialog and Custom Code for the ACCOUNT_KEY lookup.



The SETID lookup code is handled in a very similar manner for all affected dimensions as for the Account example. Sometimes the DESCR column is used in the Business Unit filter condition rather than DESCRSHORT as it is a prerequisite of the custom SQL that the translate table chosen must contain the columns specified in the custom SQL. For this reason care must be taken when customising the Rapid Mart to ensure that all the columns referred to in the lookup_ext() custom SQL still exist in each of the dimension tables otherwise errors will occur when running the fact table load.Two dimension lookups are similar but not exactly the same as the account example listed above. Company does not exist in thePeopleSoft fact table and therefore has to be sourced from DEPARTMENT. The SETID code combination therefore belongs to DEPARTMENT rather than COMPANY. As a result, the Company custom SQL uses DEPARTMENT as the translate table but returns COMPANY_KEY rather than DEPARTMENT_KEY.Like Company, the Account Type dimension has no column in the PeopleSoft fact table but can be referred to via the Account dimension table. This lookup is further complicated by it not being possible to hold the ACCOUNT_TYPE_KEY in ACCOUNT as no other attribute of ACCOUNT_TYPE can be determined from the Account dimension. This lookup is resolved by linking ACCOUNT to ACCOUNT_TYPE and joining PS_SET_CNTRL_REC to itself. The Business Unit/SETID relationship can then be identified in the same way as before to allow lookup_ext() to return ACCOUNT_TYPE_KEY:

SELECT ACCOUNT_TYPE.ACCOUNT_TYPE_KEY ,ACCOUNT.ACCOUNT DESCR ,AT.SETCNTRLVALUE DESCRSHORT FROM PS_SET_CNTRL_REC A, PS_SET_CNTRL_REC AT, ACCOUNT_TYPE , ACCOUNTWHERE ACCOUNT_TYPE.SETID = AT.SETIDAND ACCOUNT.SETID = A.SETIDAND A.SETCNTRLVALUE = AT.SETCNTRLVALUEAND ACCOUNT.ACCOUNT_TYPE = ACCOUNT_TYPE.ACCOUNT_TYPEAND A.RECNAME = \'GL_ACCOUNT_TBL\'AND AT.RECNAME = \'ACCT_TYPE_TBL\'

The Rapid Mart extracts PeopleSoft tree parent-child relationships using the DI PeopleSoft suppliment hierarchy handling feature.. Hierarchies are created for Account, Alternate Accounts, Department, Operating Unit and Product presented in a horizontal and vertical formats:• ACCOUNT_HZ, ACCOUNT_VR• ALTACCOUNT_HZ, ALTACCOUNT_VR• DEPARTMENT_HZ, DEPARTMENT_VR



• OPERATING_UNIT_HZ, OPERATING_UNIT_VR• PRODUCT_HZ, PRODUCT_VRNOTE: PeopleSoft hierarchies allow for a single child node to have multiple parent nodes. When horizontally flattened, they can produce as many similar Current Leaf record identifiers for as many parents the child node has. When using the hierachies for reporting, make sure you select the correct relationship.For more details on extraction logic for dimensions see annotations and object descriptions in the Rapid Mart WF_JournalEntry_Dims_PSF workflow.

Fact table loadAfter loading the dimensions, the work flow determines whether you are loading the JOURNAL_FACT table for the first time. If you are, the Rapid Mart executes the initial load work flow. If not, the Rapid Mart executes the incremental load work flow. The initial load job extracts the journal entry header and line item source data from the PeopleSoft tables. Constraints are set to get only actual posted transactions :PS_JRNL_LN.BUSINESS_UNIT = PS_JRNL_HEADER.BUSINESS_UNIT AND PS_JRNL_LN.JOURNAL_ID = PS_JRNL_HEADER.JOURNAL_ID AND PS_JRNL_LN.JOURNAL_DATE = PS_JRNL_HEADER.JOURNAL_DATE AND PS_JRNL_LN.UNPOST_SEQ = PS_JRNL_HEADER.UNPOST_SEQ AND$G_SDATE <= PS_JRNL_LN.JOURNAL_DATE AND$G_EDATE >= PS_JRNL_LN.JOURNAL_DATE AND PS_JRNL_HEADER.JRNL_HDR_STATUS = 'P' The journal entry fact table is loaded in TRUNCATE mode.A Staging table is used to separate the source PeopleSoft data extraction mechanism from the surrogate key lookup feature. This method maintains data extraction and transformation independence to ensure processing efficiency.



Incremental load

Load dimension tablesAll dimensions excluding the time dimensions are delta loaded based upon a table comparison between the current dimension source information and the dimension records previously loaded. The time dimensions are always fully re-loaded. Note that hierarchy tables are fully recalculated during delta runs.

Load fact tableThe same staging table methodology employed by the standard fact table load is used when loading data incrementally. The following algorithm is used to populate JOURNAL_FACT during incremental loads:1. A staging table STAGE_JOURNAL_FACT is loaded in TRUNCATE mode

with results of a 2-way inner-join where the journal entry header table ‘journal date’ field has the following constraint:$G_SDATE <= JOURNAL_DATE AND $G_EDATE >= JOURNAL_DATE

2. STAGE_JOURNAL_FACT is used as the input to renaming functions where the lookup_ext() function is used to determine the surrogate key identifier from each dimension table.

PeopleSoft does not allow deletion of financial transactions once they are entered into the system. The Rapid Mart does not support tracing journal entries that can be physically deleted from the source system.


Technical ImplementationGL Balance section7
GL Balance section
This section of the General Ledger Rapid Mart stores GL balance amounts for General Ledger detail accounts.The Rapid Mart calls the C_GLBalance_Section_PSF work flow to load balances dimension and fact tables from PeopleSoft. The following diagram shows the tables that the balances section loads.

Initial loadThe Rapid Mart uses the same algorithms for the initial load and incremental load of the GL balances fact table and also the dimension tables. The initial load job extracts a full snapshot of the appropriate PeopleSoft data without constraints on created or changed dates of the source records.The Rapid Mart runs the initial load when a variable $G_LOAD_TYPE is set to ‘FIRST’. (See “Batch configuration variables” on page 76 for descriptions of variables used to initialize jobs.)


Technical ImplementationGL Balance section 7

Dimension table loadFirst, the section loads the required dimension components. If these dimensions have already been loaded during the current job, the job will not reload them. The section uses work flow components to load dimension tables


C_AccountType_PSF

General Ledger account category (Revenue, Expense, Liability, Asset, Equity)

ACCOUNT_TYPE

C_Account_PSF Account codes and descriptions ACCOUNTC_Affiliate_PSF Intercompany codes and descriptions AFFILIATEC_AltAccount_PSF Alternate account codes and

descriptionsALTACCOUNT

C_BusinessUnit_PSF

Business unit codes and descriptions. This workflow is shared with the PeopleSoft HR Rapid Mart

BUSINESS_UNIT


COMPANY


CURRENCY



C_Department_PSF

Department codes and descriptions. This workflow is shared with the PeopleSoft HR Rapid Mart

DEPARTMENT

C_Ledger_PSF Ledger codes and descriptions. LEDGERC_OperatingUnit_PSF

Operating Unit codes and descriptions OPERATING_UNIT

C_Product_PSF Product codes and descriptions. PRODUCTC_Project_PSF Project codes and descriptions PROJECT



The Rapid Mart is based upon using surrogate keys for dimension dimension table-fact table joins. Surrogate keys provide processing efficiency when linking dimension tables to fact tables in a star schema. These surrogate keys are created when dimension tables are built and the keys are looked up and inserted into the target fact table when it is created.The PeopleSoftGeneral Ledger Rapid Mart has complications linking dimension tables to fact tables due to the usage of the PeopleSoft SETID feature.. Unique codes in certain dimensions are only achieved by a combination of the dimension code field and SETID; as it is possible to use the same dimension natural key code a number of times against different SETID’s. SETID is related to Business Unit to enable the same dimension codes to be set up with different attributes depending upon which Business Unit the code is associated with. The fact tables do not require a SETID because the Business Unit identifier exists, with the result that unless the Business Unit is decoded to its related SETID, multiple or incorrect dimension code look ups would result. The PeopleSoft source table PS_SET_CNTRL_REC contains the relationships between each dimension table SETID and Business Unit and this table must be looked up to determine the correct dimension code to insert in the target fact table.. Because the PeopleSoftGeneral Ledger Rapid Mart uses surrogate keys PS_SET_CNTRL_REC is used as a integral part of the surrogate key lookup

C_Statistic_PSF Statistic account codes and descriptions STATISTICC_GLHierarchy_PSF

Vertically, parent/child and horizontally flattened hierarchy for Account, AltAccount, Department, Operating Unit and Product





for relevant dimensions. The dimensions affected by the control table lookup for GL Balances (i.e. those that incorporate a SETID column in the dimension) are as follows:• ACCOUNT• ACCOUNT_TYPE• ALTACCOUNT• COMPANY• DEPARTMENT• LEDGER• OPERATING_UNIT• PRODUCT• PROJECT• STATISTICThe SQL required to determine the dimension surrogate key for each of the above dimensions has a degree of complexity. The SETID/Business Unit relationship must be derived from looking up Business Unit in the fact table record in the PS_SET_CNTRL_REC table. Owing to this complexity it has been necessary to build the relevant lookup_ext() function using the Custom SQL feature.. The custom SQL creates a virtual table of all the SETID/Business Unit combinations possible for the dimension lookup in question. This table is then filtered by the Business Unit for the fact table record within the body of the lookup_ext() function to provide the correct dimension surrogate key.An example of this lookup_ext() custom SQL can be found in the Account dimension lookup as follows:


The list of possible Business Units for an account code is returned in the DESCRSHORT column of the SQL and is filtered against Business Unit in the condition section of the lookup_ext() dialog:DESCRSHORT = STAGE_LEDGER_FACT.BUSINESS_UNIT



• OPERATING_UNIT_HZ, OPERATING_UNIT_VR• PRODUCT_HZ, PRODUCT_VRNOTE: PeopleSoft hierarchies allow for a single child node to have multiple parent nodes. When horizontally flattened, they can produce as many similar Current Leaf record identifiers for as many parents the child node has. When using the hierachies for reporting, make sure you select the correct relationship.For more details on extraction logic for dimensions see annotations and object descriptions in the Rapid Mart WF_GLBalance_Dims_PSF workflow.

Fact table loadAfter loading the dimensions, the work flow determines whether you are loading the LEDGER_FACT table for the first time. If you are, the Rapid Mart executes the initial load work flow. If not, the Rapid Mart executes the incremental load work flow. The initial load job extracts the balance records from the PeopleSoft transactional table..

Incremental load


Load fact tableThe same staging table methodology employed by the standard fact table load is used when loading data incrementally. The following algorithm is used to populate LEDGER_FACT during incremental loads:1. A staging table STAGE_LEDGER_FACT is loaded in TRUNCATE mode

using the following constraint:$G_SDATE <= DTTM_STAMP_SEC AND $G_EDATE >= DTTM_STAMP_SEC

2. STAGE_LEDGER_FACT is used as the input to renaming functions where the lookup_ext() function is used to determine the surrogate key identifier from each dimension table.


Technical ImplementationBudget section 7


Budget sectionThis section of General Ledger Rapid Mart stores budget amounts for General Ledger detail accounts

Initial loadThe Rapid Mart uses the same algorithms for the initial load and incremental load of the budget fact table and also the dimension tables. The initial load job extracts a full snapshot of the appropriate PeopleSoft data without constraints on created or changed dates of the source records.The Rapid Mart runs the initial load when a variable $G_LOAD_TYPE is set to ‘FIRST’. (See “Batch configuration variables” on page 76 for descriptions of variables used to initialize jobs.)


Technical ImplementationBudget section7
Dimension table load
First, the section loads the required dimension components. If these dimensions have already been loaded during the current job, the job will not reload them. The section uses work flow components to load dimension tables


C_AccountType_PSF General Ledger account category (Revenue, Expense, Liability, Asset, Equity)

ACCOUNT_TYPE

C_Account_PSF Account codes and descriptions ACCOUNTC_Affiliate_PSF Intercompany codes and descriptions AFFILIATEC_AltAccount_PSF Alternate account codes and descriptions ALTACCOUNTC_BusinessUnit_PSF

Business unit codes and descriptions. This workflow is shared with the PeopleSoft HR Rapid Mart

BUSINESS_UNIT


COMPANY


CURRENCY



C_Department_PSF Department codes and descriptions. This workflow is shared with the PeopleSoft HR Rapid Mart

DEPARTMENT

C_Ledger_PSF Ledger codes and descriptions. LEDGERC_OperatingUnit_PSF

Operating Unit codes and descriptions OPERATING_UNIT

C_Product_PSF Product codes and descriptions. PRODUCTC_Project_PSF Project codes and descriptions PROJECTC_Scenario_PSF Budget scenario codes and descriptions SCENARIO



The Rapid Mart is based upon using surrogate keys for dimension dimension table-fact table joins. Surrogate keys provide processing efficiency when linking dimension tables to fact tables in a star schema. These surrogate keys are created when dimension tables are built and the keys are looked up and inserted into the target fact table when it is created.The PeopleSoftGeneral Ledger Rapid Mart has complications linking dimension tables to fact tables due to the usage of the PeopleSoft SETID feature.. Unique codes in certain dimensions are only achieved by a combination of the dimension code field and SETID; as it is possible to use the same dimension natural key code a number of times against different SETID’s. SETID is related to Business Unit to enable the same dimension codes to be set up with different attributes depending upon which Business Unit the code is associated with. The fact tables do not require a SETID because the Business Unit identifier exists, with the result that unless the Business Unit is decoded to its related SETID, multiple or incorrect dimension code look ups would result. The PeopleSoft source table PS_SET_CNTRL_REC contains the relationships between each dimension table SETID and Business Unit and this table must be looked up to determine the correct dimension code to insert in the target fact

C_Statistic_PSF Statistic account codes and descriptions STATISTICC_GLHierarchy_PSF Vertically, parent/child and horizontally

flattened hierarchy for Account, AltAccount, Department, Operating Unit and Product





table.. Because the PeopleSoftGeneral Ledger Rapid Mart uses surrogate keys PS_SET_CNTRL_REC is used as a integral part of the surrogate key lookup for relevant dimensions. The dimensions affected by the control table lookup for Budgets (i.e. those that incorporate a SETID column in the dimension) are as follows:• ACCOUNT• ACCOUNT_TYPE• ALTACCOUNT• COMPANY• DEPARTMENT• LEDGER• OPERATING_UNIT• PRODUCT• PROJECT• SCENARIO• STATISTICThe SQL required to determine the dimension surrogate key for each of the above dimensions has a degree of complexity. The SETID/Business Unit relationship must be derived from looking up Business Unit in the fact table record in the PS_SET_CNTRL_REC table. Owing to this complexity it has been necessary to build the relevant lookup_ext() function using the Custom SQL feature.. The custom SQL creates a virtual table of all the SETID/Business Unit combinations possible for the dimension lookup in question. This table is then filtered by the Business Unit for the fact table record within the body of the lookup_ext() function to provide the correct dimension surrogate key.An example of this lookup_ext() custom SQL can be found in the Account dimension lookup as follows:


The list of possible Business Units for an account code is returned in the DESCRSHORT column of the SQL and is filtered against Business Unit in the condition section of the lookup_ext() dialog:DESCRSHORT = STAGE_BUDGET_FACT.BUSINESS_UNIT



• OPERATING_UNIT_HZ, OPERATING_UNIT_VR• PRODUCT_HZ, PRODUCT_VRNOTE: PeopleSoft hierarchies allow for a single child node to have multiple parent nodes. When horizontally flattened, they can produce as many similar Current Leaf record identifiers for as many parents the child node has. When using the hierachies for reporting, make sure you select the correct relationship.For more details on extraction logic for dimensions see annotations and object descriptions in the Rapid Mart WF_Budget_Dims_PSF workflow.

Fact table loadAfter loading the dimensions, the work flow determines whether you are loading the BUDGET_FACT table for the first time. If you are, the Rapid Mart executes the initial load work flow. If not, the Rapid Mart executes the incremental load work flow. The initial load job extracts the balance records from the PeopleSoft transactional table..

Incremental load


Load fact tableThe same staging table methodology employed by the standard fact table load is used when loading data incrementally. The following algorithm is used to populate BUDGET_FACT during incremental loads:1. A staging table STAGE_BUDGET_FACT is loaded in TRUNCATE mode

using the following constraint:$G_SDATE <= DTTM_STAMP_SEC AND $G_EDATE >= DTTM_STAMP_SEC

2. STAGE_BUDGET_FACT is used as the input to renaming functions where the lookup_ext() function is used to determine the surrogate key identifier from each dimension table.


Technical ImplementationDealing with NULL values7


Dealing with NULL valuesAs the first step in data cleansing, the BusinessObjects General Ledger Rapid Mart for PeopleSoft allows replacing NULL values found in the source system with configurable default ‘not-null’ values.The General Ledger Rapid Mart provides three category of default values to treat NULLs:• For columns that behave as a foreign key the General Ledger Rapid Mart

replaces NULL value with a global variable $G_DEFAULT_NUMBER of data type integer;

• For columns that store descriptions NULLs are replaced with $G_DEFAULT_TEXT of data type char(1);

• For columns that store dates NULLs are replaced with $G_DEFAULT_DATE of data type DATE.

Dimensions whose corresponding foreign keys in the fact tables can have value NULL are loaded with an additional ‘dummy’ row to represent NULL. The value of $G_DEFAULT_NUMBER global variable gets inserted into each dimension primary key column.

Fact table stored proceduresWhen loading each fact table the Rapid Mart calls two stored procedures. A PREPROCESSING_FACT_TABLE procedure is called before loading the fact table and a POSTPROCESSING_FACT_TABLE procedure is called when the load is finished. The procedures are automatically installed by the Rapid Mart only as placeholders:

CREATE OR REPLACE PROCEDURE postprocessing_fact_table(pLoadType IN VARCHAR2, pDropCreateIndex IN VARCHAR2, pFactTable IN VARCHAR2, pMView_Failures OUT BINARY_INTEGER) IS

BEGIN NULL;END postprocessing_fact_table;CREATE OR REPLACE PROCEDURE preprocessing_fact_table(pLoadType IN

VARCHAR2, pDropCreateIndex IN VARCHAR2, pFactTable IN VARCHAR2) IS

BEGIN NULL;


Technical Implementation 7
END preprocessing_fact_table;
In order to use these procedures as a performance tuning tool, you need to customize them. The Rapid Mart provides a sample script Create_Sample_Maintenance_SP.sql with necessary modifications. The PREPROCESSING_FACT_TABLE Oracle stored procedure defined in the sample script will drop all indexes and all materialized view logs enabled and POSTPROCESSING_FACT_TABLE will recreate them. See the Rapid Mart Deployment Guide for details.


Technical Implementation7


Rapid Mart Data Schema

appendix

Rapid Mart Data SchemaOverviewA
Overview
This appendix provides detailed information about the tables and views in the BusinessObjects General Ledger Rapid Mart for PeopleSoft. This information applies to an Oracle target datastore.

Fact tables in the Rapid Mart• JOURNAL_FACT• BUDGET_FACT• LEDGER_FACT

Dimension tables in the Rapid Mart• ACCOUNT• ACCOUNT_TYPE• AFFILIATE• ALTACCOUNT• BUSINESS_UNIT• COMPANY• CURRENCY• DEPARTMENT• FISCAL_CALENDAR• LEDGER• MONTH_DIMENSION• OPERATING_UNIT• PRODUCT• PROJECT• SCENARIO• SOURCE• STATISTIC• TIME_DIMENSION


Rapid Mart Data SchemaOther tables in the Rapid Mart A

Other tables in the Rapid Mart• ACCOUNT_HIER_HZ• ACCOUNT_HIER_PC• ACCOUNT_HIER_VR• ALTACCOUNT_HIER_HZ• ALTACCOUNT_HIER_PC• ALTACCOUNT_HIER_VR• DEPARTMENT_HIER_HZ• DEPARTMENT_HIER_PC• DEPARTMENT_HIER_VR• OPERATING_UNIT_HIER_HZ• OPERATING_UNIT_HIER_PC• OPERATING_UNIT_HIER_VR• PRODUCT_HIER_HZ• PRODUCT_HIER_PC• PRODUCT_HIER_VR• STAGE_BUDGET_FACT• STAGE_JOURNAL_FACT• STAGE_LEDGER_FACT• TEMP_DEPARTMENT

ACCOUNTDimension with Account attributes

Column name Key Data type Column description

ACCOUNT_KEY PK VARCHAR2(30) Surrogate key to ACCOUNTSETID VARCHAR2(15) SetID is used to differentiate between

Account values that belong to different Business Units

ACCOUNT VARCHAR2(30) Account codeEFFDT DATETIME Effective from dateEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Account long description


Rapid Mart Data SchemaACCOUNT_HIER_HZA

Note: The BSHEET_IND_DESCR column does not exist in PeopleSoft 8.0 but exists in versions 8.4 and 8.8. To ensure this rapid mart works in PeopleSoft 8.0 upwards the column is set to NULL in dataflow DF_Account_PSF. If PeopleSoft 8.04 or 8.8 are implemented the domain feature can be used to return the balance sheet indicator description by assigning ‘get_domain_description(PSF_DS."".BAL_SHEET_IND, Effective_Date_2.BAL_SHEET_IND)’ to the BSHEET_IND_DESCR column.

ACCOUNT_HIER_HZNatural Account key horizontally flattened hierarchy.

DESCRSHORT VARCHAR2(30) Account short descriptionUNIT_OF_MEASURE VARCHAR2(9) Account short descriptionCURRENCY_CD VARCHAR2(9) Account currency codeSTATISTICS_ACCOUNT

VARCHAR2(3) Statistics account indicator

BALANCE_FWD_SW VARCHAR2(3) Account balance forward indicatorTO_EFFDT DATETIME Effective to dateACCOUNT_TYPE VARCHAR2(3) Account typeBSHEET_IND_DESCR VARCHAR2(30) Balance sheet indicatorVAT_ACCT_FLG_DESCR

VARCHAR2(30) VAT account description

CURRENT_IND VARCHAR2(1) Effective date current date indicatorLOAD_DATE DATETIME Date and Time when the record was

loaded into target systemLOAD_TIME VARCHAR2(8) Time when the record was loaded into the

target system



SETID PK VARCHAR2(10) SetID is used to differentiate between Account values that belong to different Business Units

ACCOUNT PK VARCHAR2(30) Current leaf Account valueEFFECTIVE_FM_DT PK DATE Effective from dateEFFECTIVE_TO_DT DATE Effective to date


Rapid Mart Data SchemaACCOUNT_HIER_HZ A

CURRENT_STATUS VARCHAR2(1) Effective date current date indicatorLEAF_LEVEL NUMBER Leaf level in horizontal flatteningMAXDEPTH NUMBER Maximum depth of hierarchyLEVEL0_ACCOUNT VARCHAR2(30) Level0 (root) value for the current leaf of

AccountLEVEL0_ACCOUNT_KEY

NUMBER Level0 (root) surrogate key for the current leaf of Account

LEVEL0_DESCRIPTION VARCHAR2(90) Level0 (root) description for the current leaf of Account

LEVEL1_ACCOUNT VARCHAR2(30) Level1 value for the current leaf of Account

LEVEL1_ACCOUNT_KEY

NUMBER Level1 surrogate key for the current leaf of Account

LEVEL1_DESCRIPTION VARCHAR2(90) Level1 description for the current leaf of Account


LEVEL2_ACCOUNT_KEY




LEVEL3_ACCOUNT_KEY




LEVEL4_ACCOUNT_KEY






Rapid Mart Data SchemaACCOUNT_HIER_PCA

ACCOUNT_HIER_PCNatural Account key parent/child relationship hierarchy

LEVEL5_ACCOUNT_KEY




LEVEL6_ACCOUNT_KEY




LEVEL7_ACCOUNT_KEY




LEVEL8_ACCOUNT_KEY



LOAD_DATE DATETIME Date and Time when the record was loaded into target system

LOAD_TIME VARCHAR2(8) Time when the record was loaded into the target system



ACCOUNT_KEY NUMBER Surrogate key to child AccountSETID PK VARCHAR2(1

5)SetID is used to differentiate between Account values that belong to different Business Units


Rapid Mart Data SchemaACCOUNT_HIER_VR A

ACCOUNT_HIER_VRNatural Account key vertically flattened hierarchy

ACCOUNT PK VARCHAR2(30)

Child Account

DESCRIPTION VARCHAR2(90)

Child Account description

EFFECTIVE_FM_DT PK DATE Effective from dateEFFECTIVE_TO_DT DATE Effective to dateCURRENT_STATUS VARCHAR2(1

)Effective date current date indicator

PARENT_ACCOUNT_KEY NUMBER Parent Account surrogate keyPARENT_ACCOUNT VARCHAR2(3

0)Parent Account

PARENT_DESCRIPTION VARCHAR2(90)

Parent Account description


LOAD_TIME VARCHAR2(8)

Time when the record was loaded into the target system



SETID PK VARCHAR2(15)

SetID is used to differentiate between Account values that belong to different Business Units

ANCESTOR_ACCOUNT PK VARCHAR2(30)

Ancestor Account code

DESCENDENT_ACCOUNT PK VARCHAR2(30)

Descendent Account code



MAXDEPTH NUMBER Maximum depth of hierarchyDEPTH NUMBER Depth of the descendent


Rapid Mart Data SchemaACCOUNT_TYPEA

ACCOUNT_TYPE Dimension with Account Type attributes

ROOT_FLAG NUMBER Root flag (1 means this is a root)LEAF_FLAG NUMBER Leaf flag (1 means this is a leaf)TREELEVEL NUMBER Tree levelANCESTOR_ACCOUNT_KEY NUMBER Ancestor Account surrogate keyANCESTOR_ACCOUNT_DESCR

VARCHAR2(90)

Ancestor Account description

DESCENDENT_ACCOUNT_KEY

NUMBER Descendent Account surrogate key

DESCENDENT_ACCOUNT_DESCR

VARCHAR2(90)

Descendent Account description






ACCOUNT_TYPE_KEY PK NUMBER Surrogate key to ACCOUNT_TYPESETID VARCHAR2(15) SetID is used to differentiate between

Account Type values that belong to different Business Units

ACCOUNT_TYPE VARCHAR2(3) Account Type codeDESCR VARCHAR2(90) Account Type long descriptionDESCRSHORT VARCHAR2(30) Account Type short descriptionBALANCE_FWD_SW VARCHAR2(3) Account Type balance forward indicatorLOAD_DATE DATETIME Date and Time when the record was


target system


Rapid Mart Data SchemaAFFILIATE A

AFFILIATEDimension with inter-company attributes

ALTACCOUNTDimension with Alternate Account attributes


AFFILIATE_KEY PK NUMBER Surrogate key to AFFILIATEAFFILIATE VARCHAR2(15) Affiliate codeDESCR VARCHAR2(90) Affiliate long descriptionDESCRSHORT VARCHAR2(30) Affiliate short descriptionLOAD_DATE DATETIME Date and Time when the record was


target system


ALTACCOUNT_KEY PK NUMBER Surrogate key to ALTACCOUNTSETID VARCHAR2(15) SetID is used to differentiate between

Alternate Account values that belong to different Business Units

ALTACCOUNT VARCHAR2(30) Alternate account codeEFFDT DATETIME Effective from dateEFF_STATUS VARCHAR2(1) Effective StatusDESCR VARCHAR2(90) Alternate account long descriptionDESCRSHORT VARCHAR2(30) Alternate account short descriptionUNIT_OF_MEASURE VARCHAR2(9) Unit of measureSTATISTICS_ACCOUNT

VARCHAR2(3) Statistics account indicator

BALANCE_FWD_SW VARCHAR2(3) Alternate account balance forward indicator

BSHEET_IND_DESCR VARCHAR2(30) Balance sheet indicatorACCOUNT_TYPE VARCHAR2(3) Account typeTO_EFFDT DATETIME Effective to date


Rapid Mart Data SchemaALTACCOUNT_HIER_HZA

Note: The BSHEET_IND_DESCR column does not exist in PeopleSoft 8.0 but exists in versions 8.4 and 8.8. To ensure this rapid mart works in PeopleSoft 8.0 upwards the column is set to NULL in dataflow DF_AltAccount_PSF. If PeopleSoft 8.04 or 8.8 are implemented the domain feature can be used to return the balance sheet indicator description by assigning ‘get_domain_description(PSF_DS."".BAL_SHEET_IND, Effective_Date_2.BAL_SHEET_IND)’ to the BSHEET_IND_DESCR column.

ALTACCOUNT_HIER_HZNatural Alternate Account key horizontally flattened hierarchy.


loaded into target systemLOAD_TIME VARCHAR2(8) Time when the record was loaded into

the target system



SETID PK VARCHAR2(10) SetID is used to differentiate between Alternate Account values that belong to different Business Units

ALTACCOUNT PK VARCHAR2(30) Current leaf Alternate Account valueEFFECTIVE_FM_DT PK DATE Effective from dateEFFECTIVE_TO_DT DATE Effective to dateCURRENT_STATUS VARCHAR2(1) Effective date current date indicatorLEAF_LEVEL NUMBER Leaf level in horizontal flatteningMAXDEPTH NUMBER Maximum depth of hierarchyLEVEL0_ALTACCOUNT VARCHAR2(30) Level0 (root) value for the current leaf of

Alternate AccountLEVEL0_ALTACCOUNT_KEY

NUMBER Level0 (root) surrogate key for the current leaf of Alternate Account

LEVEL0_DESCRIPTION VARCHAR2(90) Level0 (root) description for the current leaf of Alternate Account

LEVEL1_ALTACCOUNT VARCHAR2(30) Level1 value for the current leaf of Alternate Account


Rapid Mart Data SchemaALTACCOUNT_HIER_HZ A

LEVEL1_ALTACCOUNT_KEY

NUMBER Level1 surrogate key for the current leaf of Alternate Account

LEVEL1_DESCRIPTION VARCHAR2(90) Level1 description for the current leaf of Alternate Account
























Rapid Mart Data SchemaALTACCOUNT_HIER_PCA

ALTACCOUNT_HIER_PCNatural Alternate Account key parent/child relationship hierarchy












ALTACCOUNT_KEY NUMBER Surrogate key to child Alternate Account


SetID is used to differentiate between Alternate Account values that belong to different Business Units

ALTACCOUNT PK VARCHAR2(30)

Child Alternate Account


Child Alternate Account description



PARENT_ALTACCOUNT_KEY

NUMBER Parent Alternate Account surrogate key

PARENT_ALTACCOUNT VARCHAR2(30)

Parent Alternate Account


Rapid Mart Data SchemaALTACCOUNT_HIER_VR A

ALTACCOUNT_HIER_VRNatural Alternate Account key vertically flattened hierarchy


Parent Alternate Account description







SetID is used to differentiate between Alternate Account values that belong to different Business Units

ANCESTOR_ALTACCOUNT PK VARCHAR2(30)

Ancestor Alternate Account code

DESCENDENT_ALTACCOUNT PK VARCHAR2(30)

Descendent Alternate Account code

EFFECTIVE_FM_DT PK DATE Effective from dateEFFECTIVE_TO_DT DATE Effective to dateCURRENT_STATUS VARCHAR2(1) Effective date current date indicatorMAXDEPTH NUMBER Maximum depth of hierarchyDEPTH NUMBER Depth of the descendentROOT_FLAG NUMBER Root flag (1 means this is a root)LEAF_FLAG NUMBER Leaf flag (1 means this is a leaf)TREELEVEL NUMBER Tree levelANCESTOR_ALTACCOUNT_KEY

NUMBER Ancestor Alternate Account surrogate key

ANCESTOR_ALTACCOUNT_DESCR

VARCHAR2(90)

Ancestor Alternate Account description

DESCENDENT_ALTACCOUNT_KEY

NUMBER Descendent Alternate Account surrogate key

DESCENDENT_ALTACCOUNT_DESCR

VARCHAR2(90)

Descendent Alternate Account description


Rapid Mart Data SchemaAW_JOBEXECUTIONA

AW_JOBEXECUTION Data Integrator internal table to trace job execution status

BUDGET_FACTGeneral Ledger Budget balances





NAME PK VARCHAR2(64) Job nameSTATUS VARCHAR2(12) Job run statusEXTRACTLOW VARCHAR2(10) Extract start dateEXTRACTHIGH VARCHAR2(10) Extract end date


BUSINESS_UNIT_KEY PK NUMBER Surrogate key to the BUSINESS_UNIT dimension table

LEDGER_KEY PK NUMBER Surrogate key to the LEDGER dimension table

ACCOUNT_KEY PK NUMBER Surrogate key to the ACCOUNT dimension table

ALTACCOUNT_KEY PK NUMBER Surrogate key to the ALTACCOUNT dimension table

DEPARTMENT_KEY PK NUMBER Surrogate key to the DEPARTMENT dimension table

OPERATING_UNIT_KEY

PK NUMBER Surrogate key to the OPERATING_UNIT dimension table

PRODUCT_KEY PK NUMBER Surrogate key to the PRODUCT dimension table

PROJECT_KEY PK NUMBER Surrogate key to the PROJECT dimension table


Rapid Mart Data SchemaBUDGET_FACT A

Note: The BUDGET_PERIOD column does not exist in PeopleSoft 8.0 but exists in versions 8.4 and 8.8. To ensure this rapid mart works in PeopleSoft 8.0 upwards the column is set to $G_DEFAULT_TEXT in dataflow DF_BudgetFact_Rename_PSF. If PeopleSoft 8.04 or 8.8 are implemented the BUDGET_FACT column can be assigned to the source table. in the two dataflows DF_BudgetFact_Stage_PSF and DF_BudgetFact_Rename_PSF.

AFFILIATE_KEY PK NUMBER Surrogate key to the AFFILIATE dimension table

SCENARIO_KEY PK NUMBER Surrogate key to the SCENARIO dimension table

CURRENCY_KEY PK NUMBER Surrogate key to the CURRENCY dimension table

STATISTIC_KEY PK NUMBER Surrogate key to the STATISTIC dimension table

BUDGET_PERIOD PK VARCHAR2(30) Budget periodFISCAL_YEAR PK NUMBER Fiscal Year of posted transactionACCOUNTING_PERIOD PK NUMBER Accounting Period of posted transactionCOMPANY_KEY NUMBER Surrogate key to the COMPANY

dimension tableACCOUNT_TYPE_KEY NUMBER Surrogate key to the ACCOUNT_TYPE

dimension tableTIME_KEY NUMBER Surrogate key to the TIME_DIMENSION

dimension tablePOSTED_TOTAL_AMT NUMBER Posted total amount in reporting currencyPOSTED_BASE_AMT NUMBER Posted total amount in base currencyPOSTED_TRAN_AMT NUMBER Posted total amount in local currencyBASE_CURRENCY_KEY

NUMBER Surrogate key to base currency

DTTM_STAMP_SEC DATETIME Date and time stamp of posted transaction





Rapid Mart Data SchemaBUSINESS_UNITA
BUSINESS_UNIT
Dimension with Business Unit attributes

COMPANYDimension with Company attributes


BUSINESS_UNIT_KEY PK NUMBER Surrogate key to BUSINESS_UNITBUSINESS_UNIT VARCHAR2(15) Business unit codeBASE_CURRENCY_KEY

NUMBER Base currency identifying key

DESCR VARCHAR2(90) Business unit long descriptionDESCRSHORT VARCHAR2(30) Business unit short descriptionLOAD_DATE DATETIME Date and Time when the record was

loadedLOAD_TIME VARCHAR2(8) Time in a string format when the

record was loaded


COMPANY_KEY PK NUMBER Surrogate key to COMPANYCOMPANY VARCHAR2(9) Company codeEFFDT DATETIME Effective from dateTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Effective date current date indicatorEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Company long descriptionDESCRSHORT VARCHAR2(30) Company short descriptionCOUNTRY VARCHAR2(9) Country codeGEO_CODE VARCHAR2(33) Geography codeLOAD_DATE DATETIME Date and Time when the record was


target system


Rapid Mart Data SchemaCURRENCY A

Note: The GEO_CODE column does not exist in PeopleSoft 8.0 but exists in versions 8.4 and 8.8. To ensure this rapid mart works in PeopleSoft 8.0 upwards the column is set to NULL in dataflow DF_Company_PSF. If PeopleSoft 8.04 or 8.8 are implemented the GEO_CODE column can be assigned to the source table.

CURRENCYDimension with Currency attributes

DEPARTMENTDimension with Department attributes


CURRENCY_KEY PK NUMBER Surrogate key to CURRENCYCURRENCY VARCHAR2(9) Currency codeEFFDT DATETIME Effective from dateTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Effective date current date indicatorEFF_STATUS VARCHAR2(3) Effective status (Active or Inactive)DESCR VARCHAR2(90) Currency long descriptionDESCRSHORT VARCHAR2(30) Currency short descriptionCOUNTRY VARCHAR2(9) Country codeCUR_SYMBOL VARCHAR2(12) Currency symbolLOAD_DATE DATETIME Date and Time when the record was


target system


DEPARTMENT_KEY PK NUMBER Surrogate key to DEPARTMENTSETID VARCHAR2(15) SetID is used to differentiate between

Department values that belong to different Business Units

DEPTID VARCHAR2(30) Department codeEFFDT DATETIME Effective from date


Rapid Mart Data SchemaDEPARTMENT_HIER_HZA

DEPARTMENT_HIER_HZNatural Department key horizontally flattened hierarchy.

TO_EFFDT DATETIME Effective to dateEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Department long descriptionDESCRSHORT VARCHAR2(30) Department short descriptionCOMPANY_KEY NUMBER Surrogate key to COMPANYLOCATION VARCHAR2(30) Departments locationLOCATION_KEY NUMBER Surrogate key to LOCATION (-1 in this

rapid mart. Used by PSFT HR rapid mart)

MANAGER_POSN VARCHAR2(24) Manager PositionMANAGER_NAME VARCHAR2(90) Manager NameBUDGET_DEPTID VARCHAR2(30) Controlling budget departmentMANAGER_POSITION_KEY

NUMBER Surrogate key to EMPLOYEE. (-1 in this rapid mart. Used by PSFT HR rapid mart)

MANAGER_EMPLOYEE_KEY

NUMBER Surrogate key to EMPLOYEE. (-1 in this rapid mart. Used by PSFT HR rapid mart)

BUDGET_DEPARTMENT_KEY

NUMBER Surrogate key to DEPARTMENT to identify budget department


loadedLOAD_TIME VARCHAR2(8) Time in a string format when the record

was loaded



SETID PK VARCHAR2(10) SetID is used to differentiate between Department values that belong to different Business Units

DEPTID PK VARCHAR2(30) Current leaf Department value


Rapid Mart Data SchemaDEPARTMENT_HIER_HZ A

EFFECTIVE_FM_DT PK DATE Effective from dateEFFECTIVE_TO_DT DATE Effective to dateCURRENT_STATUS VARCHAR2(1) Effective date current date indicatorLEAF_LEVEL NUMBER Leaf level in horizontal flatteningMAXDEPTH NUMBER Maximum depth of hierarchyLEVEL0_DEPTID VARCHAR2(30) Level0 (root) value for the current leaf of

DepartmentLEVEL0_DEPARTMENT_KEY

NUMBER Level0 (root) surrogate key for the current leaf of Department

LEVEL0_DESCRIPTION VARCHAR2(90) Level0 (root) description for the current leaf of Department

LEVEL1_DEPTID VARCHAR2(30) Level1 value for the current leaf of Department

LEVEL1_DEPARTMENT_KEY

NUMBER Level1 surrogate key for the current leaf of Department

LEVEL1_DESCRIPTION VARCHAR2(90) Level1 description for the current leaf of Department















Rapid Mart Data SchemaDEPARTMENT_HIER_HZA





















Rapid Mart Data SchemaDEPARTMENT_HIER_PC A

DEPARTMENT_HIER_PCNatural Department key parent/child relationship hierarchy

DEPARTMENT_HIER_VRNatural Department key vertically flattened hierarchy


DEPARTMENT_KEY NUMBER Surrogate key to child DepartmentSETID PK VARCHAR2(1

5)SetID is used to differentiate between Department values that belong to different Business Units

DEPTID PK VARCHAR2(30)

Child Department


Child Department description



PARENT_DEPARTMENT_KEY

NUMBER Parent Department surrogate key

PARENT_DEPTID VARCHAR2(30)

Parent Department


Parent Department description






SetID is used to differentiate between Department values that belong to different Business Units

DEPTID PK VARCHAR2(30)

Ancestor Department code


Rapid Mart Data SchemaFISCAL_CALENDARA

FISCAL_CALENDARTime dimension built with the monthly granularity of fiscal months

DESCENDENT_DEPTID PK VARCHAR2(30)

Descendent Department code



MAXDEPTH NUMBER Maximum depth of hierarchyDEPTH NUMBER Depth of the descendentROOT_FLAG NUMBER Root flag (1 means this is a root)LEAF_FLAG NUMBER Leaf flag (1 means this is a leaf)TREELEVEL NUMBER Tree levelDEPARTMENT_KEY NUMBER Ancestor Department surrogate keyDEPARTMENT VARCHAR2(9

0)Ancestor Department description

DESCENDENT_DEPARTMENT_KEY

NUMBER Descendent Department surrogate key

DESCENDENT_DEPARTMENT

VARCHAR2(90)

Descendent Department description






FISCAL_YEAR PK NUMBER Fiscal year. Used to link to FISCAL_YEAR of the fact tables.

ACCOUNTING_PERIOD PK NUMBER Accounting period. Used to link to ACCOUNTING_PERIOD of the fact tables.

PERIOD_NAME VARCHAR2(30) Period descriptionPERIOD_ABBRV VARCHAR2(30) Abbreviated period description


Rapid Mart Data SchemaJOURNAL_FACT A

JOURNAL_FACTGeneral Ledger journal header and line entries

CURRENT_FISCAL_YEAR

VARCHAR2(30) Current fiscal year indicator (Y or N)

CURRENT_ACCOUNTING_PERIOD

VARCHAR2(30) Current accounting period indicator (Y or N)






JOURNAL_ID PK VARCHAR2(30) Journal identifierJOURNAL_DATE PK DATETIME Journal entry dateUNPOST_SEQ PK NUMBER Unpost sequence numberJOURNAL_LINE PK NUMBER Journal entry line numberLEDGER_KEY PK NUMBER Surrogate key to the LEDGER dimension

tableACCOUNT_KEY NUMBER Surrogate key to the ACCOUNT

dimension tableALTACCOUNT_KEY NUMBER Surrogate key to the ALTACCOUNT

dimension tableDEPARTMENT_KEY NUMBER Surrogate key to the DEPARTMENT

dimension tableOPERATING_UNIT_KEY

NUMBER Surrogate key to the OPERATING_UNIT dimension table

PRODUCT_KEY NUMBER Surrogate key to the PRODUCT dimension table

PROJECT_KEY NUMBER Surrogate key to the PROJECT dimension table

AFFILIATE_KEY NUMBER Surrogate key to the AFFILIATE dimension table


Rapid Mart Data SchemaJOURNAL_FACTA

SCENARIO_KEY NUMBER Surrogate key to the SCENARIO dimension table

CURRENCY_KEY NUMBER Surrogate key to the CURRENCY dimension table

STATISTIC_KEY NUMBER Surrogate key to the STATISTIC dimension table

SOURCE_KEY NUMBER Surrogate key to the SOURCE dimension table

COMPANY_KEY NUMBER Surrogate key to the COMPANY dimension table

ACCOUNT_TYPE_KEY NUMBER Surrogate key to the ACCOUNT_TYPE dimension table

TIME_KEY NUMBER Surrogate key to the TIME_DIMENSION dimension table

MONETARY_AMOUNT NUMBER Jounral entry amountSTATISTIC_AMOUNT NUMBER Journal entry fro statistic accountsJRNL_LN_REF VARCHAR2(30) Journal entry line referenceLINE_DESCR VARCHAR2(90) Journal entry line descriptionJRNL_LINE_STATUS VARCHAR2(30) Journal entry line statusFOREIGN_CURRENCY VARCHAR2(9) Local currencyRT_TYPE VARCHAR2(15) Rate typeFOREIGN_AMOUNT NUMBER Journal entry local amountFISCAL_YEAR NUMBER Fiscal Year of posted transactionACCOUNTING_PERIOD NUMBER Accounting Period of posted transactionJRNL_EDIT_ERR_STAT VARCHAR2(30) Journal entry error status descriptionJRNL_HDR_STATUS VARCHAR2(30) Journal header statusLOAD_DATE DATETIME Date and Time when the record was


target system



Rapid Mart Data SchemaLEDGER A

LEDGERDimension with Ledger attributes

LEDGER_FACTGeneral Ledger balances


LEDGER_KEY PK NUMBER Surrogate key to LEDGERSETID VARCHAR2(15) SetID is used to differentiate between

Ledger values that belong to different Business Units

LEDGER VARCHAR2(30) Ledger codeDESCR VARCHAR2(90) Ledger descriptionEFFDT DATETIME Effective from dateTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Effective date current date indicatorLED_TYPE_DESCR VARCHAR2(30) Ledger type descriptionBUD_TYPE_DESCR VARCHAR2(30) Budget type descriptionLOAD_DATE DATETIME Date and Time when the record was


the target system



LEDGER_KEY PK NUMBER Surrogate key to the LEDGER dimension table

ACCOUNT_KEY PK NUMBER Surrogate key to the ACCOUNT dimension table

ALTACCOUNT_KEY PK NUMBER Surrogate key to the ALTACCOUNT dimension table

DEPARTMENT_KEY PK NUMBER Surrogate key to the DEPARTMENT dimension table


Rapid Mart Data SchemaLEDGER_FACTA

OPERATING_UNIT_KEY

PK NUMBER Surrogate key to the OPERATING_UNIT dimension table

PRODUCT_KEY PK NUMBER Surrogate key to the PRODUCT dimension table

PROJECT_KEY PK NUMBER Surrogate key to the PROJECT dimension table

AFFILIATE_KEY PK NUMBER Surrogate key to the AFFILIATE dimension table

CURRENCY_KEY PK NUMBER Surrogate key to the CURRENCY dimension table

STATISTIC_KEY PK NUMBER Surrogate key to the STATISTIC dimension table

FISCAL_YEAR PK NUMBER Fiscal Year of posted transactionACCOUNTING_PERIOD PK NUMBER Accounting Period of posted transactionCOMPANY_KEY NUMBER Surrogate key to the COMPANY

dimension tableACCOUNT_TYPE_KEY NUMBER Surrogate key to the ACCOUNT_TYPE

dimension tableTIME_KEY NUMBER Surrogate key to the TIME_DIMENSION

dimension tablePOSTED_TOTAL_AMT NUMBER Posted total amount in reporting currencyPOSTED_BASE_AMT NUMBER Posted total amount in base currencyPOSTED_TRAN_AMT NUMBER Posted total amount in local currencyBASE_CURRENCY_KEY

NUMBER Surrogate key to base currency

DTTM_STAMP_SEC DATETIME Date and time stamp of posted transaction





Rapid Mart Data SchemaMONTH_DIMENSION A

MONTH_DIMENSIONDimension that works in conjuction with TIME_DIMENSION to provide monthly granualarity of fact table data

OPERATING_UNITDimension with Operating Unit attributes


MONTH_KEY PK NUMBER Smart key in format ‘YYYYMM’. Used to link to MONTH_KEY in TIME_DIMENSION

MONTH NUMBER Calendar month numberQUARTER NUMBER Calendar quarter numberYEAR NUMBER YearLOAD_DATE DATETIME Date and Time when the record was


target system


OPERATING_UNIT_KEY

PK NUMBER(15) Surrogate key to OPERATING_UNIT

SETID VARCHAR2(15) SetID is used to differentiate between Operating Unit values that belong to different Business Units

OPERATING_UNIT VARCHAR2(24) Operating unit codeEFFDT DATETIME Effective from dateEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Operating unit long descriptionDESCRSHORT VARCHAR2(30) Operating unit short descriptionTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Effective date current date indicator


Rapid Mart Data SchemaOPERATING_UNIT_HIER_HZA

OPERATING_UNIT_HIER_HZNatural Operating Unit key horizontally flattened hierarchy.

LOAD_DATE DATETIME Date and Time when the record was loaded

LOAD_TIME VARCHAR2(8) Time in a string format when the record was loaded



SETID PK VARCHAR2(10) SetID is used to differentiate between Operating Unit values that belong to different Business Units

OPERUNIT PK VARCHAR2(30) Current leaf Operating Unit valueEFFECTIVE_FM_DT PK DATE Effective from dateEFFECTIVE_TO_DT DATE Effective to dateCURRENT_STATUS VARCHAR2(1) Effective date current date indicatorLEAF_LEVEL NUMBER Leaf level in horizontal flatteningMAXDEPTH NUMBER Maximum depth of hierarchyLEVEL0_OPERUNIT VARCHAR2(30) Level0 (root) value for the current leaf of

Operating Unit LEVEL0_OPERUNIT_KEY

NUMBER Level0 (root) surrogate key for the current leaf of Operating Unit

LEVEL0_DESCRIPTION VARCHAR2(90) Level0 (root) description for the current leaf of Operating Unit

LEVEL1_OPERUNIT VARCHAR2(30) Level1 value for the current leaf of Operating Unit

LEVEL1_OPERUNIT_KEY

NUMBER Level1 surrogate key for the current leaf of Operating Unit

LEVEL1_DESCRIPTION VARCHAR2(90) Level1 description for the current leaf of Operating Unit


LEVEL2_OPERUNIT_KEY



Rapid Mart Data SchemaOPERATING_UNIT_HIER_HZ A



LEVEL3_OPERUNIT_KEY




LEVEL4_OPERUNIT_KEY




LEVEL5_OPERUNIT_KEY




LEVEL6_OPERUNIT_KEY




LEVEL7_OPERUNIT_KEY




LEVEL8_OPERUNIT_KEY




Rapid Mart Data SchemaOPERATING_UNIT_HIER_PCA

OPERATING_UNIT_HIER_PCNatural Operating Unit key parent/child relationship hierarchy






OPER_UNIT_KEY NUMBER Surrogate key to child Operating UnitSETID PK VARCHAR2(1

5)SetID is used to differentiate between Operating Unit values that belong to different Business Units

OPER_UNIT PK VARCHAR2(30)

Child Operating Unit


Child Operating Unit description



PARENT_OPER_UNIT_KEY NUMBER Parent Operating Unit surrogate keyPARENT_OPER_UNIT VARCHAR2(3

0)Parent Operating Unit


Parent Operating Unit description





Rapid Mart Data SchemaOPERATING_UNIT_HIER_VR A

OPERATING_UNIT_HIER_VRNatural Operating Unit key vertically flattened hierarchy



SetID is used to differentiate between Operating Unit values that belong to different Business Units

ANCESTOR_OPERUNIT PK VARCHAR2(30)

Ancestor Operating Unit code

DESCENDENT_OPERUNIT PK VARCHAR2(30)

Descendent Operating Unit code



MAXDEPTH NUMBER Maximum depth of hierarchyDEPTH NUMBER Depth of the descendentROOT_FLAG NUMBER Root flag (1 means this is a root)LEAF_FLAG NUMBER Leaf flag (1 means this is a leaf)TREELEVEL NUMBER Tree levelANCESTOR_OPERUNIT_KEY

NUMBER Ancestor Operating Unit surrogate key

ANCESTOR_OPERUNIT_DESCR

VARCHAR2(90)

Ancestor Operating Unit description

DESCENDENT_OPERUNIT_KEY

NUMBER Descendent Operating Unit surrogate key

DESCENDENT_OPERUNIT_DESCR

VARCHAR2(90)

Descendent Operating Unit description





Rapid Mart Data SchemaPRODUCTA
PRODUCT
Dimension with Product attributes

PRODUCT_HIER_HZNatural Product key horizontally flattened hierarchy.


PRODUCT_KEY PK NUMBER Surrogate key to PRODUCTSETID VARCHAR2(15) SetID is used to differentiate between

Product values that belong to different Business Units

PRODUCT VARCHAR2(18) Product codeEFFDT DATETIME Effective from dateEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Product long descriptionDESCRSHORT VARCHAR2(30) Product short descriptionACCOUNTING_OWNER VARCHAR2(90) Accounting ownerTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Effective date current date indicatorLOAD_DATE DATETIME Date and Time when the record was


the target system


SETID PK VARCHAR2(10) SetID is used to differentiate between Product values that belong to different Business Units

PRODUCT PK VARCHAR2(30) Current leaf Product valueEFFECTIVE_FM_DT PK DATE Effective from dateEFFECTIVE_TO_DT DATE Effective to dateCURRENT_STATUS VARCHAR2(1) Effective date current date indicatorLEAF_LEVEL NUMBER Leaf level in horizontal flatteningMAXDEPTH NUMBER Maximum depth of hierarchy


Rapid Mart Data SchemaPRODUCT_HIER_HZ A

LEVEL0_PRODUCT VARCHAR2(30) Level0 (root) value for the current leaf of Product

LEVEL0_PRODUCT_KEY

NUMBER Level0 (root) surrogate key for the current leaf of Product

LEVEL0_DESCRIPTION VARCHAR2(90) Level0 (root) description for the current leaf of Product

LEVEL1_PRODUCT VARCHAR2(30) Level1 value for the current leaf of Product

LEVEL1_PRODUCT_KEY

NUMBER Level1 surrogate key for the current leaf of Product

LEVEL1_DESCRIPTION VARCHAR2(90) Level1 description for the current leaf of Product


LEVEL2_PRODUCT_KEY




LEVEL3_PRODUCT_KEY




LEVEL4_PRODUCT_KEY




LEVEL5_PRODUCT_KEY





Rapid Mart Data SchemaPRODUCT_HIER_PCA

PRODUCT_HIER_PCNatural Product key parent/child relationship hierarchy


LEVEL6_PRODUCT_KEY




LEVEL7_PRODUCT_KEY




LEVEL8_PRODUCT_KEY







PRODUCT_KEY NUMBER Surrogate key to child ProductSETID PK VARCHAR2(1

5)SetID is used to differentiate between Product values that belong to different Business Units

PRODUCT PK VARCHAR2(30)

Child Product


Child Product description

EFFECTIVE_FM_DT PK DATE Effective from date


Rapid Mart Data SchemaPRODUCT_HIER_VR A

PRODUCT_HIER_VRNatural Product key vertically flattened hierarchy

EFFECTIVE_TO_DT DATE Effective to dateCURRENT_STATUS VARCHAR2(1


PARENT_PRODUCT_KEY NUMBER Parent Product surrogate keyPARENT_PRODUCT VARCHAR2(3

0)Parent Product


Parent Product description







SetID is used to differentiate between Product values that belong to different Business Units

ANCESTOR_PRODUCT PK VARCHAR2(30)

Ancestor Product code

DESCENDENT_PRODUCT PK VARCHAR2(30)

Descendent Product code



MAXDEPTH NUMBER Maximum depth of hierarchyDEPTH NUMBER Depth of the descendentROOT_FLAG NUMBER Root flag (1 means this is a root)LEAF_FLAG NUMBER Leaf flag (1 means this is a leaf)TREELEVEL NUMBER Tree levelANCESTOR_PRODUCT_KEY NUMBER Ancestor Product surrogate key


Rapid Mart Data SchemaPROJECTA

PROJECTDimension with Project attributes

SCENARIODimension with Scenario attributes

ANCESTOR_PRODUCT_DESCR

VARCHAR2(90)

Ancestor Product description

DESCENDENT_PRODUCT_KEY

NUMBER Descendent Product surrogate key

DESCENDENT_PRODUCT_DESCR

VARCHAR2(90)

Descendent Product description






PROJECT_KEY PK NUMBER Surrogate key to PROJECT_IDSETID VARCHAR2(15) SetID is used to differentiate between

Project values that belong to different Business Units

PROJECT_ID VARCHAR2(15) Project codeDESCR VARCHAR2(90) Project descriptionLOAD_DATE DATETIME Date and Time when the record was


target system


SCENARIO_KEY PK NUMBER Surrogate key to SCENARIOSETID VARCHAR2(15) SetID is used to differentiate between

Scenario values that belong to different Business Units


Rapid Mart Data SchemaSOURCE A

SOURCEDimension with Source attributes

SCENARIO VARCHAR2(30) Scenario codeEFFDT DATETIME Effective from dateEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Scenario long descriptionDESCRSHORT VARCHAR2(30) Scenario short descriptionTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Effective date current date indicatorLOAD_DATE DATETIME Date and Time when the record was


target system



SOURCE_KEY PK NUMBER Surrogate key to SOURCESETID VARCHAR2(15) SetID is used to differentiate between

Source values that belong to different Business Units

SOURCE VARCHAR2(9) Source valueEFFDT DATETIME Effective from dateEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Source descriptionTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Indicates current attributes based upon

effective dateLOAD_DATE DATETIME Date and Time when the record was


target system


Rapid Mart Data SchemaSTAGE_BUDGET_FACTA
STAGE_BUDGET_FACT
Staging table used to split budget data processing between data extraction and data transformation


BUSINESS_UNIT PK VARCHAR2(15) Business Unit codeLEDGER PK VARCHAR2(30) Ledger codeACCOUNT PK VARCHAR2(30) Account codeALTACCT PK VARCHAR2(30) Alternate account codeOPERATING_UNIT PK VARCHAR2(24) Operating Unit codeDEPTID PK VARCHAR2(30) Department codePRODUCT PK VARCHAR2(18) Product codePROJECT_ID PK VARCHAR2(45) Project codeAFFILIATE PK VARCHAR2(15) Affiliate codeSCENARIO PK VARCHAR2(30) Scenario codeCURRENCY_CD PK VARCHAR2(9) Currency codeSTATISTICS_CODE PK VARCHAR2(9) Statistics codeFISCAL_YEAR PK NUMBER Fiscal YearACCOUNTING_PERIOD PK NUMBER Accounting periodPOSTED_TOTAL_AMT NUMBER Posted amount in reporting currencyPOSTED_BASE_AMT NUMBER Posted amount in base currencyPOSTED_TRAN_AMT NUMBER Posted amount in local currencyBASE_CURRENCY VARCHAR2(9) Base currencyDTTM_STAMP_SEC DATETIME Date and timestamp when the balance

was postedLOAD_DATE DATETIME Date and Time when the record was


target system


Rapid Mart Data SchemaSTAGE_JOURNAL_FACT A

STAGE_JOURNAL_FACTStaging table used to split journal entry data processing between data extraction and data transformation


BUSINESS_UNIT PK VARCHAR2(15) Business Unit codeJOURNAL_ID PK VARCHAR2(30) Journal identifierJOURNAL_DATE PK DATETIME Journal entry dateUNPOST_SEQ PK NUMBER Unpost sequence numberJOURNAL_LINE PK NUMBER Journal entry line numberLEDGER PK VARCHAR2(30) Ledger codeACCOUNT VARCHAR2(30) Account codeALTACCT VARCHAR2(30) Alternate account codeOPERATING_UNIT VARCHAR2(24) Operating Unit codeDEPTID VARCHAR2(30) Department codePRODUCT VARCHAR2(18) Product codePROJECT_ID VARCHAR2(45) Project codeAFFILIATE VARCHAR2(15) Affiliate codeSCENARIO VARCHAR2(30) Scenario codeCURRENCY_CD VARCHAR2(9) Currency codeSTATISTICS_CODE VARCHAR2(9) Statistics codeSOURCE VARCHAR2(9) Source codeMONETARY_AMOUNT NUMBER Journal entry amountSTATISTIC_AMOUNT NUMBER Journal entry fro statistic accountsJRNL_LN_REF VARCHAR2(30) Journal entry line referenceLINE_DESCR VARCHAR2(90) Journal entry line descriptionJRNL_LINE_STATUS VARCHAR2(30) Journal entry line statusFOREIGN_CURRENCY VARCHAR2(9) Local currencyRT_TYPE VARCHAR2(15) Rate typeFOREIGN_AMOUNT NUMBER Journal entry local amountFISCAL_YEAR NUMBER Fiscal Year of posted transactionACCOUNTING_PERIOD NUMBER Accounting Period of posted transaction


Rapid Mart Data SchemaSTAGE_LEDGER_FACTA

STAGE_LEDGER_FACTStaging table used to split budget data processing between data extraction and data transformation

JRNL_EDIT_ERR_STAT VARCHAR2(30) Journal entry error status descriptionJRNL_HDR_STATUS VARCHAR2(30) Journal header statusLOAD_DATE DATETIME Date and Time when the record was


target system



BUSINESS_UNIT PK VARCHAR2(15) Business Unit codeLEDGER PK VARCHAR2(30) Ledger codeACCOUNT PK VARCHAR2(30) Account codeALTACCT PK VARCHAR2(30) Alternate account codeOPERATING_UNIT PK VARCHAR2(24) Operating Unit codeDEPTID PK VARCHAR2(30) Department codePRODUCT PK VARCHAR2(18) Product codePROJECT_ID PK VARCHAR2(45) Project codeAFFILIATE PK VARCHAR2(15) Affiliate codeCURRENCY_CD PK VARCHAR2(9) Currency codeSTATISTICS_CODE PK VARCHAR2(9) Statistics codeFISCAL_YEAR PK NUMBER Fiscal YearACCOUNTING_PERIOD

PK NUMBER Accounting period

POSTED_TOTAL_AMT NUMBER Posted amount in reporting currencyPOSTED_BASE_AMT NUMBER Posted amount in base currencyPOSTED_TRAN_AMT NUMBER Posted amount in local currencyBASE_CURRENCY VARCHAR2(9) Base currencyDTTM_STAMP_SEC DATETIME Date and timestamp when the balance

was posted


Rapid Mart Data SchemaSTATISTIC A

STATISTICDimension with Statistic attributes





STATISTIC_KEY PK NUMBER Surrogate key to STATISTICS_CODESETID VARCHAR2(15) SetID is used to differentiate between

Statistics values that belong to different Business Units

STATISTICS_CODE VARCHAR2(9) Statistics codeEFFDT DATETIME Effective from dateEFF_STATUS VARCHAR2(1) Effective status (Active or Inactive)DESCR VARCHAR2(90) Statistic long descriptionDESCRSHORT VARCHAR2(30) Statistic short descriptionUNIT_OF_MEASURE VARCHAR2(9) Unit of measureTO_EFFDT DATETIME Effective to dateCURRENT_IND VARCHAR2(1) Indicates current attributes based upon

effective dateLOAD_DATE DATETIME Date and Time when the record was


target system


Rapid Mart Data SchemaTEMP_DEPARTMENTA
TEMP_DEPARTMENT
Temporary table used when creating the Department dimension. First stage processing of the dimension extracts dimension attributes from the source table and surrogate key lookup for DEPARTMENT_KEY. The second stage process looks up these surrogate keys to provide further surrogate keys for BUDGET_DEPT

TIME_DIMENSIONTime dimension with a daily granularity. Not recommended to be joined to LEDGER FACT or BUDGET_FACT due to the balances post date (DTTM_STAGE_SEC) not necessarily corresponding to the ACCOUNTING_PERIOD the balance falls within. These fact tables ought to be linked to FISCAL_CALENDAR.


SETID PK VARCHAR2(15) SetID is used to differentiate between Department values that belong to different Business Units

DEPTID PK VARCHAR2(30) Department codeEFFDT PK DATETIME Effective from dateBUDGET_DEPTID VARCHAR2(30) Budget department codeTO_EFFDT DATETIME Effective to dateLOAD_DATE DATETIME Date and Time when the record was


target system


TIME_KEY PK NUMBER Smart key in theformat ‘YYYYMMDD’. Used to link to TIME_KEY in the fact tables at a daily granularity.

MONTH_KEY NUMBER Smart key in the format ‘YYYYMM’. Used to link to MONTH_KEY in MONTH_DIMENSION at a monthly granularity

DAY DATETIME Daily dates ranging between user defined star and end date


Rapid Mart Data SchemaTIME_DIMENSION A

MONTH NUMBER Calendar month numeric representation

QUARTER NUMBER Calendar quarter numeric representation

YEAR NUMBER YearDAY_IN_WEEK NUMBER Numeric representation of the day in

weekWEEK_IN_YEAR NUMBER Numeric representation of the week in

yearIS_WEEKEND VARCHAR2(1) Numeric representation of weekday or

weekend daysFISCAL_YEAR NUMBER Fiscal yearACCOUNTING_PERIOD

NUMBER Accounting period

PERIOD_NAME VARCHAR2(90) Period descriptionPERIOD_ABBRV VARCHAR2(9) Abbreviated period descriptionCURRENT_FISCAL_YEAR

VARCHAR2(1) Current fiscal year indicator (Y or N)

CURRENT_ACCOUNTING_PERIOD

VARCHAR2(1) Current accounting period indicator (Y or N)

LOAD_DATE DATETIME Date and Time when the record was loaded

LOAD_TIME VARCHAR2(8) Time in a string format when the record was loaded



Rapid Mart Data SchemaTIME_DIMENSIONA


people soft

Documents

rapid mart fits

dimension table load

load fact table

contentsfact table load

initial load

incremental load

load dimension tables

trademarks business