Businessobjects Peoplesoft General Ledger Rapid Mart User'S Guide

BusinessObjects PeopleSoft General Ledger Rapid Mart Users 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. 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 2005 Business Objects. All rights reserved.
Trademarks
Copyright
Contents
Chapter 1 Introduction 9 What is a Rapid Mart? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Rapid Marts Accelerate Time to Value . . . . . . . . . . . . . . . . . . . . . . . . 10 BusinessObjects Rapid Mart architecture . . . . . . . . . . . . . . . . . . . . . . 11 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 2 Overview 13
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 What you can do with this Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Supported analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Related Rapid Marts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Sharing components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Rapid Mart schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Where the Rapid Mart fits in General Ledger Accounting Cycle . . . . . . . . 19 Chapter 3 Subject Areas 21
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Journal Entry section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 PeopleSoft processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Rapid Mart processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Rapid Mart data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Fact table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 General Ledger Balances section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 PeopleSoft processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Rapid Mart processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Rapid Mart data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Fact table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contents
Budgeting section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 PeopleSoft processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Rapid Mart processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Rapid Mart data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Fact table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Chapter 4 Reports 39
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Journal Entry section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Journal Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Recommended table joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 GL Balances section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Asset Account Trial Balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Period Net Activity Drill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Actuals Profit and Loss Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Recommended table joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Budgets section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Actual V Budget Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Budget Profit and Loss Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Recommended table joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Chapter 5 Installing the Rapid Mart 57
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 System prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Rapid Mart product components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Preparing your environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Installation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Installation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Completing the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Contents
Installing Rapid Mart Reporting Content . . . . . . . . . . . . . . . . . . . . . . . . . . 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Chapter 6 Using the Rapid Mart 69
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Recovery framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Data Integrator automatic recovery feature . . . . . . . . . . . . . . . . . . . . . 70 Rapid Mart recovery framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Execution status framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 The execution status table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 How job status is maintained . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 The execution status API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Executing a job with the reset option . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Extraction, transformation and loading process . . . . . . . . . . . . . . . . . . . . . 74 Batch configuration variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Executing the jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Customizing the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Chapter 7 Technical Implementation 83
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Journal Entry section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Initial load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Dimension table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Fact table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Incremental load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Load dimension tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Load fact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 GL Balance section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Initial load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Dimension table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Contents
Fact table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Incremental load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Load dimension tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Load fact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Budget section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Initial load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Dimension table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Fact table load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Incremental load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Load dimension tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Load fact table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Dealing with NULL values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Fact table stored procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Appendix A Rapid Mart Data Schema 111
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Fact tables in the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Dimension tables in the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Other tables in the Rapid Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 ACCOUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 ACCOUNT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 ACCOUNT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 ACCOUNT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 ACCOUNT_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 AFFILIATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 ALTACCOUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 ALTACCOUNT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 ALTACCOUNT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 ALTACCOUNT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 AW_JOBEXECUTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 BUDGET_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Contents
BUSINESS_UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 COMPANY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 CURRENCY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 DEPARTMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 DEPARTMENT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 DEPARTMENT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 DEPARTMENT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 FISCAL_CALENDAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 JOURNAL_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 LEDGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 LEDGER_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 MONTH_DIMENSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 OPERATING_UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 OPERATING_UNIT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 OPERATING_UNIT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 OPERATING_UNIT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 PRODUCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 PRODUCT_HIER_HZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 PRODUCT_HIER_PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 PRODUCT_HIER_VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 PROJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 SCENARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 STAGE_BUDGET_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 STAGE_JOURNAL_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 STAGE_LEDGER_FACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 STATISTIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 TEMP_DEPARTMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 TIME_DIMENSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Contents
Introduction
chapter
Introduction What is a Rapid Mart?
What is a Rapid Mart?

BusinessObjects Rapid Marts provide packaged extraction of operational data to accelerate the deployment of business intelligence (BI). They are addon 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 companys 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 Value

Rapid Marts are packaged data solutions that you can quickly deploy to address specific areas of business analysis. Available Rapid Marts include:

10
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
Introduction About this document
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 Mart
You 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 architecture

Rapid 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 document

This 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.
11
Introduction About this document
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
12
Overview
chapter
Overview Overview
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 Mart

The 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
14
Overview What you can do with this Rapid Mart
The Rapid Mart addresses the following three sub-modules:
Journal Entries General Ledger Balances Budgeting 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?
With this Rapid Mart, you can answer the following kinds of questions:
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 companys 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.
15
Overview Supported analyses
Supported analyses
The BusinessObjects PeopleSoft General Ledger Rapid Mart supports several types of analyses. Business function Journal Entry Types of analysis Financial Accounting Measures available in the Rapid Mart
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 year Analyses of Balance Sheets Reporting on actual and statistical amounts posted to General Ledger Intercompany transaction details Actual vs. Budget amounts comparison for the same or different accounting periods Actual vs. Actual amounts for different accounting periods Reporitng on actual and budgeted amounts posted to General Ledger

GL Balances Balance
Variance Analysis
Budgeting
Budget
16
Overview Related Rapid Marts
Related Rapid Marts

Each 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.
17
Overview Rapid Mart schema
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.
18
Overview Where the Rapid Mart fits in General Ledger Accounting Cycle
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 period
The BusinessObjects PeopleSoft General Ledger Rapid Mart addresses all the analysis of the transactions posted to the General Ledger.
19
Overview Where the Rapid Mart fits in General Ledger Accounting Cycle
20
Subject Areas
chapter
Subject Areas Overview
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 section

General 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 processing
The 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.
22
Subject Areas Journal Entry section
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 processing

The 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.
23
Rapid Mart data

The following diagram shows tables that the Journal Entry section extracts.
Fact table columns

The 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_LINE JOURNAL_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.
24
UNPOST_SEQ Journal unpost sequence number LEDGER_KEY The name of the ledger that journal entry transactions have been assigned to. This column holds the surrogate key reference to the ledger dimension
ACCOUNT_KEY The name of the account a journal entry has been posted against. This column holds the surrogate key reference to the account dimension ALTACCOUNT_KEY The 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_KEY The 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_KEY The 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_KEY There 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_KEY Specifies which data scenario a transaction is associated with.The SCENARIO_KEY column holds the surrogate key reference to the scenario dimension.
25
CURRENCY_KEY Specifies 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_KEY Indicates 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_KEY Specifies the source of the journal record. This column holds the surrogate key reference to the source dimension. COMPANY_KEY Specifies 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_KEY Specifies 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_KEY This 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_DESCR These columns can be used for journal descriptions such as invoice or purchase order references and field references. JRNL_LINE_STATUS Contains a 1 or 0 depending upon whether the journal entry is valid (0) or in error (1). FOREIGN_CURRENCY Base currency of the transaction. RT_TYPE Transaction rate type FOREIGN_AMOUNT Transaction Amount held in local currency
26
FISCAL YEAR, ACCOUNTING PERIOD The accounting period and fiscal year into which the journal entry posted date falls. JRNL_EDIT_ERR_STAT Failed journals will contain an error status that indicates what error occured. Valid journals will contain Valid - No Edit Errors. JRNL_HDR_STATUS The status of the journal as indicated by the journal header record. 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 8character 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.
Analysis
With 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 year 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?
Typical queries include:
27
Subject Areas General Ledger Balances section
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.
Actual 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 preexpenditures to be recorded commonly known as encumbrances. The primary purpose of tracking encumbrances is to avoid overspending a budget.

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

The following diagram shows tables for the GL Balances section.
Fact table columns

The 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_KEY The name of the ledger that balance transactions have been assigned to. This column holds the surrogate key reference to the ledger dimension ACCOUNT_KEY The name of the account a balance transaction has been posted against. This column holds the surrogate key reference to the account dimension
29
ALTACCOUNT_KEY The 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_KEY The 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_KEY The 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_KEY Specifies which currency is held against the balance transaction amounts. The CURRENCY_KEY column holds the surrogate key reference to the currency dimension.
STATISTICS_KEY Indicates 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_KEY Specifies 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
30
TIME_KEY This 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 PERIOD The accounting period and fiscal year into which the balance transactions will occur. POSTED_TOTAL_AMOUNT The transaction amount posted to the general ledger in reporting currency. POSTED_BASE_AMOUNT The transaction amount posted to the general ledger in base currency POSTED_TRAN_AMOUNT The transaction amount posted to the general ledger in local currency BASE_CURRENCY_KEY Base currency of the transaction. This column holds the surrogate key reference to the currency dimension. DTTM_STAMP_SEC The 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 8character 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.
31
Subject Areas Budgeting section
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 year 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 section
Budgeting 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.
The 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.
32
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.

The 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 data

The following diagram shows tables that the Budgeting section extracts.
33
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_KEY The name of the ledger that balance transactions have been assigned to. This column holds the surrogate key reference to the ledger dimension ACCOUNT_KEY The name of the account a balance transaction has been posted against. This column holds the surrogate key reference to the account dimension ALTACCOUNT_KEY The 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_KEY The 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_KEY The 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.
34
SCENARIO_KEY Specifies which data scenario a transaction is associated with. The SCENARIO_KEY column holds the surrogate key reference to the scenario dimension.
CURRENCY_KEY Specifies which currency is held against the balance transaction amounts. The CURRENCY_KEY column holds the surrogate key reference to the currency dimension.
STATISTICS_KEY Indicates 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_KEY Specifies 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_PERIOD Specifies 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_KEY This 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.
35
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 PERIOD The accounting period and fiscal year into which the balance transactions will occur. POSTED_TOTAL_AMOUNT The transaction amount posted to the general ledger in reporting currency. POSTED_BASE_AMOUNT The transaction amount posted to the general ledger in base currency POSTED_TRAN_AMOUNT The transaction amount posted to the general ledger in local currency BASE_CURRENCY_KEY Base currency of the transaction. This column holds the surrogate key reference to the currency dimension. DTTM_STAMP_SEC The 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.
36
Analysis
With 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. budgets 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?
37
38
Reports
chapter
Reports Overview
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

The journal entry section captures actual financial transactions at line item level posted to the company general ledger.
Sample reports
Using 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.
40
Reports Journal Entry section
Journal Detail Report

This 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
41
Reports Journal Entry section
FROM FISCAL_CALENDAR, BUSINESS_UNIT, DEPARTMENT, JOURNAL_FACT, ACCOUNT WHERE ( 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.DESCR HAVING ( 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 JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT Column name BUSINESS_UNIT_KE Y LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY Dimension table BUSINESS_UNIT LEDGER ACCOUNT ALTACCOUNT DEPARTMENT Column name BUSINESS_UNIT_KEY LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY OPERATING_UNIT_K EY PRODUCT_KEY
OPERATING_UNIT_K OPERATING_UNIT EY PRODUCT_KEY PRODUCT
42
Reports GL Balances section
Fact table JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT JOURNAL_FACT
Column name PROJECT_KEY AFFILIATE_KEY SCENARIO_KEY CURRENCY_KEY STATISTIC_KEY SOURCE_KEY COMPANY_KEY
Dimension table PROJECT AFFILIATE SCENARIO CURRENCY STATISTIC SOURCE COMPANY
Column name PROJECT_KEY AFFILIATE_KEY SCENARIO_KEY CURRENCY_KEY STATISTIC_KEY SOURCE_KEY COMPANY_KEY ACCOUNT_TYPE_KE Y TIME_KEY ACCOUNTING_PERIO D FISCAL_YEAR
ACCOUNT_TYPE_KE ACCOUNT_TYPE Y TIME_KEY ACCOUNTING_PERI OD FISCAL_YEAR TIME_DIMENSION FISCAL_YEAR FISCAL_YEAR
GL Balances section
The balances section stores balance amounts for general ledger detail accounts.
Sample reports
Using 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
43
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
44
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_TYPE WHERE ( 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
45
Period Net Activity Drill

This report displays period net activity for specific account types in the balance sheet..
46
SELECT ACCOUNT_TYPE.DESCR, ACCOUNT.ACCOUNT, SUM(LEDGER_FACT.POSTED_TOTAL_AMT), ACCOUNT.DESCR, ACCOUNT.DESCRSHORT FROM ACCOUNT_TYPE, ACCOUNT, LEDGER_FACT, FISCAL_CALENDAR WHERE ( 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
47
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..
48
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_FACT WHERE ( 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' )
49
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

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. Fact table LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT LEDGER_FACT Column name Dimension table Column name BUSINESS_UNIT_KE Y LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY OPERATING_UNIT_K EY PRODUCT_KEY PROJECT_KEY AFFILIATE_KEY CURRENCY_KEY STATISTIC_KEY SOURCE_KEY COMPANY_KEY ACCOUNT_TYPE_KE Y TIME_KEY
BUSINESS_UNIT_KE BUSINESS_UNIT Y LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY LEDGER ACCOUNT ALTACCOUNT DEPARTMENT
OPERATING_UNIT_K OPERATING_UNIT EY PRODUCT_KEY PROJECT_KEY AFFILIATE_KEY CURRENCY_KEY STATISTIC_KEY SOURCE_KEY COMPANY_KEY PRODUCT PROJECT AFFILIATE CURRENCY STATISTIC SOURCE COMPANY
ACCOUNT_TYPE_KE ACCOUNT_TYPE Y TIME_KEY TIME_DIMENSION
50
Reports Budgets section
Fact table LEDGER_FACT LEDGER_FACT
Column name ACCOUNTING_PERI OD FISCAL_YEAR
Dimension table FISCAL_YEAR FISCAL_YEAR
Column name ACCOUNTING_PERI OD FISCAL_YEAR
Budgets section
The budget section stores actual and budget version transactions for general ledger budget proposals.
Sample reports
Using 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 Report

This report shows actual YTD, budget YTD and variance data for the selected legal entity, department and fiscal period.
51
52
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_CALENDAR WHERE ( 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
53
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,
54
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_FACT WHERE ( 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,
55
BUSINESS_UNIT.DESCR, OPERATING_UNIT.OPERATING_UNIT, OPERATING_UNIT.DESCR, DEPARTMENT.DEPTID, DEPARTMENT.DESCR, CURRENCY.CURRENCY, CURRENCY.DESCR, ACCOUNT.ACCOUNT, ACCOUNT.DESCR

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. Fact table BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT BUDGET_FACT Column name Dimension table Column name BUSINESS_UNIT_KE Y LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY OPERATING_UNIT_K EY PRODUCT_KEY PROJECT_KEY AFFILIATE_KEY CURRENCY_KEY STATISTIC_KEY SOURCE_KEY COMPANY_KEY ACCOUNT_TYPE_KE Y TIME_KEY ACCOUNTING_PERI OD FISCAL_YEAR
BUSINESS_UNIT_KE BUSINESS_UNIT Y LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY LEDGER ACCOUNT ALTACCOUNT DEPARTMENT
OPERATING_UNIT_K OPERATING_UNIT EY PRODUCT_KEY PROJECT_KEY AFFILIATE_KEY CURRENCY_KEY STATISTIC_KEY SOURCE_KEY COMPANY_KEY PRODUCT PROJECT AFFILIATE CURRENCY STATISTIC SOURCE COMPANY
ACCOUNT_TYPE_KE ACCOUNT_TYPE Y TIME_KEY ACCOUNTING_PERI OD FISCAL_YEAR TIME_DIMENSION FISCAL_YEAR FISCAL_YEAR
56
Installing the Rapid Mart
chapter
Installing the Rapid Mart Overview
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 prerequisites
To 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 components

The 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
58
Installing the Rapid Mart Preparing your environment
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 environment

Follow 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. 4. Exit Data Integrator. 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. 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.
5.
59
Installing the Rapid Mart Installation overview
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 overview
The 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 procedure
Follow these steps to install the Rapid Mart:
60
Installing the Rapid Mart Installation procedure
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. This opens up the autorun screen. Select Install Rapid Mart option to install Rapid Mart. 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. The License Agreement window opens. Read its contents and click Yes to indicate that you agree to the product terms and conditions. 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.
2. 3.
4. 5.
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.
61
Enter or select the configuration for the source datastore, target datastore. Prompt Source Datastore Name 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. 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. 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. This option will drop (if exists) and create all database objects - tables, indexes and procedures - required for target database schema during the installation process. Select the target database type from one of the available types. Depending upon the selected type other options change. Description
Application Type
Target Datastore Name
Target Database Information Drop and Create DB Objects.
Database Type
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.
62
Prompt Database Name
Description Appears in the case of MS SQL Server database type. Enter the target database name in the SQL Server database. Appears in the case of DB2 database type. Enter the DB2 data source information. Database connection Username. Make sure that the user got privileges to create/drop table, indexes and procedures Database connection Password.
DB2 Datasource Username
Password 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. 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.
9.
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.
63
Installing the Rapid Mart Completing the installation
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 installation

To 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 Martboth 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 Content

Rapid 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.
64
Installing the Rapid Mart Installing Rapid Mart Reporting Content
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. This opens up the autorun screen. Select Install Reporting Content option to install the Reporting Content. 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. 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.
2. 3.
4.
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. 7. 8. 9.
Click Next at the confirmation screen to start installation. Now the installer will unpack and release the reporting contents into your BusinessObjects Enterprise system. Click Finish to complete the installation. Remember, you must configure the universe connection before attempting to run any of the reports. 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.
65
Installing the Rapid Mart Installing Rapid Mart Reporting Content
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.
66
67
68
Using the Rapid Mart
chapter
Using the Rapid Mart Overview
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 framework
When 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 feature

With 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.
70
Using the Rapid Mart Recovery framework
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 framework

The Rapid Mart contains an external execution status table (AW_JOBEXECUTION) that tracks the status of a jobs 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 jobs 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 days 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 days 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,
71
Using the Rapid Mart Execution status framework
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 table

The Rapid Mart installation procedure creates a table named AW_JOBEXECUTION in the target database. The execution status table has four columns. Table column NAME Description 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. The status of this job after the last execution. Possible status values are: started, done, or none. Last attempted start date of data retrieval. This date is also the ending date of the last successful run of the job. Last attempted end date of data retrieval.
STATUS EXTRACTLOW EXTRACTHIGH
How job status is maintained

The Rapid Mart records a job status for each invocation of a particular job. There are three possible values for job status:

72
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.
Using the Rapid Mart Execution status framework
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.
When a job is started, the Rapid Mart checks the jobs existing status. If the previous execution of the job did not complete successfullythat is, the job status is not donethe 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
After checking the jobs 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 jobs status to done. If the job does not complete successfully, the jobs status remains set to started. The EXTRACTLOW and EXTRACTHIGH dates remain set to the current values.
The execution status API

The 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,
73
Using the Rapid Mart Extraction, transformation and loading process
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 option

You 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 jobs 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:
74
Using the Rapid Mart Extraction, transformation and loading process
Job global variable properties. This window can be accessed by rightclicking 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.
75
Using the Rapid Mart Batch configuration variables
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 variables

The job that load the BusinessObjects General Ledger Rapid Mart for PeopleSoft uses several variables:

Global Variables
Global Variables Local Variables
Global 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 $G_LANGUAGE $G_LOAD_TYPE Format char(30) char(7) Description Language to be Used throughout the Rapid Mart 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'
76
Variable name $G_SDATE
Format YYYY.MM.D D
Description 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.D D
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 Set to current system date Set to character representation of current system time Default value for a date field when it is NULL. The default value is 9999.12.31 Default value for a number field when it is NULL or when it is a foreign key. The default value is -1
$G_LOAD_DATE $G_LOAD_TIME $G_DEFAULT_DATE $G_DEFAULT_NUMBER
datetime char(8) date int
77
Variable name $G_DEFAULT_TEXT
Format char(1)
Description Default value for a character field when it is NULL and when it is not a foreign key. The default value is ? Name of the Period Set to be used to populate TIME_DIM only. The default value is Accounting Type of the Period Set to be used to populate TIME_DIM only. Default is Month. Controls whether the fact table index is rebuilt after data loading has taken place
$G_CALENDAR_ID
char(15)
$G_CALENDAR_SETID $G_REBUILD_INDEXES
char(15) char(1)
Local Variables
Local 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. Variable name $RUN_MODE Format char(7) Description 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 Contains the pass or failure status returned by the fact table post-processing script
$P_FAILURES
int
Executing the jobs

The steps you complete when executing the PSFT_GL_Load job depend on the type of job:

1. 2.
Initial extraction Incremental extraction To execute the initial extraction and load In the project area right-click in the PSFT_GL_Load job to access the Properties window. Edit the job Global Variable properties: a. b. Make sure that the value for the $G_LOAD_TYPE variable is set to FIRST. Set the starting and ending time periods for the initial load.
78
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. 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.
d.
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. b. In the project area, right-click the job and choose Execute. Data Integrator opens the Execution Properties window. 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 load 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.
1.
79
Using the Rapid Mart Customizing the Rapid Mart
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. Set values for the rest of global variables in the Properties window. Click OK to accept the set properties and to close the window. In the project area, right-click the job and choose Execute. Data Integrator opens the Execution Properties window. 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. d. 2. a. b.
Run the job.
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 Mart

Rapid 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.
80
Transport Rapid Mart components and sections to different Rapid Marts using the Data Integrator export and import facilities. Change column names to be more meaningful in your business environment. Remove columns or tables you do not need in your business environment. Add:
For example, to customize the Rapid Mart, you might:
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.
81
82
Technical Implementation
chapter
Technical Implementation Overview
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

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.
84
Technical Implementation Journal Entry section
Initial load
The 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 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 Work flow C_AccountType_PSF Description General Ledger account category (Revenue, Expense, Liability, Asset, Equity) Account codes and descriptions Tables loaded ACCOUNT_TYPE
C_Account_PSF
ACCOUNT
85
Work flow C_Affiliate_PSF C_AltAccount_PSF C_BusinessUnit_PSF
Description Intercompany codes and descriptions Business unit codes and descriptions. This workflow is shared with the
Tables loaded AFFILIATE BUSINESS_UNIT
Alternate account codes and descriptions ALTACCOUNT
PeopleSoft HR Rapid Mart
C_Company_PSF
Company codes and descriptions. This workflow is shared with the PeopleSoft
COMPANY
HR Rapid Mart
C_Currency_PSF
Currency abbreviations and texts.This workflow is shared with the PeopleSoft
CURRENCY
HR Rapid Mart
C_TimeDim_PSF
Generated time periods with PeopleSoft TIME_DIMENSION, calendar parameters with a granularity of MONTH_DIMENSION, a calendar day. Besides creating FISCAL_CALENDAR 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 Department codes and descriptions. This DEPARTMENT workflow is shared with the PeopleSoft
C_Department_PSF
HR Rapid Mart
C_Ledger_PSF C_OperatingUnit_PSF C_Product_PSF C_Project_PSF C_Scenario_PSF C_Source_PSF
Ledger codes and descriptions. Operating Unit codes and descriptions Product codes and descriptions. Project codes and descriptions Budget scenario codes and descriptions Journal source codes and descriptions
LEDGER OPERATING_UNIT PRODUCT PROJECT SCENARIO SOURCE
86
Work flow C_Statistic_PSF C_GLHierarchy_PSF
Description Statistic account codes and descriptions Vertically, parent/child and horizontally flattened hierarchy for Account, AltAccount, Department, Operating Unit and Product
Tables loaded STATISTIC ACCOUNT_HIER_PC ACCOUNT_HIER_HZ ACCOUNT_HIER_VR ALTACCOUNT_HIER_P C ALTACCOUNT_HIER_H Z ALTACCOUNT_HIER_V R DEPARTMENT_HIER_P C DEPARTMENT_HIER_H Z DEPARTMENT_HIER_V R OPERATING_UNIT_HIE R_PC OPERATING_UNIT_HIE R_HZ OPERATING_UNIT_HIE R_VR PRODUCT_HIER_PC PRODUCT_HIER_HZ PRODUCT_HIER_VR
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 SETIDs. 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
87
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
88
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, ACCOUNT WHERE ACCOUNT.SETID = PS_SET_CNTRL_REC.SETID AND 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
89
The following diagram details the lookup_ext() dialog and Custom Code for the ACCOUNT_KEY lookup.
90
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 , ACCOUNT WHERE ACCOUNT_TYPE.SETID = AT.SETID AND ACCOUNT.SETID = A.SETID AND A.SETCNTRLVALUE = AT.SETCNTRLVALUE AND ACCOUNT.ACCOUNT_TYPE = ACCOUNT_TYPE.ACCOUNT_TYPE AND 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
91
OPERATING_UNIT_HZ, OPERATING_UNIT_VR PRODUCT_HZ, PRODUCT_VR
NOTE: 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 load

After 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.
92
Incremental load
Load dimension tables
All 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 table

The 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.
93
Technical Implementation GL Balance section
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 load
The 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.)
94

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 Work flow C_AccountType_P SF C_Account_PSF C_Affiliate_PSF Description General Ledger account category (Revenue, Expense, Liability, Asset, Equity) Account codes and descriptions Intercompany codes and descriptions Tables loaded ACCOUNT_TYPE
ACCOUNT AFFILIATE ALTACCOUNT BUSINESS_UNIT
C_AltAccount_PSF Alternate account codes and descriptions C_BusinessUnit_P SF C_Company_PSF Business unit codes and descriptions. This workflow is shared with the
HR Rapid Mart
C_Currency_PSF
COMPANY
CURRENCY
HR Rapid Mart
C_TimeDim_PSF
Generated time periods with PeopleSoft TIME_DIMENSION, calendar parameters with a granularity MONTH_DIMENSION, of a calendar day. Besides creating TIME_DIMENSION this work flow also FISCAL_CALENDAR creates MONTH_DIMENSION and FISCAL_CALENDAR at a monthly granularity. This workflow is shared with the PeopleSoft HR Rapid Mart DEPARTMENT
C_Department_PS Department codes and descriptions. F This workflow is shared with the
C_Ledger_PSF
Ledger codes and descriptions.
LEDGER OPERATING_UNIT PRODUCT PROJECT
C_OperatingUnit_P Operating Unit codes and descriptions SF C_Product_PSF C_Project_PSF Product codes and descriptions. Project codes and descriptions
95
Work flow C_Statistic_PSF C_GLHierarchy_P SF
Description
Tables loaded
Statistic account codes and descriptions STATISTIC Vertically, parent/child and horizontally ACCOUNT_HIER_PC flattened hierarchy for Account, ACCOUNT_HIER_HZ AltAccount, Department, Operating Unit ACCOUNT_HIER_VR and Product ALTACCOUNT_HIER_PC ALTACCOUNT_HIER_HZ ALTACCOUNT_HIER_VR DEPARTMENT_HIER_PC DEPARTMENT_HIER_HZ DEPARTMENT_HIER_VR OPERATING_UNIT_HIER_PC OPERATING_UNIT_HIER_HZ OPERATING_UNIT_HIER_VR PRODUCT_HIER_PC PRODUCT_HIER_HZ PRODUCT_HIER_VR
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 SETIDs. 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
96
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 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:
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
97
98
99
NOTE: 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 load

After 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 table

The 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.
100
Technical Implementation Budget section
Budget section
This section of General Ledger Rapid Mart stores budget amounts for General Ledger detail accounts
Initial load
The 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.)
101

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 Work flow Description Tables loaded ACCOUNT_TYPE
C_AccountType_PSF General Ledger account category (Revenue, Expense, Liability, Asset, Equity) C_Account_PSF C_Affiliate_PSF C_AltAccount_PSF C_BusinessUnit_PS F C_Company_PSF Account codes and descriptions Intercompany codes and descriptions Alternate account codes and descriptions
ACCOUNT AFFILIATE ALTACCOUNT
Business unit codes and descriptions. This BUSINESS_UNIT workflow is shared with the PeopleSoft
HR Rapid Mart
COMPANY
HR Rapid Mart
C_Currency_PSF
HR Rapid Mart
C_TimeDim_PSF
CURRENCY
TIME_DIMENSION, Generated time periods with PeopleSoft calendar parameters with a granularity of a MONTH_DIMENSION, calendar day. Besides creating FISCAL_CALENDAR 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 Department codes and descriptions. This workflow is shared with the PeopleSoft Ledger codes and descriptions. DEPARTMENT
C_Department_PSF
HR Rapid Mart
C_Ledger_PSF
LEDGER OPERATING_UNIT PRODUCT PROJECT SCENARIO
C_OperatingUnit_PS Operating Unit codes and descriptions F C_Product_PSF C_Project_PSF C_Scenario_PSF Product codes and descriptions. Project codes and descriptions Budget scenario codes and descriptions
102
Work flow C_Statistic_PSF
Description Statistic account codes and descriptions
Tables loaded STATISTIC ACCOUNT_HIER_PC ACCOUNT_HIER_HZ ACCOUNT_HIER_VR ALTACCOUNT_HIER_PC ALTACCOUNT_HIER_HZ ALTACCOUNT_HIER_VR DEPARTMENT_HIER_P C DEPARTMENT_HIER_HZ DEPARTMENT_HIER_V R OPERATING_UNIT_HIER _PC OPERATING_UNIT_HIER _HZ OPERATING_UNIT_HIER _VR PRODUCT_HIER_PC PRODUCT_HIER_HZ PRODUCT_HIER_VR
C_GLHierarchy_PSF Vertically, parent/child and horizontally flattened hierarchy for Account, AltAccount, Department, Operating Unit and Product
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 SETIDs. 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
103
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 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:
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
104
105

106
NOTE: 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 load

After 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 table

The 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.
107
Technical Implementation Dealing with NULL values
Dealing with NULL values

As 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 procedures

When 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;
108
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.
109
110
Rapid Mart Data Schema
appendix
Rapid Mart Data Schema Overview
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
112
Rapid Mart Data Schema Other tables in the Rapid Mart
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
ACCOUNT
Dimension with Account attributes Column name ACCOUNT_KEY SETID Key PK Data type Column description
VARCHAR2(30) Surrogate key to ACCOUNT VARCHAR2(15) SetID is used to differentiate between Account values that belong to different Business Units VARCHAR2(30) Account code DATETIME VARCHAR2(1) Effective from date Effective status (Active or Inactive)
ACCOUNT EFFDT EFF_STATUS DESCR
VARCHAR2(90) Account long description
113
Rapid Mart Data Schema ACCOUNT_HIER_HZ
Column name DESCRSHORT UNIT_OF_MEASURE CURRENCY_CD STATISTICS_ACCOUN T BALANCE_FWD_SW TO_EFFDT ACCOUNT_TYPE BSHEET_IND_DESCR VAT_ACCT_FLG_DESC R CURRENT_IND LOAD_DATE LOAD_TIME
Key
Data type VARCHAR2(9) VARCHAR2(9) VARCHAR2(3) VARCHAR2(3) DATETIME VARCHAR2(3)
Column description Account short description Account currency code Statistics account indicator Account balance forward indicator Effective to date Account type
VARCHAR2(30) Account short description
VARCHAR2(30) Balance sheet indicator VARCHAR2(30) VAT account description VARCHAR2(1) DATETIME VARCHAR2(8) Effective date current date indicator Date and Time when the record was loaded into target system Time when the record was loaded into the target system
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_HZ
Natural Account key horizontally flattened hierarchy. Column name SETID Key PK Data type Column description
VARCHAR2(10) SetID is used to differentiate between Account values that belong to different Business Units VARCHAR2(30) Current leaf Account value DATE DATE Effective from date Effective to date
ACCOUNT EFFECTIVE_FM_DT EFFECTIVE_TO_DT
PK PK
114
Rapid Mart Data Schema ACCOUNT_HIER_HZ
Column name CURRENT_STATUS LEAF_LEVEL MAXDEPTH LEVEL0_ACCOUNT LEVEL0_ACCOUNT_KE Y LEVEL0_DESCRIPTION LEVEL1_ACCOUNT LEVEL1_ACCOUNT_KE Y LEVEL1_DESCRIPTION LEVEL2_ACCOUNT LEVEL2_ACCOUNT_KE Y LEVEL2_DESCRIPTION LEVEL3_ACCOUNT LEVEL3_ACCOUNT_KE Y LEVEL3_DESCRIPTION LEVEL4_ACCOUNT LEVEL4_ACCOUNT_KE Y LEVEL4_DESCRIPTION LEVEL5_ACCOUNT
Key
Data type VARCHAR2(1) NUMBER NUMBER
Column description Effective date current date indicator Leaf level in horizontal flattening Maximum depth of hierarchy
VARCHAR2(30) Level0 (root) value for the current leaf of Account NUMBER Level0 (root) surrogate key for the current leaf of Account
VARCHAR2(90) Level0 (root) description for the current leaf of Account VARCHAR2(30) Level1 value for the current leaf of Account NUMBER Level1 surrogate key for the current leaf of Account
VARCHAR2(90) Level1 description for the current leaf of Account VARCHAR2(30) Level2 value for the current leaf of Account NUMBER Level2 surrogate key for the current leaf of Account
VARCHAR2(90) Level4 description for the current leaf of Account VARCHAR2(30) Level5 value for the current leaf of Account
115
Rapid Mart Data Schema ACCOUNT_HIER_PC
Column name LEVEL5_ACCOUNT_KE Y LEVEL5_DESCRIPTION LEVEL6_ACCOUNT LEVEL6_ACCOUNT_KE Y LEVEL6_DESCRIPTION LEVEL7_ACCOUNT LEVEL7_ACCOUNT_KE Y LEVEL7_DESCRIPTION LEVEL8_ACCOUNT LEVEL8_ACCOUNT_KE Y LEVEL8_DESCRIPTION LOAD_DATE LOAD_TIME
Key
Data type NUMBER
Column description Level5 surrogate key for the current leaf of Account
VARCHAR2(90) Level8 description for the current leaf of Account DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
ACCOUNT_HIER_PC
Natural Account key parent/child relationship hierarchy Column name ACCOUNT_KEY SETID PK Key Data type NUMBER Column description Surrogate key to child Account
VARCHAR2(1 SetID is used to differentiate between 5) Account values that belong to different Business Units
116
Rapid Mart Data Schema ACCOUNT_HIER_VR
Column name ACCOUNT DESCRIPTION EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS PARENT_ACCOUNT_KEY PARENT_ACCOUNT PARENT_DESCRIPTION LOAD_DATE LOAD_TIME
Key Data type PK
Column description
VARCHAR2(3 Child Account 0) VARCHAR2(9 Child Account description 0)
PK
DATE DATE
Effective from date Effective to date
VARCHAR2(1 Effective date current date indicator ) NUMBER Parent Account surrogate key VARCHAR2(3 Parent Account 0) VARCHAR2(9 Parent Account description 0) DATETIME Date and Time when the record was loaded into target system
VARCHAR2(8 Time when the record was loaded into ) the target system
ACCOUNT_HIER_VR
Natural Account key vertically flattened hierarchy Column name SETID Key Data type PK Column description
VARCHAR2(1 SetID is used to differentiate between 5) Account values that belong to different Business Units VARCHAR2(3 Ancestor Account code 0) VARCHAR2(3 Descendent Account code 0) DATE DATE Effective from date Effective to date
ANCESTOR_ACCOUNT DESCENDENT_ACCOUNT EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS MAXDEPTH DEPTH
PK PK PK
VARCHAR2(1 Effective date current date indicator ) NUMBER NUMBER Maximum depth of hierarchy Depth of the descendent
117
Rapid Mart Data Schema ACCOUNT_TYPE
Column name ROOT_FLAG LEAF_FLAG TREELEVEL ANCESTOR_ACCOUNT_KEY ANCESTOR_ACCOUNT_DES CR DESCENDENT_ACCOUNT_K EY DESCENDENT_ACCOUNT_D ESCR LOAD_DATE LOAD_TIME
Key Data type NUMBER NUMBER NUMBER NUMBER
Column description Root flag (1 means this is a root) Leaf flag (1 means this is a leaf) Tree level Ancestor Account surrogate key
VARCHAR2(9 Ancestor Account description 0) NUMBER Descendent Account surrogate key
VARCHAR2(9 Descendent Account description 0) DATETIME Date and Time when the record was loaded into target system
ACCOUNT_TYPE
Dimension with Account Type attributes Column name ACCOUNT_TYPE_KEY SETID Key PK Data type NUMBER Column description Surrogate key to ACCOUNT_TYPE
VARCHAR2(15) SetID is used to differentiate between Account Type values that belong to different Business Units VARCHAR2(3) Account Type code VARCHAR2(90) Account Type long description VARCHAR2(30) Account Type short description VARCHAR2(3) DATETIME VARCHAR2(8) Account Type balance forward indicator Date and Time when the record was loaded into target system Time when the record was loaded into the target system
ACCOUNT_TYPE DESCR DESCRSHORT BALANCE_FWD_SW LOAD_DATE LOAD_TIME
118
Rapid Mart Data Schema AFFILIATE
AFFILIATE
Dimension with inter-company attributes Column name AFFILIATE_KEY AFFILIATE DESCR DESCRSHORT LOAD_DATE LOAD_TIME Key PK Data type NUMBER Column description Surrogate key to AFFILIATE
VARCHAR2(15) Affiliate code VARCHAR2(90) Affiliate long description VARCHAR2(30) Affiliate short description DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
ALTACCOUNT
Dimension with Alternate Account attributes Column name ALTACCOUNT_KEY SETID Key PK Data type NUMBER VARCHAR2(15) Column description Surrogate key to ALTACCOUNT SetID is used to differentiate between Alternate Account values that belong to different Business Units Alternate account code Effective from date Effective Status Alternate account long description Alternate account short description Unit of measure Statistics account indicator Alternate account balance forward indicator Balance sheet indicator Account type Effective to date
ALTACCOUNT EFFDT EFF_STATUS DESCR DESCRSHORT UNIT_OF_MEASURE STATISTICS_ACCOUN T BALANCE_FWD_SW BSHEET_IND_DESCR ACCOUNT_TYPE TO_EFFDT
VARCHAR2(30) DATETIME VARCHAR2(1) VARCHAR2(90) VARCHAR2(30) VARCHAR2(9) VARCHAR2(3) VARCHAR2(3) VARCHAR2(30) VARCHAR2(3) DATETIME
119
Rapid Mart Data Schema ALTACCOUNT_HIER_HZ
Column name CURRENT_IND LOAD_DATE LOAD_TIME
Key
Data type VARCHAR2(1) DATETIME VARCHAR2(8)
Column description Effective date current date indicator Date and Time when the record was loaded into target system Time when the record was loaded into the target system
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_HZ
Natural Alternate Account key horizontally flattened hierarchy. Column name SETID Key PK Data type Column description
VARCHAR2(10) SetID is used to differentiate between Alternate Account values that belong to different Business Units VARCHAR2(30) Current leaf Alternate Account value DATE DATE VARCHAR2(1) NUMBER NUMBER Effective from date Effective to date Effective date current date indicator Leaf level in horizontal flattening Maximum depth of hierarchy
ALTACCOUNT EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS LEAF_LEVEL MAXDEPTH LEVEL0_ALTACCOUNT LEVEL0_ALTACCOUNT_ KEY LEVEL0_DESCRIPTION LEVEL1_ALTACCOUNT
PK PK
VARCHAR2(30) Level0 (root) value for the current leaf of Alternate Account NUMBER Level0 (root) surrogate key for the current leaf of Alternate Account
VARCHAR2(90) Level0 (root) description for the current leaf of Alternate Account VARCHAR2(30) Level1 value for the current leaf of Alternate Account
120
Rapid Mart Data Schema ALTACCOUNT_HIER_HZ
Column name LEVEL1_ALTACCOUNT_ KEY LEVEL1_DESCRIPTION LEVEL2_ALTACCOUNT LEVEL2_ALTACCOUNT_ KEY LEVEL2_DESCRIPTION LEVEL3_ALTACCOUNT LEVEL3_ALTACCOUNT_ KEY LEVEL3_DESCRIPTION LEVEL4_ALTACCOUNT LEVEL4_ALTACCOUNT_ KEY LEVEL4_DESCRIPTION LEVEL5_ALTACCOUNT LEVEL5_ALTACCOUNT_ KEY LEVEL5_DESCRIPTION LEVEL6_ALTACCOUNT LEVEL6_ALTACCOUNT_ KEY LEVEL6_DESCRIPTION LEVEL7_ALTACCOUNT
Key
Data type NUMBER
Column description Level1 surrogate key for the current leaf of Alternate Account
VARCHAR2(90) Level1 description for the current leaf of Alternate Account VARCHAR2(30) Level2 value for the current leaf of Alternate Account NUMBER Level2 surrogate key for the current leaf of Alternate Account
VARCHAR2(90) Level6 description for the current leaf of Alternate Account VARCHAR2(30) Level7 value for the current leaf of Alternate Account
121
Rapid Mart Data Schema ALTACCOUNT_HIER_PC
Column name LEVEL7_ALTACCOUNT_ KEY LEVEL7_DESCRIPTION LEVEL8_ALTACCOUNT LEVEL8_ALTACCOUNT_ KEY LEVEL8_DESCRIPTION LOAD_DATE LOAD_TIME
Key
Data type NUMBER
Column description Level7 surrogate key for the current leaf of Alternate Account
VARCHAR2(90) Level8 description for the current leaf of Alternate Account DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
ALTACCOUNT_HIER_PC
Natural Alternate Account key parent/child relationship hierarchy Column name ALTACCOUNT_KEY SETID PK Key Data type NUMBER Column description Surrogate key to child Alternate Account
VARCHAR2(1 SetID is used to differentiate between 5) Alternate Account values that belong to different Business Units VARCHAR2(3 Child Alternate Account 0) VARCHAR2(9 Child Alternate Account description 0)
ALTACCOUNT DESCRIPTION EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS PARENT_ALTACCOUNT_KE Y PARENT_ALTACCOUNT
PK
PK
DATE DATE
VARCHAR2(1 Effective date current date indicator ) NUMBER Parent Alternate Account surrogate key
VARCHAR2(3 Parent Alternate Account 0)
122
Rapid Mart Data Schema ALTACCOUNT_HIER_VR
Column name PARENT_DESCRIPTION LOAD_DATE LOAD_TIME
Key Data type
Column description
VARCHAR2(9 Parent Alternate Account description 0) DATETIME Date and Time when the record was loaded into target system
ALTACCOUNT_HIER_VR
Natural Alternate Account key vertically flattened hierarchy Column name SETID Key PK Data type VARCHAR2(1 5) Column description SetID is used to differentiate between Alternate Account values that belong to different Business Units
ANCESTOR_ALTACCOUNT DESCENDENT_ALTACCOUNT EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS MAXDEPTH DEPTH ROOT_FLAG LEAF_FLAG TREELEVEL ANCESTOR_ALTACCOUNT_K EY ANCESTOR_ALTACCOUNT_D ESCR DESCENDENT_ALTACCOUNT _KEY DESCENDENT_ALTACCOUNT _DESCR
PK PK PK
VARCHAR2(3 Ancestor Alternate Account code 0) VARCHAR2(3 0) DATE DATE NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2(9 0) NUMBER VARCHAR2(9 0) Descendent Alternate Account code Effective from date Effective to date Maximum depth of hierarchy Depth of the descendent Root flag (1 means this is a root) Leaf flag (1 means this is a leaf) Tree level Ancestor Alternate Account surrogate key Ancestor Alternate Account description Descendent Alternate Account surrogate key Descendent Alternate Account description
VARCHAR2(1) Effective date current date indicator
123
Rapid Mart Data Schema AW_JOBEXECUTION
Column name LOAD_DATE LOAD_TIME
Key
Data type DATETIME
Column description Date and Time when the record was loaded into target system
VARCHAR2(8) Time when the record was loaded into the target system
AW_JOBEXECUTION
Data Integrator internal table to trace job execution status Column name NAME STATUS EXTRACTLOW EXTRACTHIGH Key PK Data type Column description
VARCHAR2(64) Job name VARCHAR2(12) Job run status VARCHAR2(10) Extract start date VARCHAR2(10) Extract end date
BUDGET_FACT
General Ledger Budget balances Column name BUSINESS_UNIT_KEY LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY OPERATING_UNIT_KE Y PRODUCT_KEY PROJECT_KEY Key PK PK PK PK PK PK PK PK Data type NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER Column description Surrogate key to the BUSINESS_UNIT dimension table Surrogate key to the LEDGER dimension table Surrogate key to the ACCOUNT dimension table Surrogate key to the ALTACCOUNT dimension table Surrogate key to the DEPARTMENT dimension table Surrogate key to the OPERATING_UNIT dimension table Surrogate key to the PRODUCT dimension table Surrogate key to the PROJECT dimension table
124
Rapid Mart Data Schema BUDGET_FACT
Column name AFFILIATE_KEY SCENARIO_KEY CURRENCY_KEY STATISTIC_KEY BUDGET_PERIOD FISCAL_YEAR COMPANY_KEY ACCOUNT_TYPE_KEY TIME_KEY POSTED_TOTAL_AMT POSTED_BASE_AMT POSTED_TRAN_AMT BASE_CURRENCY_KE Y DTTM_STAMP_SEC LOAD_DATE LOAD_TIME
Key PK PK PK PK PK PK
Data type NUMBER NUMBER NUMBER NUMBER
Column description Surrogate key to the AFFILIATE dimension table Surrogate key to the SCENARIO dimension table Surrogate key to the CURRENCY dimension table Surrogate key to the STATISTIC dimension table Fiscal Year of posted transaction Accounting Period of posted transaction Surrogate key to the COMPANY dimension table Surrogate key to the ACCOUNT_TYPE dimension table Surrogate key to the TIME_DIMENSION dimension table Posted total amount in reporting currency Posted total amount in base currency Posted total amount in local currency Surrogate key to base currency Date and time stamp of posted transaction Date and Time when the record was loaded into target system Time when the record was loaded into the target system
VARCHAR2(30) Budget period NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER DATETIME DATETIME VARCHAR2(8)
ACCOUNTING_PERIOD PK
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.
125
Rapid Mart Data Schema BUSINESS_UNIT
BUSINESS_UNIT
Dimension with Business Unit attributes Column name BUSINESS_UNIT_KEY BUSINESS_UNIT BASE_CURRENCY_KE Y DESCR DESCRSHORT LOAD_DATE LOAD_TIME Key PK Data type NUMBER VARCHAR2(15) NUMBER VARCHAR2(90) VARCHAR2(30) DATETIME VARCHAR2(8) Column description Surrogate key to BUSINESS_UNIT Business unit code Base currency identifying key Business unit long description Business unit short description Date and Time when the record was loaded Time in a string format when the record was loaded
COMPANY
Dimension with Company attributes Column name COMPANY_KEY COMPANY EFFDT TO_EFFDT CURRENT_IND EFF_STATUS DESCR DESCRSHORT COUNTRY GEO_CODE LOAD_DATE LOAD_TIME Key PK Data type NUMBER VARCHAR2(9) DATETIME DATETIME VARCHAR2(1) VARCHAR2(1) Column description Surrogate key to COMPANY Company code Effective from date Effective to date Effective date current date indicator Effective status (Active or Inactive)
VARCHAR2(90) Company long description VARCHAR2(30) Company short description VARCHAR2(9) DATETIME VARCHAR2(8) Country code Date and Time when the record was loaded into target system Time when the record was loaded into the target system VARCHAR2(33) Geography code
126
Rapid Mart Data Schema CURRENCY
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.
CURRENCY
Dimension with Currency attributes Column name CURRENCY_KEY CURRENCY EFFDT TO_EFFDT CURRENT_IND EFF_STATUS DESCR DESCRSHORT COUNTRY CUR_SYMBOL LOAD_DATE LOAD_TIME Key PK Data type NUMBER VARCHAR2(9) DATETIME DATETIME VARCHAR2(1) VARCHAR2(3) Column description Surrogate key to CURRENCY Currency code Effective from date Effective to date Effective date current date indicator Effective status (Active or Inactive)
VARCHAR2(90) Currency long description VARCHAR2(30) Currency short description VARCHAR2(9) DATETIME VARCHAR2(8) Country code Date and Time when the record was loaded into target system Time when the record was loaded into the target system VARCHAR2(12) Currency symbol
DEPARTMENT
Dimension with Department attributes Column name DEPARTMENT_KEY SETID Key PK Data type NUMBER VARCHAR2(15) Column description Surrogate key to DEPARTMENT SetID is used to differentiate between Department values that belong to different Business Units Department code Effective from date
DEPTID EFFDT
VARCHAR2(30) DATETIME
127
Rapid Mart Data Schema DEPARTMENT_HIER_HZ
Column name TO_EFFDT EFF_STATUS DESCR DESCRSHORT COMPANY_KEY LOCATION LOCATION_KEY
Key
Data type DATETIME VARCHAR2(1) VARCHAR2(90) VARCHAR2(30) NUMBER VARCHAR2(30) NUMBER
Column description Effective to date Effective status (Active or Inactive) Department long description Department short description Surrogate key to COMPANY Departments location Surrogate key to LOCATION (-1 in this rapid mart. Used by PSFT HR rapid mart) Manager Position Manager Name Controlling budget department Surrogate key to EMPLOYEE. (-1 in this rapid mart. Used by PSFT HR rapid mart) Surrogate key to EMPLOYEE. (-1 in this rapid mart. Used by PSFT HR rapid mart) Surrogate key to DEPARTMENT to identify budget department Effective date current date indicator Date and Time when the record was loaded Time in a string format when the record was loaded
MANAGER_POSN MANAGER_NAME BUDGET_DEPTID MANAGER_POSITION_ KEY MANAGER_EMPLOYEE _KEY BUDGET_DEPARTMEN T_KEY CURRENT_IND LOAD_DATE LOAD_TIME
VARCHAR2(24) VARCHAR2(90) VARCHAR2(30) NUMBER
NUMBER
NUMBER VARCHAR2(1) DATETIME VARCHAR2(8)
DEPARTMENT_HIER_HZ
Natural Department key horizontally flattened hierarchy. Column name SETID Key PK Data type Column description
VARCHAR2(10) SetID is used to differentiate between Department values that belong to different Business Units VARCHAR2(30) Current leaf Department value
DEPTID
PK
128
Column name EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS LEAF_LEVEL MAXDEPTH LEVEL0_DEPTID LEVEL0_DEPARTMENT_ KEY LEVEL0_DESCRIPTION LEVEL1_DEPTID LEVEL1_DEPARTMENT_ KEY LEVEL1_DESCRIPTION LEVEL2_DEPTID LEVEL2_DEPARTMENT_ KEY LEVEL2_DESCRIPTION LEVEL3_DEPTID LEVEL3_DEPARTMENT_ KEY LEVEL3_DESCRIPTION LEVEL4_DEPTID LEVEL4_DEPARTMENT_ KEY LEVEL4_DESCRIPTION
Key PK
Data type DATE DATE VARCHAR2(1) NUMBER NUMBER
Column description Effective from date Effective to date Effective date current date indicator Leaf level in horizontal flattening Maximum depth of hierarchy
VARCHAR2(30) Level0 (root) value for the current leaf of Department NUMBER Level0 (root) surrogate key for the current leaf of Department
VARCHAR2(90) Level0 (root) description for the current leaf of Department VARCHAR2(30) Level1 value for the current leaf of Department NUMBER Level1 surrogate key for the current leaf of Department
VARCHAR2(90) Level1 description for the current leaf of Department VARCHAR2(30) Level2 value for the current leaf of Department NUMBER Level2 surrogate key for the current leaf of Department
VARCHAR2(90) Level4 description for the current leaf of Department
129
Column name LEVEL5_DEPTID LEVEL5_DEPARTMENT_ KEY LEVEL5_DESCRIPTION LEVEL6_DEPTID LEVEL6_DEPARTMENT_ KEY LEVEL6_DESCRIPTION LEVEL7_DEPTID LEVEL7_DEPARTMENT_ KEY LEVEL7_DESCRIPTION LEVEL8_DEPTID LEVEL8_DEPARTMENT_ KEY LEVEL8_DESCRIPTION LOAD_DATE LOAD_TIME
Key
Data type
Column description
VARCHAR2(30) Level5 value for the current leaf of Department NUMBER Level5 surrogate key for the current leaf of Department
VARCHAR2(90) Level8 description for the current leaf of Department DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
130
Rapid Mart Data Schema DEPARTMENT_HIER_PC
DEPARTMENT_HIER_PC
Natural Department key parent/child relationship hierarchy Column name DEPARTMENT_KEY SETID PK Key Data type NUMBER Column description Surrogate key to child Department
VARCHAR2(1 SetID is used to differentiate between 5) Department values that belong to different Business Units VARCHAR2(3 Child Department 0) VARCHAR2(9 Child Department description 0)
DEPTID DESCRIPTION EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS PARENT_DEPARTMENT_KE Y PARENT_DEPTID PARENT_DESCRIPTION LOAD_DATE LOAD_TIME
PK
PK
DATE DATE
VARCHAR2(1 Effective date current date indicator ) NUMBER Parent Department surrogate key
VARCHAR2(3 Parent Department 0) VARCHAR2(9 Parent Department description 0) DATETIME Date and Time when the record was loaded into target system
DEPARTMENT_HIER_VR
Natural Department key vertically flattened hierarchy Column name SETID Key Data type PK Column description
VARCHAR2(1 SetID is used to differentiate between 5) Department values that belong to different Business Units VARCHAR2(3 Ancestor Department code 0)
DEPTID
PK
131
Rapid Mart Data Schema FISCAL_CALENDAR
Column name DESCENDENT_DEPTID EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS MAXDEPTH DEPTH ROOT_FLAG LEAF_FLAG TREELEVEL DEPARTMENT_KEY DEPARTMENT DESCENDENT_DEPARTMEN T_KEY DESCENDENT_DEPARTMEN T LOAD_DATE LOAD_TIME
Key Data type PK PK
Column description
VARCHAR2(3 Descendent Department code 0) DATE DATE Effective from date Effective to date
VARCHAR2(1 Effective date current date indicator ) NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER Maximum depth of hierarchy Depth of the descendent Root flag (1 means this is a root) Leaf flag (1 means this is a leaf) Tree level Ancestor Department surrogate key
VARCHAR2(9 Ancestor Department description 0) NUMBER Descendent Department surrogate key
VARCHAR2(9 Descendent Department description 0) DATETIME Date and Time when the record was loaded into target system
FISCAL_CALENDAR
Time dimension built with the monthly granularity of fiscal months Column name FISCAL_YEAR Key PK Data type NUMBER NUMBER Column description Fiscal year. Used to link to FISCAL_YEAR of the fact tables. Accounting period. Used to link to ACCOUNTING_PERIOD of the fact tables.
PERIOD_NAME PERIOD_ABBRV
VARCHAR2(30) Period description VARCHAR2(30) Abbreviated period description
132
Rapid Mart Data Schema JOURNAL_FACT
Column name CURRENT_FISCAL_YE AR CURRENT_ACCOUNTI NG_PERIOD LOAD_DATE LOAD_TIME
Key
Data type
Column description
VARCHAR2(30) Current fiscal year indicator (Y or N) VARCHAR2(30) Current accounting period indicator (Y or N) DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
JOURNAL_FACT
General Ledger journal header and line entries Column name BUSINESS_UNIT_KEY JOURNAL_ID JOURNAL_DATE UNPOST_SEQ JOURNAL_LINE LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY OPERATING_UNIT_KE Y PRODUCT_KEY PROJECT_KEY AFFILIATE_KEY Key PK PK PK PK PK PK Data type NUMBER Column description Surrogate key to the BUSINESS_UNIT dimension table Journal entry date Unpost sequence number Journal entry line number Surrogate key to the LEDGER dimension table Surrogate key to the ACCOUNT dimension table Surrogate key to the ALTACCOUNT dimension table Surrogate key to the DEPARTMENT dimension table Surrogate key to the OPERATING_UNIT dimension table Surrogate key to the PRODUCT dimension table Surrogate key to the PROJECT dimension table Surrogate key to the AFFILIATE dimension table
VARCHAR2(30) Journal identifier DATETIME NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER
133
Rapid Mart Data Schema JOURNAL_FACT
Column name SCENARIO_KEY CURRENCY_KEY STATISTIC_KEY SOURCE_KEY COMPANY_KEY ACCOUNT_TYPE_KEY TIME_KEY MONETARY_AMOUNT STATISTIC_AMOUNT JRNL_LN_REF LINE_DESCR JRNL_LINE_STATUS FOREIGN_CURRENCY RT_TYPE FOREIGN_AMOUNT FISCAL_YEAR ACCOUNTING_PERIOD JRNL_EDIT_ERR_STAT JRNL_HDR_STATUS LOAD_DATE LOAD_TIME
Key
Data type NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER
Column description Surrogate key to the SCENARIO dimension table Surrogate key to the CURRENCY dimension table Surrogate key to the STATISTIC dimension table Surrogate key to the SOURCE dimension table Surrogate key to the COMPANY dimension table Surrogate key to the ACCOUNT_TYPE dimension table Surrogate key to the TIME_DIMENSION dimension table Jounral entry amount Journal entry fro statistic accounts
VARCHAR2(30) Journal entry line reference VARCHAR2(90) Journal entry line description VARCHAR2(30) Journal entry line status VARCHAR2(9) NUMBER NUMBER NUMBER Local currency Journal entry local amount Fiscal Year of posted transaction Accounting Period of posted transaction VARCHAR2(15) Rate type
VARCHAR2(30) Journal entry error status description VARCHAR2(30) Journal header status DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
134
Rapid Mart Data Schema LEDGER
LEDGER
Dimension with Ledger attributes Column name LEDGER_KEY SETID Key PK Data type NUMBER Column description Surrogate key to LEDGER
VARCHAR2(15) SetID is used to differentiate between Ledger values that belong to different Business Units VARCHAR2(30) Ledger code VARCHAR2(90) Ledger description DATETIME DATETIME VARCHAR2(1) Effective from date Effective to date Effective date current date indicator
LEDGER DESCR EFFDT TO_EFFDT CURRENT_IND LED_TYPE_DESCR BUD_TYPE_DESCR LOAD_DATE LOAD_TIME
VARCHAR2(30) Ledger type description VARCHAR2(30) Budget type description DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
LEDGER_FACT
General Ledger balances Column name BUSINESS_UNIT_KEY LEDGER_KEY ACCOUNT_KEY ALTACCOUNT_KEY DEPARTMENT_KEY Key PK PK PK PK PK Data type NUMBER NUMBER NUMBER NUMBER NUMBER Column description Surrogate key to the BUSINESS_UNIT dimension table Surrogate key to the LEDGER dimension table Surrogate key to the ACCOUNT dimension table Surrogate key to the ALTACCOUNT dimension table Surrogate key to the DEPARTMENT dimension table
135
Rapid Mart Data Schema LEDGER_FACT
Column name OPERATING_UNIT_KE Y PRODUCT_KEY PROJECT_KEY AFFILIATE_KEY CURRENCY_KEY STATISTIC_KEY FISCAL_YEAR COMPANY_KEY ACCOUNT_TYPE_KEY TIME_KEY POSTED_TOTAL_AMT POSTED_BASE_AMT POSTED_TRAN_AMT BASE_CURRENCY_KE Y DTTM_STAMP_SEC LOAD_DATE LOAD_TIME
Key PK PK PK PK PK PK PK
Data type NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER DATETIME DATETIME VARCHAR2(8)
Column description Surrogate key to the OPERATING_UNIT dimension table Surrogate key to the PRODUCT dimension table Surrogate key to the PROJECT dimension table Surrogate key to the AFFILIATE dimension table Surrogate key to the CURRENCY dimension table Surrogate key to the STATISTIC dimension table Fiscal Year of posted transaction Accounting Period of posted transaction Surrogate key to the COMPANY dimension table Surrogate key to the ACCOUNT_TYPE dimension table Surrogate key to the TIME_DIMENSION dimension table Posted total amount in reporting currency Posted total amount in base currency Posted total amount in local currency Surrogate key to base currency Date and time stamp of posted transaction Date and Time when the record was loaded into target system Time when the record was loaded into the target system
136
Rapid Mart Data Schema MONTH_DIMENSION
MONTH_DIMENSION
Dimension that works in conjuction with TIME_DIMENSION to provide monthly granualarity of fact table data Column name MONTH_KEY Key PK Data type NUMBER Column description Smart key in format YYYYMM. Used to link to MONTH_KEY in TIME_DIMENSION Calendar month number Calendar quarter number Year Date and Time when the record was loaded into target system Time when the record was loaded into the target system
MONTH QUARTER YEAR LOAD_DATE LOAD_TIME
NUMBER NUMBER NUMBER DATETIME VARCHAR2(8)
OPERATING_UNIT
Dimension with Operating Unit attributes Column name OPERATING_UNIT_KE Y SETID Key PK Data type NUMBER(15) VARCHAR2(15) Column description Surrogate key to OPERATING_UNIT SetID is used to differentiate between Operating Unit values that belong to different Business Units Operating unit code Effective from date Effective status (Active or Inactive) Operating unit long description Operating unit short description Effective to date Effective date current date indicator
OPERATING_UNIT EFFDT EFF_STATUS DESCR DESCRSHORT TO_EFFDT CURRENT_IND
VARCHAR2(24) DATETIME VARCHAR2(1) VARCHAR2(90) VARCHAR2(30) DATETIME VARCHAR2(1)
137
Rapid Mart Data Schema OPERATING_UNIT_HIER_HZ
Key
Data type DATETIME VARCHAR2(8)
Column description Date and Time when the record was loaded Time in a string format when the record was loaded
OPERATING_UNIT_HIER_HZ
Natural Operating Unit key horizontally flattened hierarchy. Column name SETID Key PK Data type Column description
VARCHAR2(10) SetID is used to differentiate between Operating Unit values that belong to different Business Units VARCHAR2(30) Current leaf Operating Unit value DATE DATE VARCHAR2(1) NUMBER NUMBER Effective from date Effective to date Effective date current date indicator Leaf level in horizontal flattening Maximum depth of hierarchy
OPERUNIT EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS LEAF_LEVEL MAXDEPTH LEVEL0_OPERUNIT LEVEL0_OPERUNIT_K EY LEVEL0_DESCRIPTION LEVEL1_OPERUNIT LEVEL1_OPERUNIT_K EY LEVEL1_DESCRIPTION LEVEL2_OPERUNIT LEVEL2_OPERUNIT_K EY
PK PK
VARCHAR2(30) Level0 (root) value for the current leaf of Operating Unit NUMBER Level0 (root) surrogate key for the current leaf of Operating Unit
VARCHAR2(90) Level0 (root) description for the current leaf of Operating Unit VARCHAR2(30) Level1 value for the current leaf of Operating Unit NUMBER Level1 surrogate key for the current leaf of Operating Unit
VARCHAR2(90) Level1 description for the current leaf of Operating Unit VARCHAR2(30) Level2 value for the current leaf of Operating Unit NUMBER Level2 surrogate key for the current leaf of Operating Unit
138
Rapid Mart Data Schema OPERATING_UNIT_HIER_HZ
Column name LEVEL2_DESCRIPTION LEVEL3_OPERUNIT LEVEL3_OPERUNIT_K EY LEVEL3_DESCRIPTION LEVEL4_OPERUNIT LEVEL4_OPERUNIT_K EY LEVEL4_DESCRIPTION LEVEL5_OPERUNIT LEVEL5_OPERUNIT_K EY LEVEL5_DESCRIPTION LEVEL6_OPERUNIT LEVEL6_OPERUNIT_K EY LEVEL6_DESCRIPTION LEVEL7_OPERUNIT LEVEL7_OPERUNIT_K EY LEVEL7_DESCRIPTION LEVEL8_OPERUNIT LEVEL8_OPERUNIT_K EY
Key
Data type
Column description
139
Rapid Mart Data Schema OPERATING_UNIT_HIER_PC
Column name LEVEL8_DESCRIPTION LOAD_DATE LOAD_TIME
Key
Data type
Column description
VARCHAR2(90) Level8 description for the current leaf of Operating Unit DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
OPERATING_UNIT_HIER_PC
Natural Operating Unit key parent/child relationship hierarchy Column name OPER_UNIT_KEY SETID PK Key Data type NUMBER Column description Surrogate key to child Operating Unit
VARCHAR2(1 SetID is used to differentiate between 5) Operating Unit values that belong to different Business Units VARCHAR2(3 Child Operating Unit 0) VARCHAR2(9 Child Operating Unit description 0)
OPER_UNIT DESCRIPTION EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS PARENT_OPER_UNIT_KEY PARENT_OPER_UNIT PARENT_DESCRIPTION LOAD_DATE LOAD_TIME
PK
PK
DATE DATE
VARCHAR2(1 Effective date current date indicator ) NUMBER Parent Operating Unit surrogate key VARCHAR2(3 Parent Operating Unit 0) VARCHAR2(9 Parent Operating Unit description 0) DATETIME Date and Time when the record was loaded into target system
140
Rapid Mart Data Schema OPERATING_UNIT_HIER_VR
OPERATING_UNIT_HIER_VR
Natural Operating Unit key vertically flattened hierarchy Column name SETID Key Data type PK Column description
VARCHAR2(1 SetID is used to differentiate between 5) Operating Unit values that belong to different Business Units VARCHAR2(3 Ancestor Operating Unit code 0) VARCHAR2(3 Descendent Operating Unit code 0) DATE DATE Effective from date Effective to date
ANCESTOR_OPERUNIT DESCENDENT_OPERUNIT EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS MAXDEPTH DEPTH ROOT_FLAG LEAF_FLAG TREELEVEL ANCESTOR_OPERUNIT_KE Y ANCESTOR_OPERUNIT_DE SCR DESCENDENT_OPERUNIT_ KEY DESCENDENT_OPERUNIT_ DESCR LOAD_DATE LOAD_TIME
PK PK PK
VARCHAR2(1 Effective date current date indicator ) NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER Maximum depth of hierarchy Depth of the descendent Root flag (1 means this is a root) Leaf flag (1 means this is a leaf) Tree level Ancestor Operating Unit surrogate key
VARCHAR2(9 Ancestor Operating Unit description 0) NUMBER Descendent Operating Unit surrogate key
VARCHAR2(9 Descendent Operating Unit 0) description DATETIME Date and Time when the record was loaded into target system
141
Rapid Mart Data Schema PRODUCT
PRODUCT
Dimension with Product attributes Column name PRODUCT_KEY SETID Key PK Data type NUMBER Column description Surrogate key to PRODUCT
VARCHAR2(15) SetID is used to differentiate between Product values that belong to different Business Units VARCHAR2(18) Product code DATETIME VARCHAR2(1) Effective from date Effective status (Active or Inactive)
PRODUCT EFFDT EFF_STATUS DESCR DESCRSHORT ACCOUNTING_OWNER TO_EFFDT CURRENT_IND LOAD_DATE LOAD_TIME
VARCHAR2(90) Product long description VARCHAR2(30) Product short description VARCHAR2(90) Accounting owner DATETIME VARCHAR2(1) DATETIME VARCHAR2(8) Effective to date Effective date current date indicator Date and Time when the record was loaded into target system Time when the record was loaded into the target system
PRODUCT_HIER_HZ
Natural Product key horizontally flattened hierarchy. Column name SETID Key PK Data type Column description
VARCHAR2(10) SetID is used to differentiate between Product values that belong to different Business Units VARCHAR2(30) Current leaf Product value DATE DATE VARCHAR2(1) NUMBER NUMBER Effective from date Effective to date Effective date current date indicator Leaf level in horizontal flattening Maximum depth of hierarchy
PRODUCT EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS LEAF_LEVEL MAXDEPTH
PK PK
142
Rapid Mart Data Schema PRODUCT_HIER_HZ
Column name LEVEL0_PRODUCT LEVEL0_PRODUCT_KE Y LEVEL0_DESCRIPTION LEVEL1_PRODUCT LEVEL1_PRODUCT_KE Y LEVEL1_DESCRIPTION LEVEL2_PRODUCT LEVEL2_PRODUCT_KE Y LEVEL2_DESCRIPTION LEVEL3_PRODUCT LEVEL3_PRODUCT_KE Y LEVEL3_DESCRIPTION LEVEL4_PRODUCT LEVEL4_PRODUCT_KE Y LEVEL4_DESCRIPTION LEVEL5_PRODUCT LEVEL5_PRODUCT_KE Y LEVEL5_DESCRIPTION
Key
Data type
Column description
VARCHAR2(30) Level0 (root) value for the current leaf of Product NUMBER Level0 (root) surrogate key for the current leaf of Product
VARCHAR2(90) Level0 (root) description for the current leaf of Product VARCHAR2(30) Level1 value for the current leaf of Product NUMBER Level1 surrogate key for the current leaf of Product
VARCHAR2(90) Level1 description for the current leaf of Product VARCHAR2(30) Level2 value for the current leaf of Product NUMBER Level2 surrogate key for the current leaf of Product
VARCHAR2(90) Level5 description for the current leaf of Product
143
Rapid Mart Data Schema PRODUCT_HIER_PC
Column name LEVEL6_PRODUCT LEVEL6_PRODUCT_KE Y LEVEL6_DESCRIPTION LEVEL7_PRODUCT LEVEL7_PRODUCT_KE Y LEVEL7_DESCRIPTION LEVEL8_PRODUCT LEVEL8_PRODUCT_KE Y LEVEL8_DESCRIPTION LOAD_DATE LOAD_TIME
Key
Data type
Column description
VARCHAR2(30) Level6 value for the current leaf of Product NUMBER Level6 surrogate key for the current leaf of Product
VARCHAR2(90) Level8 description for the current leaf of Product DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
PRODUCT_HIER_PC
Natural Product key parent/child relationship hierarchy Column name PRODUCT_KEY SETID PK Key Data type NUMBER Column description Surrogate key to child Product
VARCHAR2(1 SetID is used to differentiate between 5) Product values that belong to different Business Units VARCHAR2(3 Child Product 0) VARCHAR2(9 Child Product description 0)
PRODUCT DESCRIPTION EFFECTIVE_FM_DT
PK
PK
DATE
Effective from date
144
Rapid Mart Data Schema PRODUCT_HIER_VR
Column name EFFECTIVE_TO_DT CURRENT_STATUS PARENT_PRODUCT_KEY PARENT_PRODUCT PARENT_DESCRIPTION LOAD_DATE LOAD_TIME
Key Data type DATE
Column description Effective to date
VARCHAR2(1 Effective date current date indicator ) NUMBER Parent Product surrogate key VARCHAR2(3 Parent Product 0) VARCHAR2(9 Parent Product description 0) DATETIME Date and Time when the record was loaded into target system
PRODUCT_HIER_VR
Natural Product key vertically flattened hierarchy Column name SETID Key Data type PK Column description
VARCHAR2(1 SetID is used to differentiate between 5) Product values that belong to different Business Units VARCHAR2(3 Ancestor Product code 0) VARCHAR2(3 Descendent Product code 0) DATE DATE Effective from date Effective to date
ANCESTOR_PRODUCT DESCENDENT_PRODUCT EFFECTIVE_FM_DT EFFECTIVE_TO_DT CURRENT_STATUS MAXDEPTH DEPTH ROOT_FLAG LEAF_FLAG TREELEVEL ANCESTOR_PRODUCT_KEY
PK PK PK
VARCHAR2(1 Effective date current date indicator ) NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER Maximum depth of hierarchy Depth of the descendent Root flag (1 means this is a root) Leaf flag (1 means this is a leaf) Tree level Ancestor Product surrogate key
145
Rapid Mart Data Schema PROJECT
Column name ANCESTOR_PRODUCT_DES CR DESCENDENT_PRODUCT_K EY DESCENDENT_PRODUCT_D ESCR LOAD_DATE LOAD_TIME
Key Data type
Column description
VARCHAR2(9 Ancestor Product description 0) NUMBER Descendent Product surrogate key
VARCHAR2(9 Descendent Product description 0) DATETIME Date and Time when the record was loaded into target system
PROJECT
Dimension with Project attributes Column name PROJECT_KEY SETID Key PK Data type NUMBER Column description Surrogate key to PROJECT_ID
VARCHAR2(15) SetID is used to differentiate between Project values that belong to different Business Units VARCHAR2(15) Project code VARCHAR2(90) Project description DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
PROJECT_ID DESCR LOAD_DATE LOAD_TIME
SCENARIO
Dimension with Scenario attributes Column name SCENARIO_KEY SETID Key PK Data type NUMBER Column description Surrogate key to SCENARIO
VARCHAR2(15) SetID is used to differentiate between Scenario values that belong to different Business Units
146
Rapid Mart Data Schema SOURCE
Column name SCENARIO EFFDT EFF_STATUS DESCR DESCRSHORT TO_EFFDT CURRENT_IND LOAD_DATE LOAD_TIME
Key
Column description Effective from date Effective status (Active or Inactive)
VARCHAR2(30) Scenario code
VARCHAR2(90) Scenario long description VARCHAR2(30) Scenario short description DATETIME VARCHAR2(1) DATETIME VARCHAR2(8) Effective to date Effective date current date indicator Date and Time when the record was loaded into target system Time when the record was loaded into the target system
SOURCE
Dimension with Source attributes Column name SOURCE_KEY SETID Key PK Data type NUMBER Column description Surrogate key to SOURCE
VARCHAR2(15) SetID is used to differentiate between Source values that belong to different Business Units VARCHAR2(9) DATETIME VARCHAR2(1) DATETIME VARCHAR2(1) DATETIME VARCHAR2(8) Source value Effective from date Effective status (Active or Inactive) Effective to date Indicates current attributes based upon effective date Date and Time when the record was loaded into target system Time when the record was loaded into the target system
SOURCE EFFDT EFF_STATUS DESCR TO_EFFDT CURRENT_IND LOAD_DATE LOAD_TIME
VARCHAR2(90) Source description
147
Rapid Mart Data Schema STAGE_BUDGET_FACT
STAGE_BUDGET_FACT
Staging table used to split budget data processing between data extraction and data transformation Column name BUSINESS_UNIT LEDGER ACCOUNT ALTACCT OPERATING_UNIT DEPTID PRODUCT PROJECT_ID AFFILIATE SCENARIO CURRENCY_CD STATISTICS_CODE FISCAL_YEAR POSTED_TOTAL_AMT POSTED_BASE_AMT POSTED_TRAN_AMT BASE_CURRENCY DTTM_STAMP_SEC LOAD_DATE LOAD_TIME Key PK PK PK PK PK PK PK PK PK PK PK PK PK Data type Column description
VARCHAR2(15) Business Unit code VARCHAR2(30) Ledger code VARCHAR2(30) Account code VARCHAR2(30) Alternate account code VARCHAR2(24) Operating Unit code VARCHAR2(30) Department code VARCHAR2(18) Product code VARCHAR2(45) Project code VARCHAR2(15) Affiliate code VARCHAR2(30) Scenario code VARCHAR2(9) VARCHAR2(9) NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2(9) DATETIME DATETIME VARCHAR2(8) Currency code Statistics code Fiscal Year Accounting period Posted amount in reporting currency Posted amount in base currency Posted amount in local currency Base currency Date and timestamp when the balance was posted Date and Time when the record was loaded into target system Time when the record was loaded into the target system
148
Rapid Mart Data Schema STAGE_JOURNAL_FACT
STAGE_JOURNAL_FACT
Staging table used to split journal entry data processing between data extraction and data transformation Column name BUSINESS_UNIT JOURNAL_ID JOURNAL_DATE UNPOST_SEQ JOURNAL_LINE LEDGER ACCOUNT ALTACCT OPERATING_UNIT DEPTID PRODUCT PROJECT_ID AFFILIATE SCENARIO CURRENCY_CD STATISTICS_CODE SOURCE MONETARY_AMOUNT STATISTIC_AMOUNT JRNL_LN_REF LINE_DESCR JRNL_LINE_STATUS FOREIGN_CURRENCY RT_TYPE FOREIGN_AMOUNT FISCAL_YEAR ACCOUNTING_PERIOD Key PK PK PK PK PK PK Data type Column description
VARCHAR2(15) Business Unit code VARCHAR2(30) Journal identifier DATETIME NUMBER NUMBER Journal entry date Unpost sequence number Journal entry line number
VARCHAR2(30) Ledger code VARCHAR2(30) Account code VARCHAR2(30) Alternate account code VARCHAR2(24) Operating Unit code VARCHAR2(30) Department code VARCHAR2(18) Product code VARCHAR2(45) Project code VARCHAR2(15) Affiliate code VARCHAR2(30) Scenario code VARCHAR2(9) VARCHAR2(9) VARCHAR2(9) NUMBER NUMBER Currency code Statistics code Source code Journal entry amount Journal entry fro statistic accounts
VARCHAR2(30) Journal entry line reference VARCHAR2(90) Journal entry line description VARCHAR2(30) Journal entry line status VARCHAR2(9) NUMBER NUMBER NUMBER Local currency Journal entry local amount Fiscal Year of posted transaction Accounting Period of posted transaction VARCHAR2(15) Rate type
149
Rapid Mart Data Schema STAGE_LEDGER_FACT
Column name JRNL_EDIT_ERR_STAT JRNL_HDR_STATUS LOAD_DATE LOAD_TIME
Key
Data type
Column description
VARCHAR2(30) Journal entry error status description VARCHAR2(30) Journal header status DATETIME VARCHAR2(8) Date and Time when the record was loaded into target system Time when the record was loaded into the target system
STAGE_LEDGER_FACT
Staging table used to split budget data processing between data extraction and data transformation Column name BUSINESS_UNIT LEDGER ACCOUNT ALTACCT OPERATING_UNIT DEPTID PRODUCT PROJECT_ID AFFILIATE CURRENCY_CD STATISTICS_CODE FISCAL_YEAR ACCOUNTING_PERIO D POSTED_TOTAL_AMT POSTED_BASE_AMT POSTED_TRAN_AMT BASE_CURRENCY DTTM_STAMP_SEC Key PK PK PK PK PK PK PK PK PK PK PK PK PK Data type Column description
VARCHAR2(15) Business Unit code VARCHAR2(30) Ledger code VARCHAR2(30) Account code VARCHAR2(30) Alternate account code VARCHAR2(24) Operating Unit code VARCHAR2(30) Department code VARCHAR2(18) Product code VARCHAR2(45) Project code VARCHAR2(15) Affiliate code VARCHAR2(9) VARCHAR2(9) NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2(9) DATETIME Currency code Statistics code Fiscal Year Accounting period Posted amount in reporting currency Posted amount in base currency Posted amount in local currency Base currency Date and timestamp when the balance was posted
150
Rapid Mart Data Schema STATISTIC
Key
Column description Date and Time when the record was loaded into target system Time when the record was loaded into the target system
STATISTIC
Dimension with Statistic attributes Column name STATISTIC_KEY SETID Key PK Data type NUMBER Column description Surrogate key to STATISTICS_CODE
VARCHAR2(15) SetID is used to differentiate between Statistics values that belong to different Business Units VARCHAR2(9) DATETIME VARCHAR2(1) Statistics code Effective from date Effective status (Active or Inactive)
STATISTICS_CODE EFFDT EFF_STATUS DESCR DESCRSHORT UNIT_OF_MEASURE TO_EFFDT CURRENT_IND LOAD_DATE LOAD_TIME
VARCHAR2(90) Statistic long description VARCHAR2(30) Statistic short description VARCHAR2(9) DATETIME VARCHAR2(1) DATETIME VARCHAR2(8) Unit of measure Effective to date Indicates current attributes based upon effective date Date and Time when the record was loaded into target system Time when the record was loaded into the target system
151
Rapid Mart Data Schema TEMP_DEPARTMENT
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 Column name SETID Key PK Data type Column description
VARCHAR2(15) SetID is used to differentiate between Department values that belong to different Business Units VARCHAR2(30) Department code DATETIME DATETIME DATETIME VARCHAR2(8) Effective from date Effective to date Date and Time when the record was loaded into target system Time when the record was loaded into the target system VARCHAR2(30) Budget department code
DEPTID EFFDT BUDGET_DEPTID TO_EFFDT LOAD_DATE LOAD_TIME
PK PK
TIME_DIMENSION
Time 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. Column name TIME_KEY Key PK Data type NUMBER Column description Smart key in theformat YYYYMMDD. Used to link to TIME_KEY in the fact tables at a daily granularity. Smart key in the format YYYYMM. Used to link to MONTH_KEY in MONTH_DIMENSION at a monthly granularity Daily dates ranging between user defined star and end date
MONTH_KEY
NUMBER
DAY
DATETIME
152
Rapid Mart Data Schema TIME_DIMENSION
Column name MONTH QUARTER YEAR DAY_IN_WEEK WEEK_IN_YEAR IS_WEEKEND FISCAL_YEAR ACCOUNTING_PERIO D PERIOD_NAME PERIOD_ABBRV CURRENT_FISCAL_YE AR CURRENT_ACCOUNTI NG_PERIOD LOAD_DATE LOAD_TIME
Key
Data type NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2(1) NUMBER NUMBER VARCHAR2(90) VARCHAR2(9) VARCHAR2(1) VARCHAR2(1) DATETIME VARCHAR2(8)
Column description Calendar month numeric representation Calendar quarter numeric representation Year Numeric representation of the day in week Numeric representation of the week in year Numeric representation of weekday or weekend days Fiscal year Accounting period Period description Abbreviated period description Current fiscal year indicator (Y or N) Current accounting period indicator (Y or N) Date and Time when the record was loaded Time in a string format when the record was loaded
153
Rapid Mart Data Schema TIME_DIMENSION
154

Businessobjects Peoplesoft General Ledger Rapid Mart User'S Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Businessobjects Peoplesoft General Ledger Rapid Mart User'S Guide

Uploaded by

Copyright:

Available Formats

BusinessObjects PeopleSoft General Ledger Rapid Mart Users Guide