http://intelligentbusiness.wordpress.

com/2007/04/02/the-financial-data-mart/
The Financial Data Mart
2 April 2007 3 Comments
In many multi-part series, I will lay out the design for the Enterprise Data Warehouse from an Oracle
eBusiness Suite. Obviously, these will be by business areas. I will start with the core financial module
the General Ledger. Lets try to put a structure to each of these series:
Part 1 Functional Overview
Part 2 - Key Reporting / Analyses
Part 3 - Target design and considerations
Part 4 Source Schema, Key queries, ETL maps, business rules
And more as needed for the topic under discussion.
Part 1: A short Overview of Oracle General Ledger:
The General Ledger (GL) is at the heart of the Accounting system of Oracle eBS. The main purpose of GL
is to record financial activity of the company and to produce financial and management reports. The GL
consolidates financial information from all other transactional modules or subledgers and maintains
summary level information. For example, it stores the accounting information for a Receivables invoice or
an invoice payable to a vendor. It stores accounting entries for expense for depreciation of an asset or an
inventory transfer. It also has accounting entries made within itself using journal entries.
If you want to know more on Oracle General Ledger, or any other Financial module, refer to the latest
User Guide (pdf file) or the Oracle E-Business Suite Financials Handbook, a handy reference that I highly
recommend to anyone who wants a thorough understanding of the functional concepts of the financial
modules within Oracle eBusiness Suite.
The following diagram is a high level overview of how some of the core modules interact with each other
within Oracle Financials:
http://intelligentbusiness.files.wordpress.com/2008/06/gl_int1.gif

Source: 11i Financial Functional Foundation

Let us dig a little deeper to understand some of the key concepts in General Ledger that we will need to
know before we attempt to design the EDW.
Set of Books and The three Cs:
The set of books in Oracle GL is a relationship where chart of accounts, fiscal calendar and currency of
the organization are defined. More than one set of books are usually defined for an enterprise, each set of
books identifying one business unit. For example, you may have operations in USA, Canada, UK and
other countries. You would want to set up a different set of books for each country (with its own currency)
and a set of books to consolidate financial information from all the other set of books. Set of Books will be
one of the conformed dimensions in your EDW. Each of the three Cs are shared with the subledgers:

The subledgers use the GL Chart of Accounts to record accounting entries for transactions which
are then transferred to GL.

The subledgers open and close their own accounting period but the periods are defined in the
fiscal calendar in GL (Fixed Assets is an exception to this rule, as it creates its own calendar.
However, as part of Oracle eBS setup, FA period names always match the GL period names).

Currency: Financial information can be entered in different currencies (more on this a bit later)
As we develop the BI analytic requirements, it will be evident that these three Cs are also going to
be conformed dimensions within the EDW.

A quick note on security:Oracle GL, and for that matter, all Oracle modules are secured by
Responsibilities. For GL, each set of books is linked to a responsibility. Responsibilities can be more
restrictive to limit access to specific functions within GL. For EDW, however, security needs are different.
These needs have to be understood at the data level, not at the process level, as is the case in Oracle
eBS.
More on currencies:In Oracle GL (and all modules) a functional currency is established for each set of
books. Transactions can happen in the functional currency or any other foreign currency. For
transactions done in foreign currencies, there will be a need for Conversion (foreign currency that is
immediately converted to functional currency at the point of transaction), Revaluation (adjustment to
liability or asset accounts that may be differently stated at the end of the period due to the fluctuation of
the exchange rate between the transactional and functional currencies) and Translation (restating the GL
balances for an entire set of books from the functional currency to a foreign currency). We need to
understand these as these will have an impact on our ETL design, which I will discuss in a later post in
this series.
In my next post I will lay out some of the key reporting requirements that will be the basis for our financial
data warehouse design.

Financial Data Mart Part 2

In Business Intelligence on April 5, 2007 at 3:52 pm
The Finance department is almost always the heaviest user of the data warehouse. They get
consolidated numbers from all business operations and this is where concern for profit, cash flow and
balance sheet is the greatest. The Finance department analyzes all costs, all revenues
and provides information to management that drive initiatives or corrective action across the business.
People in Finance understand how the board and banks see the numbers and how the shareholders and
the investment community value them. The company I am currently doing a project was recently sold to
an investment firm on the strength of these numbers.
Lets look at the four areas of financial analyses and reporting that is usually done from the GL:
Financial Statements:

Income (Profit and Loss) Statement analysis

Balance Sheet Analysis

Cash Flow Analysis

Key financial ratios:

Ratios like current ratio (current assets to short-term debt), quick ratio (current assets excluding inventory,
to short-term debt), Total Asset Turnover (Net sales to total assets) etc. are analyzed by comparing these
values over prior periods or comparing them to budgeted values. In General Ledger, most metrics (e.g.
revenues, costs) are usually analyzed as actual vs. budget to measure deviations from preset goals.

Actual vs. budget reports also help point out areas that need the greatest immediate attention from the
management.
Revenue and profit analyses are also usually done on just billings, usually summarized from sub ledgers
(e.g. receivables invoices) directly. This is important when an organization wants to understand total billed
revenue as opposed to just the revenue that can be recognized. A case in point may be subscription
revenues or software maintenance revenues that are billed in advance for the entire year, but can only be
recognized in part every month.
Statistical Analyses:
The GL often contains summarized information at the cost center level for various statistical units e.g.
asset counts or, count of employees.
Operational Detail:
Lastly, no one in Finance will just look at high level statements and analyses in the financial data mart, if
these numbers cannot be supported by the details or a record of the atomic level transactions. Hence, in
addition to keeping summary account balances, atomic or line level detail of all journal entries is needed
in the data mart. In cases where such infrastructure cannot be built in the data mart, a direct link should
be provided in the report to get to the underlying transactions.
In this context, I want to point out the capabilities offered by the different pre-built data warehouses sold
by different vendors. Oracles Daily Business Intelligence allows the user to drill down to see the lowest
level of detail, but does not drill into the transaction itself. Cognos Performance Apps provides access to
the line level details inside the data mart as well. Oracle BI Apps (previously Siebel Analytic Apps)
provides Action Link buttons inside reports that allows the user to drill into the transaction itself while
maintaining the context or parameter values in the report.
There is one other interesting point to note about analysis done in the Finance Department. Financial
analysis revolves greatly around the chart of accounts, period vs. period comparisons and the
organizations / divisions / cost centers. Product and Customer dimensions that drive cost and margin are
not in the picture. Product revenues and margin are accounted for, to an extent in the chart of accounts,
but other key dimensions like customers and sales persons are not present, thus limiting their view of the
business. In an enterprise-scale data warehouse, however, cross functional analysis is possible. If
Finance suspects the cause of certain variations from actual to budget numbers, they can drill into the
other areas to pinpoint the cause of such deviations.
In the next part, I will put up some of the most common data warehouse reports that are created from a
Financial Data Mart, based upon my experience in different projects. I will try to glean the basic data
requirements from these and identify the dimensions, their hierarchies, fact tables and metrics that we
want to put in the EDW. We will be ready to create the basic design for the financial data mart.\

The Financial Data Mart Part 3

In Business Intelligence on April 16, 2007 at 1:10 am
Prove the numbers. No one in the enterprise is as concerned as Finance to prove the numbers correct.
Disparities and inaccuracies in financial numbers not only present a distorted picture of organizational
performance, they also carry the threat of huge regulatory consequences. That is why, even before
Finance starts using the data warehouse for analysis, they validate and reconcile the details with the
different sub-ledgers to prove that the summaries indeed tie to the details. This task is not trivial and if
business rules are not vetted and understood well enough, discrepancies will creep up that will take an
inordinate amount of time to resolve. These issues crop up when there are external systems that feed
financial information to the General Ledger as summarized journal entries, while retaining the details in
those systems. The subledgers in the data warehouse then have to assimilate these details from all the
external systems in addition to those in Oracle GL. Such issues are unique for each organization. I will
attempt to broadly outline these issues in a later post. For now, let us look at some of the most common
reports that are generated from the Financial data mart.

Financial Statement Analysis:

Trial Balance reports are used to review balances for GL accounts for budgets, actuals and
encumbrances for any currency. They are typically run for a date range, a range of accounts

Balance Sheet detail reports showing balance sheet accounts (assets, liability and equity
accounts). Period to period comparisons, month-to-date, quarter-to-date, year-to-date, budget-toactual comparisons are typical of these reports.

Cash Flow statements for companies (usually, the first segment of the GL chart of accounts),
fiscal periods.

GL Balances report this is a detail of all balances in different currencies, for different periods, for
different cost centers

GL detail, or Journal Entry detail reports to trace the GL balance to all the supporting
transactions.

P & Ls (Profit & Loss Statements) show the revenue, costs, expenses, etc. for different cost
centers, fiscal periods. Usually, these are more complicated as further details of the underlying
subledgers are usually sought. Revenue analyses by additional dimensions like sales persons
are done, some times at the detail of individual billing transactions (or invoices).

Key Financial Ratios: Detail reports are not usually run for Financial ratios and metrics like Current
Ratio, Quick Ratio, Debt to Asset, Fixed Asset Turnover, Inventory Turnover (GL), Gross Profit Margin,
Net Income, Retained Earnings, Return on Equity, Return on Assets, Asset Turnover, etc. The metrics are
calculated for the company and trends over time and comparisons with budgeted numbers are usually of
most interest.
Statistical Reports:

Headcounts by cost center per company, budget-actual comparisons, and trends over time

Asset count (e.g. how many laptops do we own?) by cost center, by company, budget-actual
comparisons, trended for different time periods or period-period comparisons.

The source of almost all of these metrics is the General Ledger. The source of all detail level GL
transactions are Journal Entries. For further analysis, one needs to drill down to the individual Subledger
(revenue, cost, expense subledgers). Budget details are also sourced from the GL. Thus, in the Financial
data mart, these will be our fact tables:

General Ledger Balances

Journal Entry Details

Budget details

Looking at the different analyses above, the key dimensions are apparent:

Time (Day, Month, Quarter, Year)

Fiscal Month (for all aggregate analysis)

Chart of Accounts

Set of Books

If you decide to build the subledgers as part of the subject area data marts (e.g. Payables Subledger as
part of the payables data mart), then these are dimensions above will need to be used and are the
designated conformed dimensions.
A note about Hierarchies:
In Oracle General Ledger, you can define parent-child relationships over the individual segments of the
accounting Flexfield. There are no restrictions to the number of levels that you can define. This is an
example of the hierarchies for the Company segment of the Accounting Flexfield (actual company name
overwritten):

Company 001 can also be defined as the parent of 002 thru 006. All segments can have hierarchies to as
many levels as is desired by the business. Hierarchies can also be defined by rollup groups that go
across all segments. This is suitable if reporting requirements are known in advance, something that does
not happen too often, but is certainly not rare.
Whichever way hierarchies may have been defined, if the business need is to report facts in the form of
aggregates and summarize for each of these segments, it is better to have a separate conformed
dimension for every segment of the chart of accounts that is important for reporting. In my experience,
company, account and cost center are the most common segments that have a need to report at a
summary level and hence demand to be treated as distinct dimensions.
Slowly Changing Dimensions: Type 1, 2, or 3?
If you are not familiar with slowly changing dimensions and the different types of SCDs, start with Ralph
Kimballs primer on SCDs.
Accounting Flexfields and hierarchies do not change frequently. Natural account segments change little
over time. Cost Center or division hierarchies, however, typically change once every year. This is most
common for Sales organizations where regions are redefined and typically change every year. In such
cases, the requirement is often to compare fact aggregates (e.g. sales revenue) of the current years
hierarchy with the previous (or any of the past 5 years) hierarchy. Requirements of this nature are
common and are typical examples of where Type 3 SCDs the least common of the SCD techniques, are
used. This concept is very lucidly explained in this article Many Alternate Realities, again by Kimball.
In the most common scenario, the Chart of Accounts dimension is a non SCD dimension (or Type 1
SCD), i.e. changes are not versioned and the dimension values are overwritten. Company, and Account
are also usually in the same category. Cost Center, however, is a conformed dimension having Type 3
SCD technique applied to handle change. Chart of Accounts also are linked to Set of Books (see Part 1 of
this series). Set of Books is also a conformed dimension that is used in most financial analysis.
Design of the data mart:

Here is a preliminary design of the Financial Data Mart for GL Balances.

To get details of the transactions that make up the balances in General Ledger, we need to drill into the
Journal Entries. Here is how that will look:

Budgets will have a similar set of dimensions (not Journal Entry Document or Categories). In Oracle GL,
you can create multiple budgets for the same chart of account combination. Hence you will need an extra
dimension Budget (or Budget Version, to be more accurate) to qualify budget amounts for a particular
combination of accounting Flexfield segments.
Notice the Journal Entry Document dimension above. This contains various attributes of journal lines like
batch name, journal name, description, etc. This dimension plays a key role in reconstructing
transactions in the data warehouse at the atomic level. It may also be used as a placeholder for several
non-additive facts as well. I will explain this very neat concept of Document dimensions in a later post. We
have used Document dimensions extensively in my current project.

I have left out several key issues here, most notably that of security and currency conversions. These are
subjects that have some unique features and will require much discussion. For now though, I will get on
with this basic framework that I have outlined here. In part four of this series, I will explain the data
structures in the General Ledger module of Oracle eBusiness suite and will explain how that data can be
extracted to this data mart.
If you have found these discussions helpful, please feel free to comment or suggest improvements.

The Financial Data Mart - Part 4

7 June 2009 5 Comments
In this short technical article, I will outline the data structures of the General Ledger module in Oracle
eBusiness Suite that are relevant in building the Financial data mart. If you are currently engaged in
building a data warehouse with Oracle eBusiness suite as the primary source of data, you may find this
useful, particularly, if you are performing ETL tasks.
Refer to part 3 of this series for the broad design. Here are the sources in Oracle eBusiness suite for the
different dimension and fact tables:
Dimensions:
Dimension
Set of Books
Chart of Accounts
Account
Company
Cost Center
Fiscal Month
Journal Categories
Journal Sources
Budgets

Oracle eBS Table

GL_SETS_OF_BOOKS
GL_CODE_COMBINATIONS
GL_CODE_COMBINATIONS,
FND_FLEX_VALUES_B,
FND_FLEX_VALUES_TL
GL_PERIOD_SETS, GL_PERIODS
GL_JE_CATEGORIES_TL
GL_JE_SOURCES_TL
GL_BUDGETS,
GL_BUDGET_VERSIONS

Facts and Document Dimensions:

Dimension
Fact GL Balances
Fact Journal Entries andJournal Entry
Document
Fact Budgets (may be combined with
Fact GL Balances)
Budget Document
Source Data Structures:

Oracle eBS Table

GL_BALANCES
GL_JE_BATCHES,
GL_JE_HEADERS, GL_JE_LINES
GL_BALANCES
GL_BUDGET ASSIGNMENTS

The following diagram outlines the source table relationships for the facts above:

The Budget tables relationships are given below:

More detailed diagrams can be downloaded from Oracle Metalink.

The descriptions for the chart of account segments are stored in Flexfields within Oracle. The following
query, for example, can be used to get the descriptions:
select gcc.segment1 company
, gcc.segment2 account
, gcc.segment3 cost_center
...
, fvc.description company_desc
, fva.description account_desc
, fvcc.description cost_center_desc
...
from gl_code_combinations gcc
,fnd_flex_values_vl fvc
,fnd_flex_values_vl fva
,fnd_flex_values_vl fvcc
where fvc.flex_value_set_id = (select flex_value_set_id from fnd_flex_value_sets where
flex_value_set_name like '<YOUR_COMPANY_GL_AFF_COMPANY')
and fvc.flex_value_meaning = gcc.segment1
and fva.flex_value_set_id = (select flex_value_set_id from fnd_flex_value_sets where
flex_value_set_name like ' YOUR_COMPANY_GL_AFF_ACCOUNT')
and fva.flex_value_meaning = gcc.segment2

and fvcc.flex_value_set_id = (select flex_value_set_id from fnd_flex_value_sets where

flex_value_set_name like ' YOUR_COMPANY _GL_AFF_COST_CENTER')
and fvcc.flex_value_meaning = gcc.segment3
order by 1,2,3,...
ETL Tip:
Loading Fact GL Balances may be tricky if you are not aware that the source table stores balances for all
types of amounts - budgets, actual amounts, encumbrances and statistical amounts. Also, it stores the
translated amounts if the translation activity has been performed at the close of the fiscal month. As a
result of this activity, you may have adjustments posted to certain accounts where you will have actual
adjustment amounts posted in the translated currency even though the corresponding local currency
amounts are zero. If you are translating amounts in the Fact GL Balances table on the fly using the
reporting tool, be aware of this issue. Although translations can easily be done dynamically, I have found it
unwise to do so because of these issues and the complex business rules that often are applied to
translations. It is safer to store actual translated values in the fact table itself.
This is the end of this series. I will write about building Sales Data Marts in the next series. Hope you
enjoyed these - I am happy to answer any questions you may have or elaborate on anything I have stated
in these posts.
Also read Part 1, Part 2 and Part 3 of this series.