Oracle E-Business Suite (EBS) is an integrated suite of enterprise software modules for financial management, supply chain management, manufacturing, project management, human capital management, and customer relationship management. Oracle E-Business Suite history dates back to nearly 25 years ago when Oracle started the Oracle Applications division, a group focused on building business management software closely integrated with Oracle database. The first Oracle ERP Application, Oracle General Ledger was launched in August 1988. Since then, Oracle Application releases have continued at regular intervals. May 2000 saw the introduction of Release 11i and in January 2007 Release 12 was launched.
This book is intended to serve as a quick guide for Oracle E-Business Suite users and implementers. This handbook discusses two key business process flows—Order to Cash and Procure to Pay.
In this chapter, we will discuss the foundation features and various products that make up Oracle Financials:
Navigation within Oracle E-Business Suite with focus on Release 12
Fundamentals of flexfields
Shared entities
Multiple Organization (MO) concepts
Multiple Organization Access Control (MOAC)
Integrated flows
Globalization support
Key aspects of application security
Oracle E-Business Suite has multiple products that support the capability to manage an enterprise. The term often used with these type of software solutions is ERP, which stands for Enterprise Resource Planning (ERP).
There are various ERP software solutions in the market but this book focuses on the solution from Oracle and the latest version is most often referred to as "EBiz Suite R12" or just simply R12 in this book (and in discussions and forums).
This handbook focuses on Oracle Financial products for Procure to Pay (P2P) and Order to Cash (O2C) business flows. As we will also be covering Oracle Fixed Assets and some reporting aspects in the following chapters it might seem like we are also covering additional flows or portions thereof, but the focus will remain on these two flows mentioned previously.
It is important to note the fact that these are separate products (and were at some point in time developed as stand-alone products) and there are differences in the way they feel, act, and look. Though they accomplish their goals in an integrated fashion, some of the technological framework is different. This does in many cases lead to interesting scenarios.
Over the following chapters, you will be introduced to key setups and key configurations considerations of Oracle Financial Applications products and transaction processing concepts.
The modules that will be covered are:
General Ledger
Subledger Accounting
Accounts Payables
Accounts Receivables
Cash Management
Treasury
Fixed Assets
Inventory
Purchasing
Order Management
Credit Management
The following common products are integrated with the Oracle Financials suite and serve as important building blocks:
Key setups and configurations will be discussed for the common modules.
Oracle E-Business Suite is a complete set of business applications that enables corporations to efficiently track detailed business transaction data to help gather decision-making information. Oracle Financials are a subset of the E-Business Suite and are a family of products designed to capture and analyze your financial data. Oracle Financials applications helps to meet your obligations in key areas such as:
Compliance
Financial control
Regulatory reporting
Cost containment
Risk management
Though the following chapters do not necessarily cover all these aspects in detail the controls and reporting capabilities are inherently built into the suite and are available to be implemented and used as needed.
Some products may need additional licensing. One of the data entities we will talk about in this chapter is generically called organizations. The financial suite supports the capability to help represent various business models in its configuration structure and are represented with related data entities. These can be listed in brief as follows:
Your organization
The role of your Legal entities
Representing your organization in the system
Organizational classifications in Oracle Financials
Chart of Accounts
System entities
We will briefly cover the inherent aspects of the organization in this chapter and the details will be covered in subsequent chapters where they are more relevant and configured. In Oracle E-Business Suite Release 12 (R12) the legal entity has been upgraded to an important data entity and now controls the ownership of various transactional and master data within the product suite. This is covered in more detail in Chapter 2, General Ledger.
The Chart of Accounts is a key feature in capturing your transactional accounting information to be able to report in a manner that supports and benefits the organizations' various organizational requirements.
Organizations and what they denote and identify will be briefly covered in a later part of this chapter.
As mentioned in the earlier part of this chapter, E-Business Suite is an integrated solution that has the capability to manage multiple business processes that support any given enterprise. The supported processes are:
The business flows depict the close integration between the products as data flows from one to the other and also highlight the shared data sets that they use.
The two main business process flows associated with Oracle E-Business Suite Release 12 financial modules and the ones that we intend to cover in this book are as follows:
The Order to Cash (O2C) process is the revenue generating business process in the enterprise and is supported by the following E-Business Suite products:
Oracle General Ledger : Accounting journals for Receivables and Inventory activity
Oracle Receivables/iReceivables : Book receivables for goods shipped and services rendered (only if Service Contracts is not installed)
Oracle Order Management : Manage Orders, ship goods, and services
Oracle Cash Management : Banks for collecting Cash Receipts
The Procure to Pay (P2P) process is the procurement and related activity in the enterprise, and is supported by the following E-Business Suite products:
Oracle General Ledger : Accounting journals for Accruals, Invoices, Payments, and Inventory receipts
Oracle Cash Management : Reconcile cash payments, adjustments and corrections to cash payments and manage Banks
Oracle Payables/iExpenses : Record invoices and employee expense reports
Oracle Inventory : Set up inventory/expense items, record inventory activity such as receipts of inventory, returns, and corrections.
Oracle Purchasing/iProcurement : Procure goods and services, record periodic and perpetual accruals
The financial application suite of products share a common data model and a set of integrated applications to give the enterprise a holistic view of their data. This enables the enterprise to view their business/financial information in a consolidated view and assist in their making informed decisions.
The products also share—due to the tight integration—data elements across them so that an entity (say an Employee) that has been defined in one product is the same entity that is used across all products that require that entity. This reduces maintenance overhead and leads to accuracy in the data that is used across the products.
Shared entities allow one-time definition of a business object so that it can be used across various modules. The ownership of a shared entity within a business organization may vary but technically the ownership is linked to a single module.
Here is a list of some often used shared entities with corresponding product owners:
|
Shared entities |
Product owner |
|---|---|
|
Unit of Measure |
Inventory |
|
Items |
Inventory |
|
Suppliers |
Purchasing |
|
Customers |
Receivable |
|
Salespersons |
Sales |
|
Employees |
Human Resources |
|
Locations |
Human Resources |
|
Currencies |
Application Object Library |
The last product Application Object Library (AOL) is a technological layer that owns a lot of internal data elements and the currencies happen to be part of this product.
Not many other data sets that you will work on at a functional level are owned by this product. We will identify in this chapter one more such important data set owned by this product.
Most enterprises have a multitude of data that they capture as part of their business transactions. To manage transactional capture of these data elements E-Business Suite has gathered most of the requirements and has more than what most enterprises would consider a data element that would need to be captured. However, the most will probably cover only 90 percent of the needs. This is a fact; it's just not a gap that can be completely covered. To compensate Oracle has allowed the facility to capture additional data in most of their transactional and master data entry forms. These are called Descriptive Flexfields (DFF) . They help to capture these additional data elements and these additional columns are built into the existing database tables and can be configured to capture whatever data you need.
There are a fixed number of columns depending on the transaction (between 7 to 15).
There is a concept of a driving field that can be used to manage what data is captured in these additional fields if needed. The driving field is called a Context Field , and the data capture can be context sensitive to enable an enormous flexibility in what you capture.
In addition to this functionality there is another flexfield component that Oracle E-Business Suite has deemed necessary to provide a flexible data capture environment. These are predefined flexfields that the system will use in its designed framework to capture and manage data. An excellent example of this is the Accounting Flexfield.
These are called Key Flexfields (KFF) due to the very reason that they are the key in the framework and processes that E-Business Suite will help manage for the user.
The name flexfield has been derived from the fact that these are made up of multiple segments (data columns) that are user defined. Here are a set of comparisons between Key and Descriptive Flexfields:
Predefined:
KFFs are predefined and have a specific use and are required to be set up for proper functioning of the E-Business Suite
DFFs are just additional pieces of data that are captured as needed
Structured:
Need a structure to be defined in each case (user defined)
This structure is limited to the number of columns in the database table that exists for each transaction
Both KFFs and DFFs can support multiple structures based on a data condition in your form or application data
Segmented:
Both KFFs and DFFs are segmented (think columns)
The number of segments is dependent on the transaction table
Value set:
KFFs must have value sets, but these are optional for DFFs and are driven by business needs
You have predefined value sets that can be used
Values:
Each DFF and KFF segment can have a set of values, when assigned to a value set
A Key Flexfield appears on a form as a normal text field with an appropriate prompt. A Descriptive Flexfield appears on your form as a two-character-wide text field with square brackets [ ] as its location on the form. When opened for data entry, both types of flexfields appear as a pop-up window that contains a separate field and prompt for each segment in use.
Note
This is configurable if you do not need to have the pop-up window appear each time. However, if you click on the List of Values (LoV) icon or the three-dots at the end of the field it will pop-up a window.
Each segment has a name and can have a set of valid values. The values may also have descriptions.
Note
There is another set of flexfields called Globalization Flexfields that are used for specific localization functionality within E-Business Suite and require additional configuration. The discussion of the specifics is outside the scope of this book.
A few examples of Key Flexfields in Oracle E-Business Suite finance modules with corresponding owners are shown in the following table:
|
Owners | |
|---|---|
|
Accounting Flexfield |
General Ledger |
|
Asset Key, Asset Location, and Category Flexfield |
Assets |
|
Territory and Sales Tax Location Flexfield |
Receivables |
|
Item Categories, System Items, Item Catalogs |
Inventory |
We will be using the Accounting Flexfield (AFF) as an example basis to demonstrate much of the details in this chapter. The AFF given later in this chapter is one that is used in the Vision Instance of Oracle E-Business Suite that is delivered with your installation by Oracle with a sample set of data that you can use as a sandbox for review and understanding functionality.
The vision installation has been the basis for most of the screens and examples in this book.
To configure a flexfield , the following four elements need to be set up:
Structure: A flexfield structure is a specific configuration of segments. As an example, different Accounting Flexfield (Chart of Accounts) structures can be defined in Oracle General Ledger for different ledgers if needed. The structure is made up of one or more than one segment.
Segment: A segment is a single subfield within a flexfield structure. You can define the appearance—display size, prompts, and assign a value set. You can also define if it is required and if any security is enabled, when defining the structure. A segment is represented in your database as a single table column.
Value set: A value set is defined to create a definition for the segment, such as the length, format type, including format definitions and validation type.
Validation types:
None: This value set has no list of approved values associated with it.
Independent: Independent type value sets perform basic checking but also check a value entered against the list of approved values you define.
Dependent: A dependent value set is associated with an independent value set. Dependent value sets ensure that all dependent values are associated with a value in the related independent value set.
Table : Table value sets obtain their lists of approved values from existing application tables. When defining your table value set, you specify a SQL query to retrieve all the approved values from the table.
Special: This specialized value set provides another flexfield as a value set for a single segment.
Pair: This specialized value set provides a range flexfield as a value set for a pair of segments.
Translatable independent: A translatable independent value set is similar to an independent value set in that it provides a predefined list of values for a segment. However, a translatable independent value set can contain display values that are translated into different languages.
Translatable dependent: A translatable dependent value set is similar to a dependent value set. The available values in the list and the meaning of a given value depend on which independent value was selected in a prior segment of the flexfield structure.
Values: Generally, the flexfield validates each segment against a set of valid values using a value set that defines the type of value, length, and min and max values. You can also have segments that have no predefined values.
There are additional aspects that are unique to the Key Flexfields that allow them to focus on functionality that is built into the design of the E-Business Suite. These are specifically important for the functionality and the capability to manage the quality of the data for a financial transaction. These aspects also manage to enforce accuracy in data capture and processing.
These help, if configured accurately, in managing to help the enterprise gather the financial data as required by the business and process and report on the resulting data sets with accuracy and adhering to GAAP rules.
Due to the fact that E-Business Suite is a packaged application and is expected to cater to the requirements of multiple businesses, there are some framework elements that enhance the functionality of the generic data capture facility. Some of these are described here in brief.
A qualifier is defined as an element that enhances or identifies a need to specifically note the use of a specific field/data set. In Oracle E-Business Suite segment qualifiers are used extensively to manage functionality within the system.
One of the most important ones is the segment qualifier (for the Accounting Flexfield).
We will discuss the segment qualifiers that are available and used as part of this flexfield.
The AFF has the following segment qualifiers:
Each segment qualifier is used by the system to process data in each case for a specific purpose.
The balancing segment is used by the system to ensure that a balanced trial balance report can be generated for a value in that segment.
The natural account segment has to be identified with additional tracking segments to identify—asset, income, expense, liability, and so on. Then the system will also automatically rollover the net balance of income and expense balances to the retained earnings account and zero out the balances when a new fiscal year begins as defined in the system.
These are predefined Key Flexfield qualifiers, and this manages to identify to the application that there is a special need for some activity to be performed based on these values.
Descriptive Flexfields used with the Accounting Flexfield segment qualified as a natural account identify usage for each value as follows:
Allow budgeting
Allow posting
Account type (Asset, Expense, Liability, Ownership/Stockholder's Equity, Income, and Revenue)
Reconcile
Third Party Control Account (Yes, No, Customer, Supplier, and Restrict Manual Journals)
The budgeting and posting qualifiers are available for all the AFF segments.
The Accounting Flexfield structure is made of multiple segments and each segment has valid values as per your configuration. When these segments are used together they create a combination (accounting flexfield combination). This happens normally when you are entering an accounting transaction such as a journal entry. Dynamic inserts for your Accounting Flexfield allow creating combinations as the transactions are entered. As long as values for each segment are valid the combination will be created.
This is an easy method to create combinations, but also allows inaccurate combinations to be created when a user inadvertently chooses the wrong set of values in each segment. The inaccuracy cannot be controlled by the system and is normally an error due to a business requirement.
To manage creating only accurate combinations you can either choose to not allow dynamic inserts, or use cross-validation rules (CV rules).
Cross-validation rules (CV rules ) are another level of functionality that allows you to use the segments and manage the combinations that get created when you use the segment values together in a transaction. The important point to understand is that the CV rules are only effective when the combinations are being created for the first time.
This is the reason that CV rules should be created when beginning an implementation and before creating any transactions that create accounting code combinations.
Another way to make sure that users do not create incorrect combinations is to use an alias. An alias is a label that you create for oft-used combinations. This way the users do not need to enter all the segment values (or remember what they should be). Another benefit is that with an alias you can also have specific segments blank so that a user can choose to fill them in as appropriate at the time of transaction entry.
Even if the alias has specific values defined these can be changed at the time of transaction entry.
One more functionality to manage transactional accuracy is to manage specific values that can be chosen by a user in a transaction. A security rule is built to allow access to a subset of values within the list of valid values for a specific "responsibility". It is important to note that when defining segment details there is a data element that controls if security rules can be used or not and this should have a value other than "No Security" for security rules to work.
There are multiple system entities that are in a generic fashion referred to as organizations in the applications suite. These however, have classifications that identify how they will be used and their effect on the configuration and usage.
The Oracle E-Business Suite includes the following important system entities:
Each system entity is assigned to a classification that determines its functionality and indicates how you might want to deploy it. These system entities sit at the highest level of the configuration basis in the suite and are shared across all the products within the E-Business Suite.
We will be focusing on the Operating Unit in this chapter. This is due to the fact that the Operating Unit (OU) provides the seemingly unique aspect of being able to segregate data within a ledger, legal entity, and business group.
The functionality that an OU provides, commonly referred to as multi-org, enables multiple business units in an enterprise to use a single installation of E-Business Suite Applications products while keeping transaction data separate and secure. This was first introduced in an earlier release (Release 10.4). Prior to this release this functionality required users to install multiple versions of the software to manage these segregations.
The segregations were managed by assigning a responsibility (or a role) to a user that secured data to an Operating Unit (OU). This allowed users to use a single installation of the applications suite and manage data segregation and transactional capability to specific areas within the enterprise. This has been enhanced to allow access to multiple organizations, called Multiple Organization Access Control (MOAC) , from within a single responsibility with Release 12.
Some of the modules that support the multi-org structure are:
The functionality secures access to data so that users can access only information that is relevant to them. You can also sell products from one Operating Unit that uses one primary ledger, but ship them from another Operating Unit using a different primary ledger, while automatically recording the appropriate intercompany accounting by posting intercompany accounts payable and accounts receivable transactions.
The multi-org model provides a hierarchy that can dictate how transactions flow through different business units and how those business units interact. In the next illustration, note the different shapes used for each organization type. The shapes are helpful when drawing multiple organization diagrams.
With E-Business Suite Applications accounting, distribution, and materials management functions, you define the relationships between inventory organizations, operating units, and ledgers to create a multi-level company structure. Each organization classified as a legal entity must specify a primary ledger to post accounting transactions. A legal entity points to one and only one primary ledger. An inventory organization is used to define, manage, and store items (products, parts list) and must reference an operating unit for sales and procurement transactions. In R12 an inventory organization can point to only one operating unit. Items are defined in the master inventory organization (master parts list) and added to the appropriate child inventory organizations for transactional purposes. This is explained in a little more detail in the Chapter 4, Inventory.
Multiple Organization Access Control (MOAC) is basically the ability to access multiple operating units from a single application responsibility. In prior releases, a single responsibility allowed access to process data only for one operating unit. If a user was managing Payables for Sweden, Norway, and Finland a user needed to have three different responsibilities to do their tasks.
Note
The operating unit is used to manage data in subledger products—as listed earlier—General Ledger does not use operating units to segregate data.
In Release 12 a security profile is used to assign multiple operating units as required. This security profile when assigned to a responsibility will grant access to multiple operating units. Given the example of a user above managing payables for Sweden, Norway, and Finland they could now manage all payables for these three countries from within a single responsibility. MOAC is not enabled and used for the iProcurement and iExpense modules.
Oracle E-Business Suite Release 12 provides significant enhancements to the Oracle E-Business Suite security system. This model is now called Oracle User Management and a depiction is shown in the following figure:
The Core Security now includes a Role Based Access Control (RBAC) model that builds on the existing function security (menu functions) and data security (OU access across subledgers, security rules in GL, project organization access in Oracle Projects, and so on) model. The function security is the base layer of access control in Oracle E-Business Suite. It restricts user access to individual menus and functions within the system, but does not restrict access to the data contained within those menus.
Data security is the next layer and builds on function security. This layer provides access related to the data that a user can access. Oracle E-Business Suite restricts access to individual data that is displayed on the screen once the user has selected a menu or menu option.
RBAC enables organizations to create roles (also called responsibilities as in previous releases) based on specific job functions and to assign these roles the appropriate permissions (a lower level access model than a responsibility). Access control is defined through roles, and user access to Oracle E-Business Suite is determined by the roles granted to the user. In Cash Management for example the RBAC functionality is used to grant access to a role (also called a responsibility) to a specific legal entity and that allows the bank account to be used for a given legal entity (and its related operating unit). For example, cash management security based on a legal entity uses RBAC for internal bank accounts.
Delegated administration is a privilege model that builds on the RBAC system to provide organizations with the ability to assign the required access rights for managing roles and user accounts. Administration privileges determine the users, roles, and organization information that delegated administrators can manage.
The registration processes enable organizations to provide end-users with a method for requesting various levels of access to the system. Based on their eligibility these access requests can be granted (approvals can also be managed before these grants are made).
Self-service requests and approvals enable end users to request initial access or additional access to the systems. Approvals for these requests can be managed systematically and tracked for audit purposes before the grant is made. Notifications can be generated to the requestor so that there is a seamless process to granting access.
Oracle E-Business Suite Release 12 introduces the Swan user interface, which has a browser look and feel.
To gain access to use the E-Business Suite the system administrator has to create a username and a password, and assign specific responsibilities to access functions in specific products.
Oracle E-Business Suite Release 12 can support multiple languages and the user can select a language of choice during the login process.
The access to each product is defined by a responsibility (also called a role). The following screenshot shows a personal home page with a list of responsibilities. The user clicks on a responsibility to access the available functions. Oracle provides default responsibilities that have access to all the functions and many enterprises may want to change this to manage SOX compliance issues.
In earlier R12 releases there used to be a three panel launch page. The responsibilities were listed on the left pane, the functions were displayed in the center pane, and favorites were listed in the right pane. This has changed in R12.1.3. You now have a two panel page and Favorites has been moved to a drop-down on the title bar.
The other major change in 12.1.3 is that the submenus and functions for a responsibility now show up in a cascade fall below the main responsibility pane. The favorites list now contains a mix of standard forms, web pages, and web links.
If you look at the icons on the favorites list, they tell a story. The icons on the first five Favorites link are standard forms explained a little later, called GUI forms. The next Favorite is a web link to an external site—Metalink—Oracle support site. The last two are web pages.
The following screenshot is a graphical user interface form also known as a GUI form, and referred to previously as a standard form. This user interface has been available and in use from release 10.7 GUI and is still prevalent in many cases.
This form is used in most places in the all products and has shortcut keys as shown in the box on the right-hand side of the previous screenshot.
The list of these shortcuts is another document in itself and there are other ease of use icons on the top as well as the menu bar. This is well documented in a paper presented to the OAUG in 2007. The paper is titled Wow, I Can do That in Oracle Applications! The paper was presented by me at the conference and is available in the conference papers database.
On the Oracle forms graphical user interface (GUI) form has shortcuts for navigation. These shortcut keys only work in the GUI form. This is invoked by using the Ctrl+K command (pressing the Ctrl and K keys together). These commands are used in general in combination with the Ctrl key, and this may be different in different environments, so you need to check at your particular environment.
In these forms you will see multiple ways in which data is presented—tabs that hold additional data sets (for capture and display) in the middle of the image, columns on the top of the form, and the scroll bar just above the tabs shows that there are more columns to the right.
Just above the columns on the left-hand corner you see a folder icon 
. This is an interesting functionality to allow users to manage how they see their columns laid out for ease of data entry. This is called Folder functionality and is useful to move, add, or remove the columns shown on the screen.
Note
You cannot add columns that are not inherently exposed by the applications framework. You can only choose columns from a predefined list.
The folder functionality is also described in detail in the paper referred to earlier.
The following is a screenshot of the new web page that is now used for some functions:
The users can click on the Preferences link on the web form and manage default preferences and options for their use. This is only for the user and is not system wide.
Here is a list of items that can be managed from the Preferences page:
default language
date format
time zone
number format
change password
notification email style
The Navigator link is visible form web forms and is similar to a change responsibility 
icon on the standard form. Clicking on the Navigator link will show a drop-down of available responsibilities to a user. You can go back to the home page by clicking on the Home link.
A Help link is available from various web forms and is similar to the 
icon on the standard form. This will open a new window where help documentation is available about the form and fields on the form or page. This requires some additional configuration and should be done by the person who is installing and administering the E-Business Suite.
In this chapter, you were introduced to an overview of the E-Business Suite and a little about how it works and some fundamentals to what makes it flexible and usable at multiple enterprises.
You learnt about the flexibility and uniqueness of flexfields, organizations, Multiple Organization Access Control (MOAC), and navigation.
In the following chapters we will introduce you to business process flows, Procure to Pay, and Order to Cash, delving deeper into each of the products that are used within these processes and highlighting unique aspects related to usage, configuration, and transactional areas.
