The following terms are excerpted from Chapter 1 of Susan Foster's book, "Oracle E-Business Suite 11i: Implementing core financial applications." Click for book details.
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 below.
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.
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.
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.
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 of Susan Foster's book.
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.
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. 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.
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.
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. 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.
Prior to defining the multi-org structure, develop the multi-org design on paper first. See Chapter 6 of Susan Foster's book for the required setup steps and more information.
Oracle Applications' underlying architecture is Oracle's relational database version 8i. A relational database is composed of tables. A table is 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.
A relational database table is a collection of data records. 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. 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. 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. One supplier record may have 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 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.