Advertisements

Oracle Peoplesoft Accounts Payable Data model and dataflow

This is a simplified Peoplesoft Accounts Payable data flow and data model. The purpose is to provide a basic understanding of the key tables and how data flows through the module.  Understanding the key tables and the data flow is helpful when creating metrics and reports in tools such as OBIEE or when working with OBIA Financial Analytics, and particularly, with the Accounts Payable dashboard, reports and metrics.

When a voucher is created, the information is recorded in the VOUCHER, VOUCHER_LINE and DISTRIB_LINE tables. 

When payments are created for the vouchers, the information is recorded in the PAYMENT_TBL and PYMNT_VCHR_XREF tables.  The PYMNT_VCHR_XREF table provides a bridge between voucher and payment tables.

When a voucher is posted and when a payment is posted, accounting entries are generated and recorded in VCHR_ACCTG_LINE.

Payments are of course made to vendors.  Vendor primary information is stored in the VENDOR table, but there are many more vendor related tables.

PeoplesoftAccountsPayableDataModelAndFlow

Accounts Payable key table descriptions

VOUCHER AP Voucher Header Table. This Table provides the Invoice Header Information and the Accounting Information as displayed on the Voucher. Budget Checking Exceptions can also be identified on this table.
VOUCHER_LINE AP Voucher Line Table. This Table provides the individual line information for each invoice including description, quantity, unit of measure, unit amount, and extended amount. You can have multiple VOUCHER_LINE to each VOUCHER.
DISTRIB_LINE AP Voucher Distribution Table. This Table provides the Invoice accounting line distribution detail. Budget Checking Exceptions can also be identified on this table. You can have multiple DISTRIB_LINE to each VOUCHER_LINE.
VCHR_ACCTG_LINE AP Accounting Entries. This Table contains all transactions that are journal generated.
PYMNT_VCHR_XREF Voucher Scheduled Payment Table. This Table is often used as a link between the Voucher and the Payment Tables.
PAYMENT_TBL AP Disbursements Table. The Primary Table that the Payments are recorded against at time of the PayCycle Manager.
PYMNT_XREF_VW AP Payment Voucher Information. The View is designed to link the Voucher ID with the Payment Reference.
   
VENDOR Vendor Header Table. This Table represents the high-level Header information related to a specific vendor.
VENDOR_ADDR Vendor Address Table
VNDR_ADDR_PHN Vendor Address Phone Table
VENDOR_LOC Vendor Location Table
VENDOR_CNTCT Vendor Contact Detail Table
VENDOR_PAY Vendor Payment Defaults
VENDOR_WTHD Vendor Withholding Table
VENDOR_WTHD_JUR Vendor Withholding Jurisdiction Table
Advertisements

Oracle EBS General Ledger data flow and data model

In just about any ERP financial accounting system, including Oracle EBS General Ledger, the General Ledger module is integrated with other modules, such as Accounts Payable and Accounts Receivable.  The General Ledger will collect and store financial activity information from the other modules, and will be the module that best reflects the overall financial condition of the company. Because of this, the General Ledger is typically heavily used for financial reporting from OBIEE, OBIA, or other tools.

This post aims to provide a quick overview of the data model of Oracle EBS General Ledger and the data flow within the module.

Oracle General Ledger is a part of the Oracle E-Business Suite Financials Application.  Many of the other Oracle Applications modules are integrated with Oracle General Ledger, and send transactions to the General Ledger in the form of journals.

For example, when a company receives an invoice, the transaction is entered into Oracle Payables; and then when the invoice is paid, another transaction is generated in Oracle Payables. There could be tens, hundreds or even thousands of these transactions per day.  This activity is recorded in the Oracle General Ledger in the form of journals.

Similarly, when a company makes a sale, and then when payment is received for that sale, those transactions are recorded in the Oracle Receivables module, and the transactions are also passed on to the Oracle General Ledger with the Transfer program.

Below is a diagram of Oracle General Ledger’s data flow and some of the key tables in the data model.

OracleGL_DataFlow

Oracle EBS Modules and External Systems populate the GL_INTERFACE table through the Transfer program and Load programs respectively.  The Journal Import Process takes those records and loads them into the GL_JE_BATCHES, GL_JE_HEADER and GL_JE_LINES tables. The Posting Process calculates and loads balances from those records into the GL_BALANCES table.

The tables covered here are some of the sources for the OBIA star schemas (fact and dimension tables) used in OBIA Financials, and in particular, the General Ledger dashboard and analyses.

GL_INTERFACE This table holds financial transactions   (journals) transferred from other Oracle Applications modules and external   systems.
GL_JE_BATCHES This table identifies a “batch” of   journals that are related and processed together. Each batch contains one or   more journals.
GL_JE_HEADER Each journal has one journal header   and one record this table
GL_JE_LINES Each journal has one or more journal   lines and are tied together by the journal header

Some other important supporting tables in the GL data model include:

GL_CODE_COMBINATIONS This is the Accounting Flexfield table   and it stores the chart of accounts values, and so the table contains the   valid GL account combinations allowed in the system, along with other   relevant information about the accounts.
GL_LEDGERS This table stores all the Ledgers and   Ledger Sets in the Oracle GL system
GL_PERIODS This   table stores information   about the accounting periods defined in the Oracle GL system. Each row contains   information such as, start date, end date of the period, the period type, the   fiscal year, and the period number.
FND_CURRIENCIES This table stores the list of valid   currencies to be used in Oracle Applications

OBIEE Tuning Whitepaper from Oracle (has been updated)

Oracle has released an updated version of their OBIEE Tuning Whitepaper.

You can find the document here …

https://blogs.oracle.com/pa/entry/test

… or here …

https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=212370301476321&id=1333049.1&_afrWindowMode=0&_adf.ctrl-state=w65avp7pa_30

You will need to have an Oracle ID to access it (which is a free sign up).

In addition to all the great information that was in the original document, the updates to the document include:

  • New improved HTTP Server Caching algorithm
  • Oracle iPlanet Web Server tuning parameters
  • New tuning parameters settings / values for OPIS/OBIS components

The topics included in the document are:

1.0 Performance Overview

1.1 Introduction to Oracle Business Intelligence EE Performance
1.2 Performance Terminology
1.3 Understanding Key Performance Drivers

2.0 Top Tuning Recommendations for OBIEE

2.1 Tune Operating Systems parameters.
2.2 Tune Oracle WebLogic Server (WLS) Parameters
2.3 Tune 64bit Java Virtual Machines (JVM)
2.4 Tune 32bit Java Virtual Machines (JVM)
2.5 Tune HTTP Server Parameters
2.6 Tune HTTP Server Compression / Caching
2.7 Tune Oracle Database Parameters

3.0 Performance Monitoring OBIEE

3.1  Built-in BI Metrics for Performance Monitoring
3.2  Performance Monitoring In Windows Environment
3.3. Performance Monitoring In Unix Environment

4.0 Tuning OBIEE Components

4.1 Oracle BI Presentation Services Component
4.2 Oracle BI Server Component

5.0 Tuning Essbase

5.1 Essbase ASO Tuning

Report-Based Total Pivot table calculation option in OBIEE

If you have a scenario where your pivot totals are not matching your pivot numbers (in other words, the total is not correct) in an OBIEE pivot table, this post may help.

There might be times when your pivot table shows a set of numbers that do not add up to the Grand Total calculated by OBIEE. This could be due to the grain of the data returned from your SQL, possibly from performing different calculations on multiple columns.

If already checked (default), then uncheck or deselect the “Report-Based Total” option as shown below to see if this solves your problem. (And if unchecked, then check it to see if that helps you).
From within your pivot view, select the button on your measure value, then select “Aggregation Rule”, then uncheck “Report-Based Total”.

Report-Based-Total

According to the OBIEE documentation … “If the option Report-Based Total is not selected, the Oracle BI Server will calculate the total based on the entire result set, before applying any filters to the measures.”

Basically the difference is … instead of the BI Server generating SQL that will calculate the total based on the grain of your rows (how the data rows look in the table view), it will calculate the total based on the how the data is partitioned over the rows and columns (the pivot table values). 

This is an often overlooked option that can, but rarely, affect your results. Based on your scenario, you may need the selection checked or unchecked.  Try it and see if helps your situation.

OBIEE data source types and data retrieval methods

OBIEE is capable of connecting to and retrieving data from a variety of data sources.  The type of data sources that OBIEE can connect to are OLTP, OLAP, Data Warehouses (ROLAP), and Files.

  • OLTP databases – these include the normalized-design databases including ERP, CRM and other LOB systems.
    – The relational databases supported are: Oracle databases, Microsoft SQL Server, IBM DB2, and Teradata Warehouse.
    – And the ERP/CRM sources supported are: Oracle E-Business Suite, Oracle Peoplesoft, Oracle Siebel CRM, Oracle JD Edwards, and SAP.  Note: any ERP/CRM system running on one the databases mentioned above can be supported, but those mentioned here are special ERP/CRM sources.
  • OLAP databases – these include dimensional-databases including applications based on dimensional databses.
    – The OLAP datases supported are: Oracle Essbase, Oracle OLAP, Microsoft Analysis Services, and SAP Netweaver BI.
    – And the OLAP applications sources supported are: Oracle Hyperion Planning and Oracle Hyperion Financial Management.
  • Dimensionally-modeled data warehouses – these are relational databases designed with a star-schema / dimensional model, on one of the 4 supported relational databases mentioned above.
  • Files – Microsoft Excel, XML files, Flat files.

The data retrieval methods used to connect to these sources are:

  • OLTP – SQL
  • OLAP – MDX
  • Data Warehouse – SQL
  • Files – ODBC

OBIEE has the ability to connect to multiple of these data sources at the same time, and the data sources can be of the same or different types.  So, for example, an OBIEE Server can source data from an Oracle 11g Data Warehouse, and from an Oracle Essbase 11g OLAP cube at the same time, and join the data together for user consumption.
Similarly, file datasources can also be added to provide additional information, for example from an external source, and joined to data from the other sources mentioned above.  This “joining” of data is handled by the OBIEE BI Repository and BI Server.

To the end user accessing the data from a front-end tool (Analysis Editor / Answers), it seems like a single data source. That is one of the features that makes OBIEE such a great tool particularly for heterogeneous database environments.

Developing requirements for an OBIEE project

Eliciting and creating requirements for an OBIEE project is a very important step in creating a successful, pervasive OBIEE system in an organization.

Throughout the requirements elicitation and creation process, you need to keep in mind that all requirements must be testable.  The only way to verify if a requirement has been met is to successfully test it, and therefore, all requirements must be specific and detailed enough to allow for a QA person to verify it.

A huge and essential component of OBIEE projects is the reports being delivered in one form or another – and therefore, another set of characteristics to keep in mind are that the reports and their form of delivery need to be: accurate, relevant, timely, and actionable.

Typically an OBIEE project involves significant effort, and can take several months to complete, but visible progress can be made in a shorter time.  Requirements may need to be prioritized to handle the most critical ones first (a phase 1 for example), and postpone some for later in the project – a phase 2 for example.  However, it should not take months to see some results, because OBIEE is a great platform for an agile methodology – allowing the project to show some results early and ongoing, as the project becomes more and more completed.

To elicit requirements, there are a number of methods that can be used.  You will need to choose the most appropriate method based on the particular scenario – who is the user, what area does the requirements cover, etc.  Some of the methods used can include: interviews, observation, reviewing existing reports (from a previous system for example); soliciting information from colleagues in other companies; and developing/showing report concepts and getting feedback; brainstorming – from strategic goals and reporting needs to tactical/operational.  However, you should try to learn as much as possible about the business, processes and people beforehand; and always try to be a good listener.

Requirements for an OBIEE project can be grouped into the following groups of questions:

What information does the business users need to see? 

This is often driven by the company’s strategic goals. The data needs to be in aid of answering business questions that users will need to aid their decision making in order to realize operational and tactical goals that support the strategic goals.

The information could be enterprise wide, departmental, or specific subject matter.

The reporting requirements could also be classified as strategic, tactical, or operational.  The strategic requirements are usually enterprise wide, while the tactical and operational requirements are usually relevant to a departmental, group or individual role.  Strategic requirements can at times be monitored and tracked via Key Performance Indicators (KPIs) which can be developed and presented in OBIEE.  Operational requirements at times will need Agents or iBots that trigger some action based on an event.  And tactical requirements are usually satisfied using reports that display valuable metrics about the business operations.

What are your business objectives and what metrics will help you to monitor progress toward those objectives?  What information do you wish you had to do your job better?

Where will the data be sourced from?  In other words, what are the source systems?

The answer to this question could include Data warehouses or data marts, ERP systems, Line of Business systems (LOBs), Flat files, External sources, OLTP, OLAP, etc.

The data sources need to be defined in the OBIEE BI Repository (RPD) via Connection Pools, and the metadata for the relevant tables imported.  OBIEE data sources can be relational (OLTP), multi-dimensional (OLAP) or files (Excel, XML, ADF).  The OLAP data sources supported by OBIEE are Oracle Essbase, Oracle OLAP, Microsoft SQL Server Analysis Services, and SAP BW.

However, for better performance, it is best if the data sources are multi-dimensional – either star-schema relational or OLAP.

What data is required from those systems?  And what data needs to be calculated or derived?

Analysis needs to be done to determine what subset of data (if not all) is needed from each of the source systems. What measures, dimensions, hierarchies, and attributes are required? What lookup tables are required?

And it’s always a good idea to ask “Why?”  Why is this data needed?  How will it be used?

This involves reports, and it is important to keep in mind that all report/reporting data need to be accurate, relevant, timely, and actionable.

What data that is not in the source system but can be derived? Calculations, Associations, mappings, etc – these derived items can be created in the OBIEE repository BMM layer, and exposed to users as necessary.

What granularity of data is needed?  Summary, Detail, both

What time range (including the time granularity) of data is needed?  Historical, Current, Real-time, Day, Month, Quarter, Year

What KPI’s are required to track the state of the business?

What data needs to be filtered out/in from each data source tables in the various scenarios?

What are some of the frequently used filter criteria?  à this could drive some of the repository variables created in OBIEE

What are some frequently used values for analysis?  à this could drive dashboard prompts in OBIEE

Will the business users need to perform data mining or need the results of data mining?

How frequently does the data need to be updated?

If the data is not directly connected to the source, then how often should the data be updated – real-time, hourly, daily, weekly, monthly, on-demand, etc?

Who needs to see what data?  And who needs access to what functionality?

This is in essence a security question.  What are the various groups/roles that need access to data, and what data should each group/role have access to?

Can the reporting system be integrated with the company’s existing LDAP? This is typically the case for most modern reporting systems including OBIEE which integrates with popular LDAP systems including Active Directory.

Does row-level security need to be implemented?  OBIEE allows for row-level security.

Can all users use all features of the reporting platform?  Or will only specific users be granted access to specific functionality?

What dashboards and reports will each group of users be able to see?

How will the information be shared with business users?  What modes of information delivery need to be used?

Will reports be shared?  email, saved to a directory, web dashboard, file (pdf, word, excel, html)?

Do users need to be proactively notified of events? – for example, a user or group needs to be notified if stock levels fall below a threshold.

The answers to this question will drive the Agents/iBots that need to be created.

Will the reports be run on a predefined schedule or based on some predefined condition?  Or will they be run on-demand?  This will also drive Agents/iBots and Conditions.

Do users need to download information?  This will drive the ‘report links’ that are placed on the dashboard pages.

Do report results need to be preserved or can/should they be overwritten?

Will users be allowed to create their own analyses or perform adhoc analysis? And if yes, how will that activity be monitored and supported?

What visualization features are required for each report or set of data?  Dashboards, Scorecards, Charts, graphs, tables, pivots, gauges, icons, colors, fonts, etc.

Will the users need to be able to drill from summary to detail reports?  Rollup from detail to summary?

Will the users be able to interact with the data?  Prompts, View Selectors, Column Selectors, etc

What are some of the system level requirements?

What level of system performance is required?

Dashboard and report creation tools

Does the reporting system need to be able to access/connect to multiple data sources at a time?  OBIEE allows for multiple data sources connected at the same time.
Does the reporting system need to be able to access/connect to relational, multi-dimensional, and file data sources?

Does the reporting system need data mining capabilities?

Does the system need to support drill-down, rollup functionality?

What are the critical usage times for the system?  In other words, what are times when the system must be available? For example, during the month-end close process or during the holiday sales season.  This will drive when changes can be made to the system.

What are the highest usage times for the system?  What hardware do we need to support that usage?

How will changes be handled? In other words, what is the change control process?

It is very important that all the relevant players are included in the requirements process – business leaders and business users, SMEs, technical staff, database administrators, OBIEE Developers (report developers, rpd developers), OBIEE architect, ETL developers, ETL architect.  Before development officially starts, it is important to get all relevant sign-offs on the requirements.  This will ensure that everyone is on the same page, and that the business users are getting what they need.

This post will be a “living” document, as I will be coming back and updating this post from time to time to add more detail and more OBIEE specifics.

Renaming the Views in an Analysis for use in a View Selector in OBIEE 10g & OBIEE 11g

In OBIEE 10g, we renamed the Views directly inside the View Selector definition like here…

Rename-View-10g

In OBIEE 11g, we rename the View inside the View definition itself … like here …

Rename-View-11g-1

then rename …

Rename-View-11g-2

And then you will use/select the new name in the View Selector (instead of renaming it in the View Selector). 

This is much better because you know exactly what view is being used in the View Selector.  Whereas in 10g, at times it took more effort to determine what original view the renamed views related to.