John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

Introduction
Hello again, folks. We all know the joy of car shopping; there’s no better way to be stripped quickly of your money and dignity.
The tail-end of this process is usually a hoot, when the dealer runs down a litany of useless stuff that no one needs:
undercoating, scotch guard, window etching, and so forth. It’s important for us to know what we don’t need so we don’t get taken
for the proverbial ride. Even more important, however, is to know what options we must absolutely have; six-cylinder engine,
airbags, all-wheel drive, and so forth. Such knowledge allows us to quickly eliminate the pretenders from the contenders,
thereby leaving an “apples-to-apples” comparison.

Well, determining must-have options for a car is pretty intuitive; you need airbags and all-wheel drive so you don’t die – pretty
straightforward. The process is not as intuitive when evaluating a Reporting and Analysis solution. The must-have features and
functionality for Multidimensional and Relational Analysis software don’t necessarily scream their added value unless the buyer
understands, from both source data and reporting deliverable standpoints, why he or she is in the market for either or both types
of tools.

The goal of this whitepaper is to assist the non-technical JD Edwards (JDE) end-user in more effectively executing the Search
and Selection process for a Reporting and Analysis solution. I suggest that it would be helpful for you to first read my previous
whitepaper, “Helping Non-Technical JDE End-Users Choose the Proper Reporting Tool,” to better understand the types of
tools available.

Download all Cetova whitepapers at http://www.cetova.com/download-whitepaper.php.

What Do I Need in a Reporting and Analysis Tool?

As a consultant, I’ve participated in several ERP Search and Selection projects. Have a look at Figure 1 - Software Evaluation
Matrix. The following criteria, typically used in evaluating enterprise systems, could likely also be used in assigning points to
Reporting and Analysis solutions.

FIGURE 1 – SOFTWARE EVALUATION MATRIX

CRITERION SUMMARY DEFINITION
Functionality Vendors may be ranked on their ability to meet the features and functionality requirements, usually set
forth in a separate matrix.
Cost Vendors may be ranked on Total Cost of Ownership, which includes not only routine operational
costs, but also up-front implementation time and costs for hardware, software, and services.
Business Vision Vendors may be ranked on their ability to provide a solution that enables and is consistent with the
customer’s Business Vision.
System Vision Vendors may be ranked on their ability to provide a solution that enables and is consistent with the
customer’s System Vision. Ease of seamless integration across mission critical Best-of-Breed (BOB)
solutions, is usually of paramount importance.
Flexibility and Vendor software may be ranked on its ability to easily accommodate modifications, client deployment,
Scalability role-based security, and scalability requirements.
Toolset Vendor software may be ranked on whether program objects can be developed and modified using a
toolset; whether the toolset utilizes open versus proprietary languages; toolset ease-of-use; availability of
change management and version controls; and breadth of available objects and APIs.
Vendor Vendors may be ranked on their overall reputation, stability, longevity, strategic direction, software
alliances, and install base. Facilitating information will be gleaned from vendor-provided information, and,
from client references.
Product Support Vendors may be ranked on all aspects of product support, including but not limited to training, help desk,
documentation, availability and frequency of upgrades, versions to be released, an anticipated sunset
dates.

866-CETOVA-4 Page 1
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

CRITERION SUMMARY DEFINITION

Resource Vendor software may be ranked on the availability of marketplace resources such as user groups and
Community ERP and CRM professionals.
Operational Support Vendor software may be ranked on requirements for DBA, network, hardware, and other support staff.

The granddaddy of all evaluation criteria is right up top - Functionality, which may be weighted by as much as twenty to thirty-
percent, or more, in the final analysis.

So, would you know what to look for within your features and functionality requirements? What are those must-have features
and functionality for Multidimensional and Relational Analysis software? That’s where I hope this whitepaper can provide some
guidance. Now, as always, I’ll confess that I don’t know everything; charm goes farther than actual knowledge. What I do know,
as a power-user, end-user, and consultant, is that certain features and functionality tend to present themselves repeatedly as
must-have. Unfortunately, since the customer “doesn’t know what he doesn’t know,” such must-have requirements are not
confirmed up-front during the Search and Selection process.

Now then, please read on for a [hopefully] clear explanation of the must-have Reporting and Analysis functionality sought in both
Multidimensional and Relational Analysis tools. As always, drop me an email (jlambrianakos@cetova.com) if you have any
questions.

Multidimensional … Lots of Dimensions

This section will define for the non-technical JDE end-user some basic Multidimensional Analysis (MDA) concepts and
terminology, which, in my opinion, should be standard working knowledge for anyone looking into a JDE Reporting and Analysis
solution.

First, let’s get some vocabulary squared away. Those fields upon which you slice-and-dice (i.e. pivot) your data via MDA – we
call those fields Dimensions. For example, Cetova C-FAR provides out-of-the box MDA over the JDE General Ledger Account
Balance (F0902) table along the following dimensions: Business Unit, Account (Object and Subsidiary), Subledger and
Subledger Type, Ledger Type, Fiscal Year, and Company.

So, let’s say that you want to build a basic Profit and Loss Statement based upon your account balances in the F0902. Have a
look at Figure 2 – Simple P&L.

FIGURE 2 – SIMPLE P&L

Actual Budget Variance
Revenue
Cost of Goods Sold
Gross Margin
Operating Expenses
Income Taxes
Net Income

What is implied, vis-à-vis the report dimensions, by this example? Well, a few things...

First, the reported account balances will be aggregated by the Account dimension down the rows and by the Ledger Type
dimension across the columns … easy enough. Second, we’d have to assume that some sort of data selection or filtering is
being executed over the remaining dimensions, such as Business Unit, Fiscal Year, and Company. Furthermore, based upon
this example, it’s reasonable to assume that those remaining dimension values are being selected for the entire report.
866-CETOVA-4 Page 2
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

So, let’s say that we run this P&L over a Fiscal Year value of 2008. It is therefore obvious that the reported balances would be
from Fiscal Year 2008. Now, let’s say we run this P&L over Fiscal Years 2008 and 2009. In this case, the reported balances
would be the sums of those individual balances from Fiscal Years 2008 and 2009.

However, what if we wanted to perform a comparative analysis of Fiscal Year 2008 versus 2009? In other words, what if, rather
than summing up 2008 and 2009 balances, we wanted to analyze 2008 Ledger Type balances against 2009 Ledger Type
balances. Such side-by-side managerial analysis would require that each column represent a distinct combination of Fiscal Year
and Ledger Type values. The functionality required for rows and/or columns to represent distinct dimension value combinations
is known as Cross-Join functionality. Have a look at Figure 3 – P&L with Cross-Join and Single Fiscal Year.

Please note, while we use the term Cross-Join in this whitepaper, the same query concept may be termed differently by other
vendors and subject matter experts. For example, we’ve seen such query functionality referred to as Cross-Product. Keep in
mind that we’re referring to the same functionality, which is illustrated below. For our Clients reading this whitepaper, I’m
referring to dimension Stacking, one of our many colloquialisms at Cetova.

FIGURE 3 –P&L WITH CROSS-JOIN AND SINGLE FISCAL YEAR

2008
Actual Budget Variance
Revenue
Cost of Goods Sold
Gross Margin
Operating Expenses
Income Taxes
Net Income

This P&L reports its columns as a Cross-Join of two separate dimensions. Ideally, with a single drag-and-drop, the user easily
constructs the report columns by joining the Fiscal Year and the Ledger Type dimensions. Such functionality is the hallmark of
any MDA solution; it delivers the characteristic analytic value as set forth in my previous whitepaper, “Helping Non-Technical
JDE End-Users Choose the Proper Reporting Tool.” Remember also that a drag-and-drop interface, at least in this day and
age, should be considered must-have for both Multidimensional and Relational Analysis tools.

From an effort standpoint, a single drag-and-drop effectively modifies the data selection on a column-by-column-basis. So,
rather than rigidly specifying Fiscal Year(s) for the entire report, you now can flexibly specify Fiscal Year by column. For you
SQL big shots, a simple drag-and-drop creates three brand new WHERE Clauses within the three sub-queries underlying the
respective columns.

Furthermore, with a single additional drag-and-drop, you should be able to create three new cross-joined dimension columns,
which select 2009 for comparative analysis. See Figure 4 – P&L with Cross-Join and Multiple Fiscal Years.

866-CETOVA-4 Page 3
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

FIGURE 4 – P&L WITH CROSS-JOIN AND MULTIPLE FISCAL YEARS

2008 2009
Actual Budget Variance Actual Budget Variance
Revenue
Cost of Goods Sold
Gross Margin
Operating Expenses
Income Taxes
Net Income

So, the ability to easily define columns in terms of two or more dimensions (i.e. Cross-Joined Dimensions) is a necessary, but not
sufficient, bit of functionality offered by a robust MDA tool. Now let’s look at those features and functions that separate the best
MDA tools from the rest of the pack.

Multidimensional Analysis: Compound Dimensions

So, Cross-Join functionality is great – four drags gets you a three-column variance report, one more drag gets you three more
columns. What could be easier? Well, ease-of-use is one thing, but flexibility is a whole other story. This section will illustrate
Compound Dimension functionality, which may be used to sidestep the rigid column-sets that frequently result from Cross-Join-
based reporting.

Please note, while we use the term Compound Dimension in this whitepaper, the same query concept may be termed
differently by other vendors and subject matter experts. For example, we’ve seen such query functionality referred to as
Asynchronous Components, Dimensions, or Columns. Please keep in mind that we’re referring to the same functionality,
which is illustrated below. For our Clients reading this whitepaper, I’m referring to dimension Squishing, another one of our
many colloquialisms at Cetova.

So, let’s take an example to make this clear. Say your boss requests from you a simple P&L to see how this month’s numbers
compare to last month, this month last year, and the current budget … with a budget variance. Please take a look Figure 5 –
P&L with Multiple Cross-Joins.

FIGURE 5 – P&L WITH MULTIPLE CROSS-JOINS

2009 2008
AA BA Variance AA BA Variance
Current Prior Current Prior Current Prior Current Prior Current Prior Current Prior
Period Period Period Period Period Period Period Period Period Period Period Period
Revenue
Cost of Goods Sold
Gross Margin
Operating Expenses
Income Taxes
Net Income

Make no mistake; the sample report above is quite easy to develop using Cross-Joins. I drag my Accounts as rows, then, I
simply Cross-Join my Fiscal Year with Ledger Type and Period as columns, throw in a calculation, and I’m finished in about two
minutes. Pretty good!

866-CETOVA-4 Page 4
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

Well, hold on now. Reconcile the output in Figure 5 to your boss’ original reporting request. She basically wanted six columns;
you gave her thirteen. Furthermore, you’re reporting data like Prior Period Budgets, which no one cares about anyway.
Unfortunately, such a cumbersome report is sometimes unavoidable with Cross-Joins. Once you create a Cross-Join of the
Fiscal Year, Ledger Type and Period dimensions, that same column-set will persist throughout the report, thereby creating
unnecessary detail. Furthermore, if you try to resolve this situation by selectively deleting unwanted columns, such as Prior
Period for the BA Ledger, your Multidimensional Analysis (MDA) tool will likely delete every instance of Prior Period throughout
the entire report. This obviously is not an optimal outcome.

Well, imagine now that you can merge together the Fiscal Year, Ledger Type, and Period dimensions into a new Compound
Dimension on a column-by-column-basis. Please have a look at the lines of Figure 6 – P&L Using Compound Dimensions.

FIGURE 6 – P&L USING COMPOUND DIMENSIONS

2009 2009 2008 2009 2009
AA AA AA BA Variance
Current Period Prior Period Current Period Current Period Current Period
Revenue
Cost of Goods Sold
Gross Margin
Operating Expenses
Income Taxes
Net Income

This is a much simpler report … correct? The report in Figure 6 is now more closely aligned with your boss’ simple reporting
request. Compound Dimensions are great for manipulating Data Selection (a.k.a. Data Filters) within an otherwise static column-
set. Each of the five amount columns in Figure 6 is a Compound Dimension, crafted individually with a user-defined
combination of Data Filters. This report, while a bit more time-consuming in development, perhaps five minutes versus two
minutes, is much more flexible because the columns may be tweaked independently of each other.

So, here’s my takeaway. By definition, an MDA tool must offer the ability to cross-join over multiple dimensions; think of this as
basic pivoting. However, not all MDA tools allow you to selectively manipulate the resulting column-sets by compounding the
cross-joined dimensions. Think back to high school chemistry … mixtures vs. compounds. A mixture’s components retain their
original properties. However, a compound is a whole new animal, whose original components have been altered. So, a cross-
join between Fiscal Year, Ledger Type, and Period mixes and matches the GL balance data per the various combinations of the
selected dimension values. A Compound Dimension of Fiscal Year, Ledger Type, and Period, on the other hand, merges these
dimensions into wholly new column definitions, which can be tweaked individually without regard to one another.

Multidimensional Analysis: Parents and Children

We all know the pain of writing a report with hardcoded rows, only to be dealt a blow when someone adds a brand new record to
the JDE Account Master (F0901) table and then posts a journal entry to that new account, which ends up not being incorporated
into the report. Take the following Travel and Entertainment section of a chart of accounts in Figure 7 – Travel and
Entertainment COA.

866-CETOVA-4 Page 5
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

FIGURE 7 – TRAVEL AND ENTERTAINMENT COA

OBJECT SUBSIDIARY DESCRIPTION LOD PEC
7700 Travel and Entertainment 5 N
7710 Travel 6 N
7710 100 Airfare 7 L
7710 200 Auto Mileage 7 L
7710 300 Lodging 7 L
7710 400 Meals – Per Diem 7 L
7720 Entertainment 6 N
7720 100 Meals 7 L
7720 200 Parking 7 L

It’s totally reasonable to assume that, in the name of getting things done, most non-technical end-users would take the most
straightforward approach in coding a detailed T&E P&L. In other words, such a user would most likely code each report row to
correspond with a single record from the F0901 table (i.e. account).

Well, that’s fine, but we all know that it’s not best practice. Obviously, if someone comes along and adds account 7710.500 (Hire
Cars) to the chart, then posts to this new account, without revising the report accordingly, then this new account’s balances will
not be reported. Any decent Multidimensional Analysis (MDA) tool has taken this common reporting exception into
consideration, and offers functionality to select all existing Children for any particular Parent account, business unit, etc. This
way, the user simply codes the report at the Parent-level, with all Children being incorporated at run-time.

In my experience, such Parent-Child functionality may lack robustness with regard to two specific feature-sets.

First, you want an MDA tool that allows you to selectively apply Parent-Child functionality. Many MDA solutions assume a
uniform, properly designed chart of accounts. Based upon this assumption, Parent-Child functionality is typically available only
at the report-level, rather than at the column and row-levels as well. In other words, you instruct the tool to report through Level
of Detail = 7, for example, for all rows. This all-or-nothing approach does not take into account a non-optimal chart of accounts,
or, ad hoc reporting needs. Ideally, you want an MDA tool that allows Parent-Child functionality to be applied differently on a
row-basis. For example, your ad hoc T&E reporting may require that all of the Children to the Travel Parent be detailed, while
those Children for the Entertainment Parent are rolled-up.

Furthermore, following this flexibility theme, you want an MDA tool that offers robust formatting and totaling for each instance of a
Parent-Child function. For example, you may want to strike totals differently throughout the report, with variations in borders, font
formats, and blank row usage.

So, Parent-Child functionality is commonly offered as a mechanism to preserve the integrity between reported versus stored
ERP data. More robust Parent-Child functionality further offers two specific feature-sets. First, the user should be able to
selectively invoke Parent-Child functionality within the report, as opposed to settling for mandatory report-wide usage. Second,
formatting and totaling should likewise be customized per instance of Parent-Child function.

Multidimensional Analysis: Cell Specifications

Most, if not all, of the arithmetic and formatting operations executed by a Multidimensional Analysis (MDA) solution are done so
on either a row or column-basis. Have a look at Figure 8 – Percent Variance P&L.

866-CETOVA-4 Page 6
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

FIGURE 8 – PERCENT VARIANCE P&L

Actual Budget % Variance
Direct Sales 60000 50000 20%
Retail Sales 40000 45000 11%
Revenue 100000 95000 5%
Direct Materials (5000) (4000) 25%
Direct Labor (10000) (9000) 11%
Indirect Materials (1000) (1000) 0%
Indirect Labor (3000) (3000) 0%
Depreciation (1000) (1000) 0%
Costs of Goods Sold (20000) (18000) 11%
Gross Margin 80000 77000 4%

It’s pretty clear that the three bold-formatted total rows are mostly comprised of values derived from row-based summation.
Likewise, Column Three (% Variance) is mostly comprised of values derived from column-based operations performed over the
previous two columns. Mostly…

Now, take a look at the cells shaded in orange. The calculations taking place in these cells, which reside within the bold-
formatted total rows, clearly do not adhere to those default row calculations. Rather than sum the values in previous rows, these
orange-shaded cells perform the columnar percent-variance calculation over Columns One and Two. Therefore, these cells are
exceptions to the default formatting in that the column calculations take precedence over the row calculations.

This is a very common example for the usage of Cell Specifications. Very simply, Cell Specifications allow the user to override
the calculation or formatting that would otherwise be executed in a cell per the default row, column, or report-level specifications.

Once again, at the very least, your MDA tool should allow you to specify whether column or row specifications (e.g. data
selection, calculations, formatting, etc.) take precedence at the report-level. Ideally, to take it a step further, your MDA tool
should allow you to flexibly hardcode individual Cell Specifications independently of existing row, column, or report-level
specifications. So, imagine the ability to use MS Excel-like formulas and references within your MDA report. Have a look at
Figure 9 – Percent Variance P&L with Units.

FIGURE 9 – PERCENT VARIANCE P&L WITH UNITS

A B C D E F G
1 Actual Budget % Variance AU BU % Variance
2 Direct Sales ($) 60000 50000 20% 63 50 26%
3 Retail Sales ($) 40000 45000 11% 39 45 13%
4 Revenue ($) 100000 95000 5% 102 95 7%
5 Direct Sales (Units) REF E2 REF F2 REF G2
6 Retail Sales (Units) REF E3 REF F3 REF G3
7 Revenue (Units) REF E4 REF F4 REF G4

866-CETOVA-4 Page 7
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

In this latest example, you obviously require the traditional presentation of Dollars above Units, i.e. a vertically-oriented
relationship between Ledger Types. However, given that you’ve already specified Ledger Types as columns to enable variance
reporting, well, you’re stuck with a horizontally-oriented relationship between Ledger Types. In my humble opinion, your MDA
tool should allow the following simple end-around: Calculate Units in Columns E through G, Hide Columns E through G, and
Reference the cells in Columns E through G within Columns B through D. Sure, this is a no-brainer for MS Excel, but you’d be
surprised to see how many MDA tools fall short in this area.

So, to conclude these three sections, which detail must-have functionality for a Multidimensional Analysis tool, I hope that you
see a common theme between the need for Compound Dimensions, Parent-Child functionality, and Cell Specifications. These
aforementioned features enable the non-technical end-user to more flexibly specify and format his or her output. Think of
Multidimensional Analysis as a standard rule that’s applied over and over again to multiple permutations and combinations of
field values. Sometimes, you need to bend the rules, and these three features allow just that.

Relational Analysis: Views

Think of a View as nothing more than Select query output that is, in turn, used as the basis for another Select query. The ability
for the non-technical end-user to easily designate query results as subsequent source data is vital to maximizing the utility of a
Relational Analysis tool. More specifically, I can think of two important uses for such functionality.

First, Views created by super-users may be leveraged by non-technical end-users whose reporting may require complex table
joins. For example, say your boss requests a list of open Accounts Payable vouchers from the JDE AP Ledger (F0411) table.
Easy enough … right? Well, suppose your boss also requires the corresponding GL Account Code to which each Pay Item was
accrued, along with the corresponding GL Account Code Description. Well then, you’d better know how to join the F0411 table
to both the General Ledger (F0911) and Account Master (F0901) tables. You’d also need to know how the F0911 Automatic
Entry (Document Type = “AE”) records are generated based upon your AP Constants.

Or, instead of dealing with this mess, you could ask a super-user, or the vendor for that matter, to create a brand new View,
Open AP Accruals, which already joins the required tables, as the basis of your reporting. By the way, a good Relational
Analysis tool will make such custom Views easy to locate, as well as offer User or Role-based View security.

Views are also critical for approximating Multidimensional Analysis (MDA) functionality through your Relational Analysis tool.
Let’s take the following example, where your boss asks for a report that looks like Figure 10 – JDE F0911 Query Results, while
the supporting data is stored as seen in Figure 11 – JDE General Ledger (F0911). Remember, we’re reporting only Period 7.

FIGURE 10 – JDE F0911 QUERY RESULTS

FIGURE 10 – JDE F0911 QUERY RESULTS
Object Code Receipts Adjustments Sales Journal Entries
1310 3000 1500 10000 0
1320 0 0 0 500-
Totals 3000 1500 10000 500-

866-CETOVA-4 Page 8
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

FIGURE 11 – JDE GENERAL LEDGER (F0911)

FIGURE 11 - JDE GENERAL LEDGER (F0911)
Document Number Document Type Amount Period Number Object
GLDOC GLDCT GLAA GLPN GLOBJ
1001 OV 1500 7 1310
1002 OV 1500 7 1310
1003 IA 2000 7 1310
1004 IG 500- 7 1310
1005 RI 10000 7 1310
1006 JE 500- 7 1320
1007 OV 1000 8 1310
1008 OV 1500 8 1310

Hopefully, you’ll remember from my first whitepaper that the optimal solution for this reporting challenge is MDA; when you
require horizontal (i.e. side-by-side) representation of numbers that are stored vertically (i.e. across multiple records).

However, though not optimal, Relational Analysis remains a viable solution for this reporting challenge, especially if an MDA tool
is not available. Very simply, you create four new Views, one per Document Type, each based off the F0911 table. Each View
would be keyed off the Object Code with transaction Amounts summed by Object Code. Then, you create a fifth View simply as
a distinct listing of all Object Code values from the F0911 table. Finally, your sixth View would join the previous five Views by
Object Code to produce the results set forth by Figure 9. Again, this is not as straightforward as dragging and dropping a few
columns through an MDA tool. Nonetheless, it’s just as effective, and just as easy – just more time-consuming.

Relational Analysis: IF Statements

Let’s move from Views into a discussion of how IF Statements can also approximate Multidimensional Analysis (MDA)
functionality. An IF Statement is the mechanism by which we instruct the report to take an action, such as selecting a value, if
certain criteria are met. If such criteria are not met, then we just instruct the report to do something else.

Let’s continue with the example set forth by Figures 10 and 11. Using IF Statement functionality, a user of Relational Analysis
could get pretty darn close to this result. Have a look at Figure 12 – JDE F0911 IF Statement Results. Remember, we’re
reporting only Period 7.

FIGURE 12 – JDE F0911 IF STATEMENT RESULTS

FIGURE 12 – JDE F0911 IF STATEMENT RESULTS
Object Code Receipts Adjustments Sales Journal Entries
1310 1500 0 0 0
1310 1500 0 0 0
1310 Receipts 3000 0 0 0
1310 0 2000 0 0
1310 0 500- 0 0
1310 Adjustments 0 1500 0 0
1310 0 0 10000 0
1310 Sales 0 0 10000 0
1310 Totals 3000 1500 10000 0
1320 0 0 0 500-
1320 Journal Entries 0 0 0 500-
1320 Totals 0 0 0 500-
Grand Totals 3000 1500 10000 500-

866-CETOVA-4 Page 9
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

Basically, a good Relational Analysis tool will allow you to specify the final four columns of the report in Figure 10 using simple IF
Statements. Take the “Receipts” column as an example. Simply put, if the Document Type (GLDCT) of the F0911 record is
“OV,” then we instruct the tool to write the Amount (GLAA) to that column. If the Document Type is not “OV,” then we instruct the
tool to just write a zero. The same If…Then logic is applied to the final three columns as well.

I know what a few of you are thinking, “The report in Figure 12 doesn’t look as cool as the report in Figure 10.” Yeah, well, it’s
not supposed to look that good; it was written using a totally different technology. My point is that, with the right Relational
Analysis functionality, you can approximate the results obtained through Multidimensional Analysis. By the way, if your
Relational Analysis tool also allows you to suppress detail rows and selected total levels, then it will get you really close to the
results seen in Figure 10.

So, to conclude these two sections that detail must-have functionality for a Relational Analysis tool, I hope that you see a
common theme between the need for Views and IF Statements. Both of the aforementioned features enable the non-technical
end-user (i.e. not a SQL expert) to approximate the presentation capabilities of an MDA tool. Frankly, due to relative Total Cost
of Ownership, the non-technical end-user is more likely to have access to a Relational versus MDA tool.

The Big Picture

It’s time to take this conversation up 40,000 feet. I’ve described some specific functionality that no self-respecting JDE Reporting
and Analysis package should be without. That’s great and all, but, some advice for navigating the JDE Reporting and Analysis
market in general would be useful as well.

Niche players … ah yes … there’s some sexy stuff out there. I’m not calling anyone out by name, but I will tell you that there are
some proven, small JDE Reporting and Analysis tools out there in the marketplace. Typically, you’re looking at simple
interfaces, rapid implementation thanks to out-of-the-box integration with JDE, and a low price point.

Here’s the somewhat bad news … the niche packages don’t do much, but what they do, they do extremely well … and rarely will
they advertise what they don’t do. So, as a potential buyer, you also want to be forward-looking vis-à-vis your JDE Reporting
and Analysis requirements. You want a basket of features and functionality into which you can grow. You don’t want to make a
purchase only to redo the Search and Selection process as new requirements surface.

Here are just a few questions that you may want to ask yourself regarding the growth potential of your targeted solution.
• This package does a dynamite job at slicing-and-dicing my General Ledger Balances per various Business Unit and
Account hierarchies. What if, down the line, I need similar analytics over my Procure-to-Pay and Order-to-Cash
Cycles? Will this package operate over additional JDE modules and tables?
• I love the simple, out-of-the-box hooks into JD Edwards. However, I need visibility into some of my non-JDE
operational systems. Will this package quickly and easily integrate with any third-party relational database?
• These pro forma financials look great, as do my ad hoc managerial reports. But, I can’t give these to my boss. What
about graphics and dashboards?

What about the big boys? You know who I’m talking about - enterprise-level players. These guys do everything, but you pay for
it, especially if you do not have adequate in-house JDE expertise, because the level of pre-integration with JDE among these
larger solutions is relatively low. If you work at a recession-proof organization that throws good money after bad Reporting and
Analysis, then fine. On the other hand, if you watch your pennies, and you’re targeting one of these enterprise-level solutions,
then you must take stock of your in-house JDE expertise, and then determine your consulting and services budget.

866-CETOVA-4 Page 10
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

You want as much pre-integration as possible so you’re not paying through the nose for configuration later on. Here are just a
few questions that you may want to ask yourself regarding the out-of-the-box potential of your targeted solution.
• Does this tool come pre-integrated with the JDE Data Dictionary? After all, I need to see my custom field descriptions
and all values (e.g. Dates) properly formatted.
• Can I leverage the Category Codes in the F0006, F0901, F4101, etc.? I’ve worked hard to create these hierarchies,
and I would like to have them recognized readily by my Reporting and Analysis tool.
• On the flip-side, can I easily create custom hierarchies? Unfortunately, some of our JDE Master Data is not up to
snuff.
• JDE tables must be carefully joined to enable drill-back. Does this tool provide out-of-the-box drill-back configured
specifically for JDE?
• Is this tool smart enough to automatically associate UDC Values with their Descriptions from the F0005?
• I’ve made a significant investment in configuring JDE Security, and obviously do not want to do it all over again. Does
this tool integrate with JDE Security?

Remember folks, these are just a few of the questions that you need to ask … but there are tons more. My advice to you? Plan
for growth and take stock of your in-house JDE expertise. Then go shopping.

Summary
Thank you for reading, folks; I look forward to getting emails with feedback, comments, suggestions, and so forth. Please email
me at jlambrianakos@cetova.com.

So, for a non-technical end-user, I’ll set forth the following major takeaway. I fully acknowledge that different organizations and
users will evaluate Multidimensional and Relational Analysis solutions using different and differently-weighted criteria.
Nonetheless, I think it makes sense that, unless your purchase is merely a token act, features and functionality play a pivotal role
in selecting your solution. In my experience, certain features and functions are critical to maximizing your JDE Reporting and
Analysis investment.

You’ve heard the terms – Business Intelligence, OLAP, Cubes, Slice-and-Dice, and so on. I’m sure that you also know the
players. These Multidimensional Analysis (MDA) tools are great because a non-technical end-user can, with a few drags and
drops, compile and execute tons of complex SQL to roll-up enterprise data in useful ways. From a data standpoint, MDA is
indicated when you require horizontal (i.e. side-by-side) representation of numbers that are stored vertically (i.e. across multiple
records).

As previously mentioned, the very nature of MDA processing leads to a level of rigidity in the way output is delivered to the user.
Think of MDA as a standard rule that’s applied over and over again to multiple permutations and combinations of field values.
Sometimes, you need to bend the rules.

In my humble opinion, an MDA tool is truly robust when it allows you to bend those rules. First, Compound Dimensions allow
you to alter the combinations of field values that define individual rows and columns. Second, robust Parent-Child functionality
allows you to preserve the integrity of your reported ERP data through flexible formatting and row or column-based usage, as
opposed to rigid report-wide usage. Third, Cell Specifications allow you to modify the content and appearance of individual
cells, regardless of the more general calculations and formatting specified by the row, column, or overall report.

866-CETOVA-4 Page 11
www.cetova.com
 John Lambrianakos

JD Edwards Reporting and Analysis:

Must-Have Multidimensional and Relational Analysis Functionality

I use the term Relational Analysis in referring to those tools that allow you to select records from ERP tables, just like you
would through Microsoft Access. Envision a simple data dump with sorting, totaling, and formatting. For example, you JDE
World folks have likely used World Writer, a proven tool.

Once again, in my humble opinion, a Relational Analysis tool is truly robust when it allows a non-technical end-user (i.e. not a
SQL expert) to approximate the presentation capabilities of an MDA tool. Relational Analysis tools require a fraction of the
configuration and support as required by MDA tools, and are therefore more prevalent, unless of course your IT department is
looking to keep nursing the end-users. There are two features that will deliver a decent approximation of Multidimensional
Analysis. First, Views allow you to avoid table-join hassles, and, base your reporting upon the output of previous queries, which
logically should become more analytical as you approach the final product. Second, IF Statements allow you to generate more
horizontally-aligned, and therefore more analytical, reporting output.

Finally, at a more general level, understand how to navigate the somewhat complex JDE Reporting and Analysis marketplace.
First, try to evaluate features and functionality in terms of your current and future requirements. Then, identify those features and
functionality that are must-have by virtue of what your organization lacks in terms of JDE expertise.

Next Whitepaper Preview

After reading this whitepaper, you should now have some idea of the functionality that is critical to robust Multidimensional and
Reporting tool. So, please look forward to my next piece, which will discuss best practices for pre-implementation homework.
My goal will be to help you maximize your Multidimensional Analysis ROI.

About the Author

John Lambrianakos (jlambrianakos@cetova.com) is the VP of Marketing and Product Development at Cetova Corp. John has
been working with JD Edwards since 1991, both as a consultant for GL Associates and IBM Global Services, and, in industry as
a Finance Manager at Tiffany & Co. John received his BA in Economics from Vassar College in 1991, and his MBA from the
University of Texas at Austin, McCombs School of Business, in 1995.

866-CETOVA-4 Page 12
www.cetova.com