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.