Introduction
To implement Oracle E-Business Suite 11i as efficiently and effectively
as possible, each and every Oracle project team member needs to understand
the concepts of a successful business system and a software
project. The concepts hold true for any software project regardless of
whether the organization is implementing or upgrading Oracle E-Business
Suite 11i.
ORACLE APPLICATION METHODOLOGY
FosterÕs Oracle Application Methodology (OAM) provides the guidelines
for a successful Oracle applications business system software project.
OAM involves understanding the components of a business system and
how to incorporate the project methodology into the business system (see
Exhibit I.1). The business system components include: hardware, software,
data, people, and procedures. These five components working in
harmony with a proven project methodology will produce a state-of-theart
business system and will guarantee a successful Oracle E-Business
Suite 11i implementation project.
Each business system component is critical to the success of the system.
Clearly, hardware, software, and data are required, but people and
procedures are also an integral part of any system. In addition, each system
component canÕt stand individually and one canÕt replace the other.
There is a balance between the components. For example, many organizations
try to build software to perform user procedures. Each component,
including the project methodology, is described in detail.
1
HARDWARE
Oracle E-Business Suite uses a three-tier hardware architecture. The three
tiers represent the database tier, the application tier, and the PC tier.
Platform
The first decision is the hardware platform. Oracle E-Business Suite supports
a number of hardware platforms. The Information Technology personnel
should review OracleÕs Internet Computing Architecture (ICA)
and determine the organizationÕs optimal hardware configuration.
The project team must determine the number of Oracle applications
instances or occurrences required when sizing the platforms. Typically,
different organizations have different configurations of instances. Oracle
applications instance examples include:
¥ Patch instanceÑpatches are applied and tested
¥ Development instanceÑprogrammers develop custom software prior
to user testing
2 INTRODUCTION
People
Data
Hardware
Software
Procedures
Project Project
Exhibit I.1 Oracle Applications Methodology
¥ Test instanceÑusers test the custom software prior to production
¥ Training instanceÑpeople are trained
¥ Production instanceÑlive data
Also keep in mind the organizationÕs budget cycle. Additional instances
may require additional hardware platforms that may impact the
capital budget. If upgrading, understand the ICA architecture and how
the distribution of platform tiers may increase an organizationÕs hardware
requirements.
Sizing
Prior to purchasing hardware, the organization should perform sizing
calculations for Oracle E-Business Suite. The previous Oracle application
installation manual provided a sizing spreadsheet. Therefore, use
the release 10 sizing spreadsheet as a template. If nothing else, have the
Database Administrator (DBA) calculate sizing estimates based on the
larger volume tables. Use common sense when reviewing or creating the
sizing formulas.
Keyboard Mapping
Oracle E-Business Suite 11i provides default keyboard mapping. The keyboard
mapping may not reflect the organizationÕs standard keyboard
mapping. Have the Information Technology personnel change the keyboard
defaults to comply with in-house standards. For example, set F7 to
Enter Query, F8 to Execute Query, F9 to retrieve a List of Values, F10 to
Save, and so forth. If no keyboard standards exist, create them. Create a
keyboard template for users to position above the function keys.
Printers
Oracle E-Business Suite 11i seeds printer definitions. Many common
printer styles are predefined. The Information Technology personnel
must review the seeded printer definitions and link them to the appropriate
in-house printers. They must also ensure the printers are working
properly. They should test all output types used including portrait, landscape,
and landwide print formats. Any specific custom print styles such
as checks, invoices, statements, dunning letters, and so forth should be
tested as well.
Hardware 3
SOFTWARE
Oracle E-Business Suite software comprises Enterprise Resource Planning
applications, including General Ledger, Payables, and Receivables.
Software Customization Rule
The standard software customization rule of thumb states that 80 percent
of the software application package should fit the organization as is, and
only 20 percent of the software application should be customized. The
rule holds true for Oracle E-Business Suite as well. If over 20 percent of
the software must be developed in-house due to the unique business requirements,
a harder look at the business processes should occur.
Most customers start with a ÒNo CustomizationÓ philosophy. While
this holds true in theory, every organization has some customization. The
trick is to avoid customization wherever possible. The one-time cost and
ongoing costs of customization can easily get prohibitive. The more customization,
the more overhead and testing that must occur with every
patch and upgrade. Try to use functional solutions rather than technical
solutions. Reengineer the business process if possible, and perform costbenefit
analysis projections. In other words, cost-justify the solutions.
Once personnel management see the true cost, they may be less eager to
customize.
All customization should utilize Oracle E-Business SuiteÕs Standard
Report Submission (SRS) capabilities. SRS gives each application the same
look and feel for running batch or concurrent processes. Information
Technology personnel are responsible for adding new batch processes including
custom reports and programs. Using SRS allows the custom software
to have the same look and feel as the other Oracle concurrent
processes. Running the custom software should be transparent to the user.
Oracle Software Support
The first level of support for Oracle E-Business Suite is the Oracle applications
documentation. The installation CDs contain a documentation
CD. The documentation file formats include HTML and PDF. (HTML is
the language the web browser understands and PDF is the Adobe Acrobat
file format.) The Information Technology personnel should install the
documentation and provide the organization with full Oracle applications
documentation. Exhibit I.2. displays the Oracle Applications Documentation
Library.
4 INTRODUCTION
Navigate through the Oracle applications HTML documentation
as with any other internet-compliant application. Start with the appropriate
tab and drill-down to the specific documentation. For example,
press the ERP (Enterprise Resource Planning) tab to review the documentation
for Oracle General Ledger, Oracle Payables, and Oracle
Receivables.
Exhibit I.3 displays the Oracle Applications Adobe Acrobat documentation
file directory. The PDF user guide naming standards include the release
number, the application short code, and the type of manual. The
release number is 115 (release 11.5), the application short codes are AP,
AR, and GL, and the manual type is UG for user guide manual. For example,
the Oracle Payables user guide is 115APUG.PDF.
The Oracle Applications PDF technical reference manual naming standards
include the application short code and the type of manual of TRM.
For example, the Oracle Payables technical reference manual is
APTRM.PDF.
Software 5
Exhibit I.2 Oracle Applications Documentation Library: HTML
MetaLink
Use OracleÕs MetaLink website (www.metalink.oracle.com) to check for
application issues and patches. (See Exhibit I.4). MetaLink provides a forum
for all users to share and trade information. The organizationÕs support
number, for example, the Customer Support Identifier (CSI) number,
is required to sign in.
Oracle supports only certified software versions for the specific hardware
platform. For example, Oracle E-Business Suite 11i with Oracle database
version 7.4 is not supported. Check MetaLink for the certified
software versions and make sure the organization is compliant.
Oracle Apps World and Oracle Applications User Group
Oracle Apps World (sponsored by Oracle Corporation) and the Oracle
Applications Users Group (OAUG) meet periodically. Both conferences
provide functional and technical papers presented by Oracle, the user
community, and various consulting firms. Both conferences are an excellent
resource for improving an organizationÕs understanding of Oracle applications
and functionality. In addition, new releases are demonstrated
and new features discussed.
6 INTRODUCTION
Exhibit I.3 Oracle Applications Documentation Library: PDF
Oracle Applications and Personal Computers
Each userÕs personal computer must be configured with software to run
Oracle E-Business Suite 11i. A web browser, such as Netscape Navigator
or Microsoft Internet Explorer, is required to log onto the organizationÕs
Oracle applications internet address. In addition, Jinitiator software from
Oracle must be loaded on the PC to connect with Oracle applications.
Typically, the Information Technology group is responsible for configuring
the PCs. Develop and follow in-house procedures for installing software
on the userÕs PC.
Testing
Testing Oracle applications needs to be intensive. After the business requirements
have been defined, the test scenarios and test plans may be
developed for the four testing methodologies. The testing methods
should be used in sequential order and should be utilized initially during
implementation and later during patch or upgrade testing. The four
Software 7
Exhibit I.4 Oracle MetaLink
testing methodologies are: unit, system, integrated, and Conference
Room Pilot.
Unit testing tests the individual transactions within the application.
For example, Ò Can I enter a supplier?Ó may be one unit test scenario.
ÒCan I enter an invoice?Ó may be another.
System testing tests the transactions from cradle-to-grave within the
application. System testing involves testing the entire business process
within the application. For example, ÒCan I enter a supplier, enter a supplier
invoice, and create a disbursement to the supplier?Ó may be one system
test scenario.
Integrated testing tests the transactions from cradle-to-grave, including
all interfaces and customization for all applications. Testing the entire
business process within all the applications is called integrated testing.
ÒCan I load the supplier data from an interface, enter a supplier invoice,
create a disbursement to the supplier, and post the journals in Oracle General
Ledger?Ó may be one integrated test scenario.
Conference Room Pilot (CRP) testing tests the transactions from cradle-
to-grave, including all interfaces and customization for all applications
for an entire business period. Testing the entire business process as a
monthly cycle is considered CRP testing. ÒCan I enter an entire monthÕs
worth of typical transactions for all Oracle applications?Ó may be the
high-level CRP test scenario. The CRP testing should be signed off by the
users and the steering committee.
The CRP test plans should be saved for patch and upgrade testing. In
addition, the test plans may also serve as the foundation for user training
materials and user procedure documentation. As the use of Oracle applications
change during the lifetime of the software, remember to incorporate
the new features into the test plans.
Housekeeping
Oracle Applications require the Information Technology personnel and
users to perform housekeeping tasks. The Information Technology personnel
are responsible for installing Oracle E-Business Suite 11i and con-
figuring and tuning the system. In addition, the Information Technology
personnel are responsible for monitoring the batch processes, including
purging old batch requests that include the report and log files. Typically,
a Ònumber of days oldÓ is selected for purging. For example, all batch requests
over five days old are purged. Users should be aware of the daysold
purge criteria and produce reports accordingly.
The users are responsible for purging the application data periodi-
8 INTRODUCTION
cally. At year-end, the purge of old data should occur. Journals, balances,
and other transaction tables, such as invoice and payment tables, should
be purged. Determine the reporting requirements and remove the unnecessary
data, especially before an upgrade! Review each application for the
purge capabilities. Remember to back up and test purge before attempting
to purge production data.
Patches and Upgrades
Patches are enhancements to Oracle Applications. Typically, patches are
downloaded from OracleÕs MetaLink site. All patches should be tested
thoroughly before installing into production, no matter how insignificant
the patch may seem. Do not install patches and test them in the production
environment!
Upgrading Oracle applications is not for the faint of heart. The upgrade
process is a project. All custom software must be reviewed and determined
if the customizations remain necessary. Users must thoroughly
test the upgraded software as if going into production.
DATA
Oracle E-Business Suite Data is stored in OracleÕs database. As with any
system, the quality of the data is criticalÑgarbage in, garbage out.
Relational Architecture
All team members must have a high-level understanding of relational architecture
before utilizing Oracle applications. The table concept of rows
and columns is similar to the spreadsheet architecture, and the organization
should be educated as such. A user must understand the architecture
before properly navigating the windows and entering data.
Data Flows
The current business processes should be diagrammed. The cradle-tograve
business processes should document the steps and the data flows.
After the processes are documented, review the steps and data flows to
note unnecessary or duplicate steps. Determine how Oracle applications
will perform the business processes. Note the gaps between the software
application and the business process. Develop solutions. Ask ÒWhy?Ó
Data 9
Reengineer the business process, think of workarounds, or at worst, design
a custom software solution.
In addition, the future business processes should be diagrammed. A
flowcharting package should be used to document the envisioned cradleto-
grave business processes. This data flow diagram should also be used
as a prototype for the training plans, the test plans, and the user procedures
documentation.
Conversion
To convert or not to convert, that is the question. Converting legacy data
can be time-consuming, expensive, and complex. Determine the historic
reporting requirements and perform a cost-benefit analysis. And remember,
like-to-have reporting requirements are different than have-to-have
reporting requirements. For example, the financial reporting requirements
of prior year actuals to current year actuals is most likely have-to-have reporting.
Supplier payment history for the past year is an example of liketo-
have reporting.
The project team must determine the conversion requirements, then
provide the conversion plan. First, consider converting manually. If the
volume is too large, convert the legacy data via a custom software conversion
program. The process can be complex and time-consuming. The
legacy data must be downloaded, cleansed, and run through the conversion
program into Oracle applications. Typically, the data is not in a relational
database format. The Information Technology group must
provide a vehicle for the users to view and cleanse the data. Duplicates
must be noted and merged. This process can be very time-consuming as
the conversion data files can be large. Automated approaches to noting
possible duplicates and data cleansing are available, but user involvement
is still critical.
Also, timing issues with conversion extracts must be understood and
planned for. Given the time it takes to cleanse the data, the team must determine
how the new records and changes are to be identified and added
to the previously extracted conversion data so the entire file is converted
prior to production.
Interfaces
Oracle Applications provide the table layouts for converting or interfacing
legacy systems. These open interfaces are now documented in the
10 INTRODUCTION
user manuals rather than the technical manuals. The project team must
determine what data, if any, must interface. All interfaces into and out of
the current legacy systems should be documented. All future in-coming
and out-going interfaces to Oracle applications should be documented
also. The interface flow documents will confirm that all interfaces are included
in the project plan and project testing scenarios.
PEOPLE
People represent the organizationÕs personnel. Both functional and technical
personnel must be included.
Team Personnel
The project team members should include: the steering committee, management,
functional users, Information Technology personnel, including
programmer/analysts, Database Administrators, and System Administrators.
Typically, consultants, contractors, upper management, and Internal
Audit complete the project team.
The steering committee and management determine the high-level
project scope and expected project dates. The functional users determine
how the organization will utilize the Oracle applications functionality.
As part of the Information Technology personnel, programmer/
analysts design and develop the custom software, including conversion
programs and custom reports. The Database Administrator is responsible
for installing and maintaining the Oracle databases. The
System Administrator is responsible for setting up the application
infrastructure including users, menus, printers, and system profile
values.
Although the implementation of Oracle E-Business Suite 11i does not
require the use of consultants or contractors, they can make the project
more effective and efficient. Consultants provide application knowledge,
project guidance, and leadership. For example, a consultant can provide
the project plan. Contractors perform the work the organization specifies.
For example, a contractor builds the customer conversion program. Although
each type of outside resource is needed, understand the use of
each and why they are not interchangeable. Interview and check references
for the specific consultant or contractor, just as you would for an
employee.
People 11
Team Attributes
Functional and technical personnel must compose the team. And they
must be dedicated to the project. If personnel are not dedicated to the project,
the probability of success diminishes significantly. In addition, if only
technical personnel comprise the team, the probability of user acceptance
is significantly lessened. All project team members must be able to communicate,
think, and be team players. Each must be willing to make decisions,
trade information, and share the project responsibilities. These
attributes do not necessarily reflect the strongest or more experienced personnel
in the respective area.
Most crucial is a proven Oracle applications leader who can ensure
the project stays focused, keeps its scope, and remains on track. In addition,
the project leader must control the schedule, and make adjustments
as changes occur and issues arise. The ability to identify,
prioritize, and resolve project issues in a timely manner is critical. In
addition, the project leader must be able to convey confidence, even in
dire times.
Train the Trainers
Use an experienced Oracle applications instructor. Afterwards, have the
best users train the remaining users. Do not use an in-house training department
to teach Oracle applications. Other organizations have tried
and, at best, it works poorly. This is not a spreadsheet package. It is a flexible
but complicated software package. A quality Oracle applications instructor
understands the organizationÕs business processes and how they
are accomplished with the Oracle software and in-house custom software
and procedures.
In addition, the training should be specific to the organization. The
training materials should be developed from the testing materials and
should be used as a starter set for the user procedure manuals.
Ensure the users have had adequate PC training. They should be able
to sign-on, use the mouse, and navigate the system prior to learning how
to use Oracle applications.
In addition, make the training time as productive as possible. Get a
training room with one PC per two users. Users learn by doing, not by
hearing; it is like driving a car. Get them behind the wheel! In addition,
the training room gets the users out of their offices where too many distractions
can occur.
12 INTRODUCTION
Train When Appropriate
Training users more than one month before they actually sign-on and use
the system is fruitless. They will forget everything they learned and have
to be retrained. In addition, train new users or new employees to the organization.
Do not consider training to be a one-time occurrence.
Application and Query Training
Training should include functional and technical training. Many users,
while not needing to know the Oracle applications technical details, can
benefit from a technical overview. Many functional users are able to use
query tools against the data tables to create their own custom reports.
PROCEDURES
Procedures document the organizationÕs business and system processes.
Procedures should be easy to follow and include complete documentation.
In-house Procedures
In-house user procedures must be developed. Although Oracle E-Business
Suite release 11i is the internet version, it is not necessarily intuitive.
New users must be trained and procedures must be documented to ensure
the organizationÕs business processes are working properly.
Project team members should have documentation standards. A project
setup book should be created with all setup screen shots, reports, and
test scenarios. Key setup decisions, such as the accounting flexfield, may
have Òwhite papersÓ detailing the analysis, design results, and recommendations,
and should be included.
Data Naming
Create in-house naming standards and follow them. Develop naming
standards from OracleÕs standards or create new ones. Naming standards
apply to functional and technical team members.
The functional team should develop the internal Oracle Applications
naming standards. For example, the functional team should develop supplier
and customer naming standards. Remember relational database
Procedures 13
models stress the use of English. In other words, use code names which
have meaning on their own. For example, use Yes and No, not codes such
as 0 or 1 to reflect Yes and No. As another example, user-names should be
real user-name identifiers such as SFOSTER, not the old legacy sign-in
code of F42628.
The technical team members should follow OracleÕs file and directory
naming standards for consistency. All customization should reside
in a unique directory. Do not place customizations under Oracle applications
directories or they risk being overwritten during the upgrade
process.
Examples of naming standards should be developed for:
¥ Key flexfields, including the value set name, segment name, and segment
structure name
¥ Descriptive flexfields
¥ Oracle General Ledger Financial Statement Generator report components
and report names
¥ Responsibilities, menus, users, printers, SRS concurrent processes
¥ Segment values, List of Values, Quick Codes
¥ Supplier and Customer names and address data
¥ Batch names as in journals, invoices, receipts, and disbursements
PROJECT METHODOLOGY
Each organization needs to have a project methodology. How is the organization
going to document the project? Typically, different consulting organizations
provide their own project methodology. How does the
methodology document the business process flows? The gap analysis?
The custom software required? Does the methodology provide real value
or only promote additional consulting hours? The key is to balance the
cost of the methodology with the benefit to be derived.
Project Scope
Have management clearly define the project scope at the beginning of the
project. Have the project team clearly understand and stick to the project
scope. DonÕt deviate from the scope without management approval.
14 INTRODUCTION
Many projects have scope creep, which precludes the organization from
implementing on-time or meeting the true project objectives.
Project Plan
The project should have a project plan. The project scope and project lifecycle
must be incorporated into the project plan. Realistic milestones should
be incorporated from the project scope document. Typically, all major milestones
and tasks should be detailed. Use a project software package that
details the tasks, the resources, and the task dependencies. Once the project
plan is created, use the plan to monitor performance. Actual to baseline
comparisons may be performed to indicate lagging project tasks.
Project Communication
The project team members must communicate on a regular basis. Weekly
status meetings and weekly status reports from each team member are a
must. As the production date nears, the project team may have daily
meetings. Project team communication is critical to monitoring and managing
the project plan.
In addition, all project documentation should be available to all project
team members. Use shared public folders on a network directory with
files detailing:
¥ Project Scope
¥ Project Plan
¥ Current and Future Business Process Flows
¥ Status Meetings
¥ Issues: Open and Closed with the resolutions
¥ Conversions/ Interfaces/Customizations
¥ Naming Standards
¥ Test Plans
¥ Setup Documentation
¥ User Procedures
¥ Training Materials
¥ Technical Assistance Requests (TARs) logged to Oracle Support
¥ Any other information all team members should share
Project Methodology 15
Project Lifecycle
All project team members must understand the project lifecycle. The project
lifecycle is: Analysis ¥ Design ¥ Development ¥ Testing ¥ Implementation
¥ Production. The steps are sequential. Typically, problems
occur if one phase is rushed. Just because the CFO said the organization is
going live January 1, doesnÕt mean it is a good idea. Nine women canÕt
have a baby in one month no matter how much the CFO or CIO wants it
and is willing to throw money at it.
During the analysis phase of the project, the project team should conduct
interviews with upper management to determine the organizationÕs
critical success factors. What does the organization consider the top priorities
to be? Verify that the critical success factors are within the project
scope, if applicable. The project must ensure that the organizationÕs critical
success factors are met. Look at the organization hierarchy document;
make sure all levels of the organization have been interviewed and the
relevant critical success factors have been included in the project scope.
The ability to think differently and adapt to change is hard. Many organizations
implement exactly what they have in their legacy systems.
They make Oracle applications a mirror image of the current system.
Users are accustomed to the current process. Identifying business process
improvements and convincing users and management to change can be
challenging at best.
When reviewing the cradle-to-grave business processes, ask if each
step in the process is adding value? Is the human touching the paper (or
transaction) adding value to the process, or is that person simply following
the business process designed long before? If the process is not adding
value, ask why is it occurring? In order to maximize the organizationÕs return
on investment, donÕt recreate what is there today. Think differently.
16 INTRODUCTION
1
Concepts
OVERVIEW
OracleÕs E-Business Suite 11i is the first true integrated set of business applications
in a database environment available in an internet format. Using
OracleÕs database technology and combining OracleÕs superior
integrated applications provides a state-of-the art business system with
extreme flexibility. Each organization has the ability to implement these
applications according to its specific processing environment.
While there are a multitude of Oracle applications within the E-Business
Suite 11i software package, this book focuses on core financials Oracle
General Ledger, Oracle Payables, and Oracle Receivables. Once the
learning curve of these applications is under way, the learning curve of
the other applications should be significantly reduced.
Prior to navigation through the system, a number of Oracle concepts,
including the integration between the applications, should be understood.
These concepts are documented in this chapter or are included in the respective
application chapter.
ORACLE E-BUSINESS SUITE 11i Integration
Oracle General Ledger is fully integrated with Oracle applications, including
Oracle Payables and Oracle Receivables (see Exhibit 1.1).
Oracle General Ledger defines the processing environment used by
Oracle Payables and Oracle Receivables. The environment defines the
17
CHAPTER
specific organizationÕs chart of accounts, calendar, and currency. Oracle
Payables journal entries to Oracle General Ledger include Invoices and
Disbursements. Oracle Receivables journals entries to Oracle General
Ledger include Invoices and Receipts.
All accounting transactions flow to the Oracle General Ledger with
full audit trail capabilities, even if the Oracle Payables or Oracle Receivables
subsystem journals are summarized. Drill-down capabilities from
the Oracle General Ledger journal entry to the Oracle Payables and Oracle
Receivables subledgers are available. In addition, release 11i allows the
ability to view the actual T-accounts and journal entry transactions.
ORACLE GLOSSARY
Oracle applications have specific terminology. A sample of terms a user
must comprehend before navigating or setting up Oracle E-Business Suite
11i will be discussed.
18 CONCEPTS
Exhibit 1.1 Oracle E-Business Suite General Ledger Integration
Responsibility
A responsibility determines which Oracle applications a user may access.
In addition, a responsibility determines what transactions a user may perform
and optionally, what data the user may perform the transaction on.
For example, the accounting manager may have full access to Oracle General
Ledger, while the accounting clerk may only have access to the Oracle
General Ledger journal entry transactions.
Concurrent Processing
Oracle applications use concurrent processes to perform batch processing
or background processing. Batch processes include creating reports, running
custom software, or posting journals. OracleÕs concurrent manager
processes these batch requests. The concurrent request starts with a status
of Pending. Once the concurrent manager begins processing the request,
the status will change to Running. After the concurrent process is done,
the status will change to Completed.
Concurrent requests may be run as an individual request or as a request
set composed of a parent request, which spawns many child requests.
For example, a GL month-end report set may have the Trial
Balance report and General Ledger report produced. Each request will
have a unique concurrent request number.
System Administrator
The System Administrator is responsible for setting up the applications
foundation and monitoring the applications. The System Administrator
defines the users, menus, user responsibilities, printers, and appropriate
profile values. In addition, the System Administrator is responsible for
defining and controlling concurrent processing. Most organizations have
the System Administrator as the Oracle Applications Help Desk. In other
words, when a user encounters a question or issue, the first person asked
for help is the System Administrator. In addition, the System Administrator
contacts Oracle for support assistance.
Database Administrator
The Database Administrator is responsible for installing and configuring
the Oracle database and applications. In addition, the DBA is responsible
Oracle Glossary 19
for the daily monitoring of the database and users, for managing security
privileges, and for performing database sizing and tuning.
Flexfields
Oracle applications provide flexfields to allow each organization the ability
to define its own reporting structures. Two kinds of flexfields are provided:
key flexfields and descriptive flexfields. Key flexfields are required
within Oracle applications to record key data elements. Descriptive flex-
fields are user-defined and record required data elements not provided by
standard Oracle applications functionality.
The key flexfield types are predefined. Each key flexfield type is
owned by a specific Oracle application, but is shared across all the applications.
For example, the accounting flexfield represents the chart of accounts
and is owned by Oracle General Ledger, but is shared with all
Oracle applications that create financial transactions. The key flexfield de-
finition process and setup steps are described in detail in Chapter 4.
Account Generator
Some Oracle applications utilize the Account Generator. The Account
Generator replaces FlexBuilder as the tool to automatically create accounting
flexfield combinations. The Account Generator process utilizes OracleÕs
workflow capabilities. The Account Generator is not required for the
core financials unless utilizing the gain/loss or finance charges functionality
of Oracle Receivables.
Set of Books Architecture
The Oracle General Ledger (GL) Set of Books concept must be understood.
An Oracle GL Set of Books contains the same three Cs: the same
chart of accounts, the same calendar, and the same currency (see Exhibit
1.2).
All three are unique within a GL Set of Books. The chart of
accounts determines the accounting flexfield structure and segment
values. The calendar defines the transaction and reporting periods,
such as months or periods. The currency defines the functional currency
for the organization.
If one of the three Cs for the GL Set of Books is different, such as a different
chart of account structure, another GL Set of Books must be created.
20 CONCEPTS
Oracle Glossary 21
Exhibit 1.2 Oracle General Ledger Set of Books
Oracle applications post to one, and only one, GL Set of Books. The GL:Set
of Books profile must be linked to the appropriate application responsibility.
Therefore, the application responsibility determines where the financial
transactions will be posted. For example, the Payables Manager U.S.
responsibility will post to the U.S. GL Set of Books and the Payables Manager
U.K. will post to the U.K. GL Set of Books.
Single Organization Architecture
OracleÕs single organization architecture allows one Oracle Payables and
one Oracle Receivables instance or occurrence to post to a GL Set of
Books. In earlier releases of Oracle applications, the GL Set of Books restriction
with the three Cs led many organizations to have multiple instances
of the other Oracle applications, including Oracle Payables and
Oracle Receivables. The one currency restriction was cumbersome for organizations
with operations in multiple countries. These instances were
independent and led to duplicate data (see Exhibit 1.3).
Multi-Organization Architecture
Oracle applications release of multi-organization functionality now integrates
the multiple GL Set of Books capabilities to the multiple occurrences
of Oracle Payables and Oracle Receivables (see Exhibit 1.4).
Multi-org allows all instances of Oracle Payables and Oracle Receivables
to be in the same instance as Oracle General Ledger.
OracleÕs multi-org architecture resolves the single org architecture issue.
The organization now decides which organizations are within one instance.
All Oracle Payables instances may be in one instance and still
integrate with Oracle General Ledger.
This multi-org flexibility leads each organization to define centralized
data and procedures along with decentralized data and procedures. In
other words, an organization can define the organization-wide Oracle applications
environment or centralized environment. Each logical group
within the multi-org environment can have its own Oracle applications
environment or decentralized environment. For example, Corporate can
dictate the supplier naming standards while each operational facility can
dictate its payables environment.
OracleÕs multi-org concepts must be understood prior to defining the
multi-org environment. Understanding the multi-org levels is critical for
the multi-org environment to work properly. The multi-org concepts are
displayed in Exhibit 1.5.
22 CONCEPTS
Prior to defining the multi-org structure, develop the multi-org design
on paper first. Use Exhibit 1.6 as a simple template to design and document
the various organization levels and values. See Chapter 6 for the required
setup steps and more information.
Relational Architecture
Oracle applicationsÕ underlying architecture is OracleÕs relational database
version 8i. A relational database is composed of tables. A table is
Oracle Glossary 23
Exhibit 1.3 Single Org Architecture
very similar to a spreadsheet with rows representing data records and
columns representing the data element types. The supplier table consists
of supplier number, supplier name, supplier type, and so forth (see
Exhibit 1.8).
A relational database table is a collection of data records (see Exhibit
1.7). For example, a supplier table is a collection of supplier records or
rows. A row is a unique record. The rows make up the data records. Ex-
24 CONCEPTS
Exhibit 1.4 Multi-Org Architecture
Oracle Glossary 25
Exhibit 1.5 Multi-Org Concepts
Exhibit 1.6 Organization Design
amples include: 22201 Lexington Associates or 24232 Belmont Electric. A
column is a field or data element. For example, a supplier number or supplier
name field represents a column. A combination of columns or fields
makes a record.
OracleÕs relational database architecture supports one-to-many data
relationships (see Exhibit 1.8). Each table may have a one-to-many
relationship with another table. Tables are related by a key column and
are indicated to the user through different screens or windows. For
example, one supplier may have more than one supplier site or location.
The one supplier record, Boxford Engineering, has three supplier
site records. Project team members must understand this concept prior
to designing and developing conversion programs for suppliers or
customers.
In addition, the one-to-many relational database architecture will be
evident when navigating through the windows. Usually, each window
represents a table. For example, there is one window for supplier and another
window for supplier sites. If the two tables are displayed in one
26 CONCEPTS
Exhibit 1.7 Relational Table Architecture
window, usually they are segregated into blocks or logical divisions of the
window.
Windows also may call views or subsets of the table. Oracle application
windows in a multi-org environment call a view of the related
table. For example, the data displayed in the Payable Options window
is a view of the related table for the specific organization. The table contains
all the data and the view provides the organization-specific subset
of the table.
Oracle Glossary 27
Exhibit 1.8 Oracle Table Relationships