- Shopping Bag ( 0 items )
Oracle Application Methodology.
Chapter 1. Concepts.
Oracle E-Business Suite 11i Integration.
Chapter 2. Oracle Applications Navigation.
Accessing Oracle Applications.
Data Entry Mode.
Chapter 3. Setting Up Oracle Applications.
System Administrator Step 1.1: Responsibility.
System Administrator Step 1.2: User.
System Administrator Step 1.3: Printer.
System Administrator Step 1.4: Profile Values.
System Administrator Step 1.5: Concurrent Processes.
Chapter 4. Flexfields.
Accounting Flexfields Step 2.1: Setup.
Accounting Flexfields Step 2.2: Values.
Accounting Flexfields Step 2.3: Cross-Validation Rules.
Chapter 5. General Ledger.
Using General Ledger.
General Ledger Step 3.1: Calendar.
General Ledger Step 3.2: Set of Books.
General Ledger Step 3.3: Profile Values.
General Ledger Step 3.4: Intercompany Account.
General Ledger Step 3.5: Open Period.
Inquiry and Reporting.
Chapter 6. Multi-Org.
Multi-Org Step 4.1: Human Resources User Profile.
Multi Org Step 4.2: Locations.
Multi Org Step 4.3: Organizations.
Multi Org Step 4.4: Responsibilities.
Multi Org Step 4.5: Profile Values.
Multi Org Step 4.6: Adamin.
Multi Org Step 4.7: Other Profile Values.
Chapter 7. Payables.
Payables Step 5.1: Lookup Codes.
Payables Step 5.2: Select Set of Books.
Payables Step 5.3: Profile Values.
Payables Step 5.4: Payment Terms.
Payables Step 5.5: Financial Options.
Payables Step 5.6: Expense Report Template.
Payables Step 5.7: Bank Accounts.
Payables Step 5.8: Payables Options.
Payables Step 5.9: Reporting Entities.
Payables Step 5.10: Open Period.
Matching to Purchasing.
Employee Expense Report.
Inquiry and Reporting.
Chapter 8. Receivables.
Receivables Step 6.1: Flexfields.
Receivables Step 6.2: System Options.
Receivables Step 6.3: Payment Terms.
Receivables Step 6.4: Open Period.
Receivables Step 6.5: AutoAccounting.
Receivables Step 6.6: Transaction Types: Credit Memos.
Receivables Step 6.7: Transaction Source.
Receivables Step 6.8: Collectors.
Receivables Step 6.9: Approval Limits.
Receivables Step 6.10: Receivable Activities.
Receivables Step 6.11: Bank Accounts.
Receivables Step 6.12: Receipt Classes and Payment Methods.
Receivables Step 6.13: Receipt Sources.
Receivables Step 6.14: Statement Cycles.
Receivables Step 6.15: Profile Values.
Receivables Step 6.16: Customer Profile Class.
Receivables Step 6.17: Customers.
Receivables Step 6.18: Remit-to Addresses.
Receivables Step 6.19: (Standard) Memo Lines.
Receivables Step 6.20: Tax Codes.
Inquiry and Reporting.
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 General Ledger is fully integrated with Oracle applications, including Oracle Payables and Oracle Receivables.
Oracle General Ledger defines the processing environment used by Oracle Payables and Oracle Receivables. The environment defines the 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 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.
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 Database Administrator is responsible for installing and configuring the Oracle database and applications. In addition, the DBA is responsible for the daily monitoring of the database and users, for managing security privileges, and for performing database sizing and tuning.
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 flexfields 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 definition process and setup steps are described in detail in Chapter 4.
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.
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 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. Examples 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. 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 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.