Fundamentals of Flexfields

Fundamentals of Flexfields

A flexfield is a field made up of sub-fields, or segments. A flexfield appears on your form as a pop-up window that contains a prompt for each segment. Each segment has a name and a set of valid values. There are two types of flexfields: key flexfields and descriptive flexfields.

Key Flexfields: Most organizations use "codes" made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. For example, your organization might use the part number PAD-NR-YEL-8 1/2x14" to represent a notepad that is narrow-ruled, yellow, and 8 1/2" by 14". Another organization may identify the same notepad with the part number "PD-8x14-Y-NR". Both of these part numbers are codes whose segments describe a characteristic of the part. Although these codes represent the same part, they each have a different segment structure that is meaningful only to the organization using those codes.

The Oracle Applications store these "codes" in key flexfields. Key flexfields are flexible enough to let any organization use the code scheme they want, without programming.

When your organization initially installs Oracle Applications, you and your organization's implementation team customize the key flexfields to incorporate code segments that are meaningful to your business. You decide what each segment means, what values each segment can have, and what the segment values mean. Your organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). You can also define relationships among the segments. The result is that you and your organization can use the codes you want rather than changing your codes to meet Oracle Applications' requirements.

For example, consider the codes your organization uses to identify general ledger accounts. Oracle Applications represent these codes using a particular key flexfield called the Accounting Flexfield. One organization might choose to customize the Accounting Flexfield to include five segments: company, division, department, account, and project. Another organization, however, might structure their general ledger account segments differently, perhaps using twelve segments instead of five. The Accounting Flexfield lets your Oracle General Ledger application accommodate the needs of different organizations by allowing them to customize that key flexfield to their particular business usage. See: the Oracle General Ledger User's Guide.


Descriptive Flexfields: Descriptive flexfields provide customizable "expansion space" on your forms. You can use descriptive flexfields to track additional information, important and unique to your business, that would not otherwise be captured by the form. Descriptive flexfields can be context sensitive, where the information your application stores depends on other values your users enter in other parts of the form.
A descriptive flexfield appears on a form as a single-character, unnamed field enclosed in brackets. Just like in a key flexfield, a pop-up window appears when you move your cursor into a customized descriptive flexfield. And like a key flexfield, the pop-up window has as many fields as your organization needs.
Each field or segment in a descriptive flexfield has a prompt, just like ordinary fields, and can have a set of valid values. Your organization can define dependencies among the segments or customize a descriptive flexfield to display context-sensitive segments, so that different segments or additional pop-up windows appear depending on the values you enter in other fields or segments.
For example, consider the Additions form you use to define an asset in your Oracle Assets application. This form contains fields to capture the "normal" information about an asset, such as the type of asset and an asset number. However, the form does not contain specific fields for each detail about a given asset, such as amount of memory in a computer or lifting capacity of a forklift. In this case, having all the potentially-needed fields actually built into the form is not only difficult, it is undesirable. Because while one organization may have computers and forklifts as assets, another organization may have only computers and luxury automobiles (and no forklifts) as assets. If the form contained built-in fields for each attribute of a forklift, for example, an organization with no forklifts would find those fields to be both unnecessary and a nuisance because a user must skip them to enter information about another type of asset. In fact, fields for forklift information would be cumbersome whenever a user in any organization tries to enter any asset that is not a forklift.
Instead of trying to contain all possible fields for assets information, the Additions form has a descriptive flexfield that you can customize to capture just the information your organization needs about your assets. The flexfield structure can depend on the value of the Asset Category field and display only those fields (segments) that apply to the particular type of asset. For example, if the asset category were "desk, wood", your descriptive flexfield could prompt for style, size and wood type. If the asset category were "computer, hardware", your flexfield could prompt for CPU chip and memory size. You can even add to the descriptive flexfield later as you acquire new categories of assets.
The Enter Journals window in the Oracle General Ledger applications is another example of a form that includes descriptive flexfields to allow organizations to capture additional information of their own choosing. Each block contains a descriptive flexfield as its last field. You might use these to store additional information about each journal entry, such as a source document number or the name of the person who prepared the entry.


Benefits of Flexfields: Flexfields provide you with the features you need to satisfy the following business needs:
1. Customize your applications to conform to your current business practice for accounting codes, product codes, and other codes.
2. Customize your applications to capture data that would not otherwise be tracked by your application.
3. Have "intelligent fields" that are fields comprised of one or more segments, where each segment has both a value and a meaning.
4. Rely upon your application to validate the values and the combination of values that you enter in intelligent fields.
5. Have the structure of an intelligent field change depending on data in your form or application data.
6. Customize data fields to your meet your business needs without programming.
7. Query intelligent fields for very specific information.

What is the distinction between flexfields and application features?
Flexfields, while they are a major feature of the Oracle Applications as a whole, are merely a mechanism to provide many application features. Key flexfields provide a flexible way for the Oracle Applications to represent objects such as accounting codes, part numbers, job descriptions, and more. For example, the Accounting Flexfield is a feature that uses a key flexfield to represent accounting codes throughout most of the Oracle Applications. Similarly, descriptive flexfields provide a flexible way for the Oracle Applications to provide customizable "expansion space" in forms, as well as a way to implement context-sensitive fields that appear only when needed. Both types of flexfield let you customize Oracle Applications features without programming.


Basic Flexfields Concepts

Segment:
- A segment is a single sub-field within a flexfield. You define the appearance and meaning of individual segments when customizing a flexfield. A segment is represented in your database as a single table column.

- For a key flexfield, a segment usually describes a particular characteristic of the entity identified by the flexfield. For example, you can have a key flexfield that stores part numbers. The key flexfield can contain the part number PAD-YEL-NR-8 1/2x14, which represents a yellow, narrow ruled, 8 1/2" x 14" note pad. Each section in the part number, separated by a hyphen, describes a characteristic of the part. The first segment describes the object, a note pad, the second segment describes the color of the object, yellow, and so on.

- Note that we also refer to the fields in a descriptive flexfield pop-up window as segments even though they do not necessarily make up meaningful codes like the segments in key flexfields. However, they do often describe a particular characteristic of the entity identified elsewhere on the form you are using.

Values, Validation and Value Sets:
- Your end user enters a segment value into a segment while using an application. Generally, the flexfield validates each segment against a set of valid values (a "value set") that are usually predefined. To "validate a segment" means that the flexfield compares the value a user enters in the segment against the values in the value set for that segment.
- You can set up your flexfield so that it automatically validates segment values your end user enters against a table of valid values. If your end user enters an invalid segment value, a list of valid values appears automatically so that the user can choose a valid value.
- You can think of a value set as a "container" for your values. You choose what types of values can fit into your value set: their length, format, and so on.
- A segment is usually validated, and usually each segment in a given flexfield uses a different value set. You can assign a single value set to more than one segment, and you can even share value sets among different flexfields. For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to the segment.

Structure:
- A flexfield structure is a specific configuration of segments. If you add or remove segments, or rearrange the order of segments in a flexfield, you get a different structure.
- You can define multiple segment structures for the same flexfield (if that flexfield has been built to support more than one structure). Your flexfield can display different prompts and fields for different end users based on a data condition in your form or application data. Both key and descriptive flexfields may allow more than one structure.
- In some applications, different users may need a different arrangement of the segments in a flexfield (key or descriptive). Or, you might want different segments in a flexfield depending on, for example, the value of another form or database field.
- Your Oracle General Ledger application, for example, provides different Accounting Flexfield (Chart of Accounts) structures for users of different sets of books. The Oracle General Ledger application determines which flexfield structure to use based on the value of the GL Set of Books Name user profile option.


Planning Flexfields: Just as for implementing any new application, planning is by far the most important (and probably the most time-consuming) phase of implementing flexfields, so you should give it careful thought. The planning phase can be broken into smaller, though still interrelated, steps:
1. Decide which flexfields to implement
2. Learning about a specific flexfield
3. Planning the structure
4. Planning the segments
5. Planning the segment validation
6. Planning to use additional features
7. Documenting your plan

Suggestion: We recommend that you plan your flexfields as completely as possible, including your potential segment values, before you even begin to define them using Oracle Applications forms. Once you begin using your flexfields to acquire data, you cannot change them easily. Changing a flexfield for which you already have data may require a complex conversion process.

Decide which flexfields to implement: Oracle Applications products rely on some key flexfields as central parts of the applications, so you must set up these key flexfields. For example, while the Oracle General Ledger products use only the Accounting Flexfield key flexfield, almost every Oracle Applications product uses the Accounting Flexfield for some part of its processing. So, you must almost always set up the Accounting Flexfield, especially if you have more than one of the Oracle Applications at your site. In addition, many Oracle Applications products such as Oracle Inventory and Oracle Purchasing use the System Items Flexfield (Item Flexfield). Other Oracle Applications use various key flexfields for various purposes, and defining those flexfields is usually mandatory for a particular application.

- While most Oracle Applications products require that you set up particular key flexfields, many descriptive flexfields are optional. You need only set up optional descriptive flexfields for forms where you want to capture business data not otherwise captured by the form fields.

Learning about a specific flexfield: Because each key and descriptive flexfield has a different purpose, you should be sure to understand the purpose and requirements for the flexfield you want to define. Some flexfields, particularly the Accounting Flexfield, have restrictions on how you can define them. Most descriptive flexfields simply provide a certain number of segment columns you can use for whatever you need to fill your organization's needs.


Defining:
- Defining your flexfield is easy once you have completed and documented your planning stage. You use Oracle Applications setup forms to define your flexfield.

Define your value sets: Depending on exactly how you want to validate your segments, you may spend 10-30 minutes defining each value set (roughly one value set per segment, or fewer if you plan to share value sets or do not plan to use value sets for certain segments).
Note that you do not define your actual values at this point; rather, you are simply defining the containers for your values.

Define your segment structures: This is the main part of defining a flexfield, and includes defining structure titles, segment prompts, segment order, and segment display sizes. Depending on the number of structures and segments you have, you may spend 20-90 minutes per flexfield.

Define your values, if necessary: Depending on exactly how you want to validate your segments, you may spend anywhere from 1-3 minutes defining each independent or dependent value in an Oracle Applications form. If you have legacy systems, you may need to build a program to import your legacy values into Oracle Applications tables.

Define additional features, if necessary: If you plan to use additional features such as cross-validation rules or flexfield value security, you define those additional features at this point.


Data Entry and Ongoing Maintenance: Data entry consists of using your applications for your day-to-day operations. For key flexfields, you may want to predefine the complete codes (combinations of segment values) you want to allow your users to enter.

- As your organization's needs change, you will need to perform ongoing maintenance of your flexfields. For example, you may need to define new flexfield structures or disable old structures. You may also need to add new values or cross-validation rules or value security rules.


Intelligent Key: An intelligent key is a code made up of sections, where one or more parts may have meaning. An intelligent key "code" uniquely identifies an object such as an account or a part or a job. Intelligent keys are useful in applications because they are usually easier for a user to remember and use than a unique number. For example, a part number of PAD-YEL-11x14 is much easier to remember than a unique part number of 57494. However, unique ID numbers are easier to maintain in a relational database application because only one column is required for the ID number, while multiple columns would be required for an intelligent key (one for each section or segment of the code). The Oracle Applications use key flexfields to represent intelligent keys with unique ID numbers. That is, an end user sees and works with an easy-to-remember intelligent key code, while the Oracle Applications only need to store a hidden unique ID number in most tables.

Attention: Throughout this guide we use the "Part Number Key Flexfield" in our examples and graphics. We use this example because it helps to illustrate the uses and behaviors of key flexfields without requiring any specialized accounting, human resources, or manufacturing knowledge. However, there is no actual "Part Number Key Flexfield" in the Oracle Applications, and you should not confuse it with the System Items Flexfield (Item Flexfield) used by many Oracle Applications products such as Oracle Inventory.


Combination: A combination is a particular complete code, or combination of segment values that makes up the code, that uniquely identifies an object. For example, each part number would be a single combination, and if you had ten parts you would define ten combinations. A valid combination is simply a combination that may currently be used (that is, it is not out of date or disabled).

- Note that many of the Oracle Applications products (and their documentation) do not necessarily refer to key flexfield combinations as "combinations". They may refer to combinations using the name of the entity or the key flexfield itself. For example, Oracle Assets uses a key flexfield called the "Asset Key Flexfield" and refers to one of its combinations as "an asset key" or "an asset key flexfield". In another example, Oracle General Ledger and other Oracle Applications products generally use the term "account" or "GL account" to refer to combinations of the Accounting Flexfield.


Combinations Table: Each key flexfield has one corresponding table, known as the combinations table, where the flexfield stores a list of the complete codes, with one column for each segment of the code, together with the corresponding unique ID number (a code combination ID number or CCID) for that code. Then, other tables in the application have a column that stores just the unique ID for the code. For example, if you have a part number code, such as PAD-YEL-11x14, the "Parts" combinations table stores that code along with its ID, 57494. If your application allows you to take orders for parts, you might then have an "Orders" table that stores orders for parts. That "Orders" table would contain a single column that contains the part ID, 57494, instead of several columns for the complete code PAD-YEL-11x14.

Flexfield Qualifier: A flexfield qualifier identifies a particular segment of a key flexfield.
Usually an application needs some method of identifying a particular segment for some application purpose such as security or computations. However, since the a key flexfield can be customized so that segments appear in any order with any prompts, the application needs a mechanism other than the segment name or segment order to use for segment identification. Flexfield qualifiers serve this purpose. You can think of a flexfield qualifier as an "identification tag" for a segment.

For example, your Oracle General Ledger product needs to be able to identify which segment in the Accounting Flexfield contains balancing information and which segment contains natural account information. Since you can customize the Accounting Flexfield so that segments appear in any order with any prompts, Oracle General Ledger needs the flexfield qualifier to determine which segment you are using for natural account information. When you define your Accounting Flexfield, you must specify which flexfield qualifiers apply to which segments.
Other applications, such as Oracle Human Resources, also use flexfield qualifiers. Oracle Human Resources uses flexfield qualifiers to control who has access to confidential information in flexfield segments.
A segment qualifier identifies a particular type of value in a single segment of a key flexfield. In the Oracle Applications, only the Accounting Flexfield uses segment qualifiers. You can think of a segment qualifier as an "identification tag" for a value. In the Accounting Flexfield, segment qualifiers can identify the account type for a natural account segment value, and determine whether detail posting or budgeting are allowed for a particular value.
It is easy to confuse the two types of qualifiers. You should think of a flexfield qualifier as something the whole flexfield uses to tag its pieces, and you can think of a segment qualifier as something the segment uses to tag its values.


Types of Key Flexfield Forms: Key flexfields appear on three different types of application form:
1. Combinations form
2. Foreign key form
3. Range form
These form types correspond to the types of tables that contain key flexfield data.

1. Combinations form: A combinations form is a form whose only purpose is to maintain key flexfield combinations. The base table of the form is the actual combinations table. This table is the entity table for the object (a part, or an item, an accounting code, and so on). The form contains hidden fields for each segment column in the table, as well as displayed fields for the concatenated segment values (the combination) and any other fields (and columns) that the entity requires. A combinations form is sometimes also called a maintenance form.

Foreign key form: A foreign key form is a form whose underlying base table contains only one or two columns that contain key flexfield information. The purpose of a foreign key form often has very little to do with the key flexfield itself, and that the key flexfield appears on the form is essentially incidental. For example, if you have a key flexfield that represents a part number, you would use the combinations form to define new parts and maintain existing part numbers. You would then have many foreign key forms that you use to manipulate your parts. You might have a form where you take orders for parts, another form where you receive parts, and yet another form where you ship parts. The fact that your part number happens to be a key flexfield is not important to your taking orders for your parts.

Range form:
- A range form displays a range flexfield, which is a special pop-up window that contains two complete sets of key flexfield segments. A range flexfield supports low and high values for each key segment rather than just single values. Ordinarily, a key flexfield range appears on your form as two adjacent flexfields, where the leftmost flexfield contains the low values for a range, and the rightmost flexfield contains the high values. A user would specify a range of low and high values in this pop-up window. For example, you might choose a range of part numbers for which you want to run a report.

- The range form uses a special table as its base table. This table contains one or more (usually two) columns for each segment column that appears in the combinations table. However, these columns do not necessarily contain actual segment values, and a row in the table does not necessarily contain actual valid combinations. Usually this table contains two columns for each segment, called SEGMENTn_LOW and SEGMENTn_HIGH (where n is the segment column number), that store the range of values for each segment.

- In Oracle Applications, we use a key flexfield range to help you specify cross-validation rules for key flexfield combinations.

- Some forms use a variation of a range flexfield to capture information for each key flexfield segment that is not necessarily a segment value. For example, the form might capture a "Yes" or "No" value for each segment (the Assign Function Parameters form displays a pop-up flexfield window where you choose Yes or No to specify whether you want to assign a value to each particular segment).

Dynamic insertion: Dynamic insertion is the insertion of a new valid combination into a combinations table from a form other than the combinations form. If you allow dynamic inserts when you set up your key flexfield, a user can enter a new combination of segment values using the flexfield window from a foreign key form. Assuming that the new combination satisfies any existing cross-validation rules, the flexfield inserts the new combination into the combinations table, even though the combinations table is not the underlying table for the foreign key form.

- For some key flexfields, dynamic inserts may not be allowed. Sometimes it may not make sense for an application to allow a user to be able to create a new combination from any form other than the combinations form. For example, a user should not be able to create a new part while taking an order for parts using an Enter Orders form; the application should restrict the creation of new part numbers to authorized users using a Create Parts form.

- Dynamic inserts may not be technically possible for some key flexfields. If the combinations table contains mandatory columns that are not maintained by the flexfield, dynamic inserts would not be possible. If the combinations table contains mandatory non-flexfield columns, such as a "unit of measure" column, the flexfield would not be able to complete the entire row in the combinations table from the foreign key form (because the base table of the foreign key form is not the combinations table). The flexfield does maintain the CCID column.

- Generally there is only one, if any, combinations form for a given key flexfield. In some applications, there may not be a combinations form. In these cases, you would use dynamic inserts to create new combinations.


Overview of Values and Value Sets:
Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables.
When you first define your flexfields, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values.
You define your value sets first, either before or while you define your flexfield segment structures. You typically define your individual values only after your flexfield has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your flexfield.
You can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. You can share value sets across key and descriptive flexfields. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.
Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right-Justify Zero-fill set to Yes.
Remember that different flexfields may have different requirements and restrictions on the values you can use, so you should read information for your specific flexfield as part of your value planning process. For example, the Accounting Flexfield requires that you use certain types of value sets.


Planning Values and Value Sets: To plan values and value sets:
1. Choose a format for your values. Choosing Value Formats.
2. Decide whether your segment should have a list of values. Decide What Your User Needs.
3. Choose an appropriate validation type for your segment. Choosing a Validation Type for Your Value Set.
4. Consider using values that group neatly into ranges so that using range-based features (value security, value hierarchies, and so on) will be easier. Plan Values to Use Range Features.
5. Plan both values and descriptions as appropriate.
6. Plan any value hierarchies, cross-validation rules, value security rules, and so on as appropriate.


Defining Values and Value Sets
1. Prerequisites
- Plan your flexfield structures and segments.
- Thoroughly plan your values and value sets. Planning Values and Value Sets.

2. To define values and value sets:
1. Navigate to the Value Sets window.
2. Define your value set. Defining Value Sets.
3. Define your values. Defining Segment Values.


Relationship Between Independent and Dependent Values: Independent and dependent value sets have a special relationship. While you can have the same dependent values for any of your independent values, the meanings (or descriptions) - as well as any segment qualifier values, enabled/activation information and descriptive flexfield data for that value - of the dependent values depend on which of the independent values you choose in the prior independent segment.

You must set up your independent-dependent value sets carefully using the following sequence: - Create your independent value set first
- Create your dependent value set, specifying a default value
- Define your independent values
- Define your dependent values

When you define each of your independent values, Oracle Applications automatically creates a default dependent value that goes with your independent value. For example, the previous diagram shows a default value of zero (0). If for some reason you create a dependent value set after your independent value set has values, you must manually create a default value in your dependent set for each of your independent values, since each independent value must have a default dependent value. If necessary, create your default dependent values manually using the Segment Values form (you also use this form to create all dependent values other than the default value). You must create at least one dependent value for each independent value, or else your user will be unable to enter segment value combinations in the flexfield. However, we recommend that you carefully follow the above order for creating your value sets so that you never have to create default dependent values manually, since manually creating default dependent values is both tedious and error-prone.

"Dependent" Values with Table Validation: Flexfields uses a special mechanism to support table-validated segments whose values depend on the value in a prior segment (a different mechanism from that used for independent value sets with dependent value sets). You can use flexfield validation tables with a special WHERE clause (and the $FLEX$ argument) to create value sets where your segments depend on prior segments. You can make your segments depend on more than one segment (cascading dependencies). However, you cannot use parent value/child value features with these value sets, nor can you use this mechanism with the Accounting Flexfield.


Parent and Child Values and Rollup Groups :Only Oracle General Ledger and Oracle Public Sector General Ledger use these features, and only with the Accounting Flexfield. Parent and child value sets have a relationship different from the relationship between independent and dependent values.
- You can use a rollup group to identify a group of parent values for reporting or other application purposes. You assign key flexfield segment values to rollup groups.

Implementing Table-Validated Value Sets:
Table-validated value sets let you use your own application tables as value sets for flexfield segments and report parameters instead of the special values tables Oracle Applications provides. You need not enter each value manually using the Segment Values window. Value sets you base on validation tables can be similar to Independent value sets, where values in your Table type value sets are independent of the values in all other segments. Or, depending on how you define your validation table's WHERE clause, they can depend on one or more previous segments in your flexfield.
In general, you should use a validation table if you want a key or descriptive flexfield segment, or report parameter, to use values that your application already requires or maintains for other application purposes. Using a validation table then lets you avoid maintaining two copies of the same values (one in your application's table and the other in Oracle Application Object Library's tables).
You can use many advanced features with your table-validated value sets. You can use validation tables for flexfield segments or report parameters whose values depend on the value in a prior segment. You use flexfield validation tables with a special WHERE clause (and the $FLEX$ argument) to create value sets where your segments depend on prior segments. You can make your segments depend on more than one segment, creating cascading dependencies. You can also use validation tables with other special arguments to make your segments depend on profile options or field values.
If you want to make use of key flexfield features such as rollup groups and parent-child relationships, you can store the child values in your validation table, but you should use the Segment Values windows Oracle Applications provides to add or define the parent values and rollup groups.

Implementing a validation table:
1. Create or select a validation table in your database. You can use any existing application table, view, or synonym as a validation table. Defining Your Validation Table.
2. Register your table with Oracle Application Object Library (as a table). You may use a non-registered table for your value set, however. If your table has not been registered, you must then enter all your validation table information in this region without using defaults.
3. Create the necessary grants and synonyms. Creating Grants and Synonyms for Your Table.
4. Define a value set that uses your validation table. Defining Value Sets.
5. Define your flexfield structure to use that value set for a segment. You can use the same table for more than one value set, using different SQL WHERE clauses to limit which values are used for flexfield and report parameter validation. For example, if you wish to validate different segments against different rows of the same table, you would use the same table twice but select different rows of the table for each value set by using different SQL WHERE clauses.

Warning: You should not use any WHERE clause and/or ORDER BY clause at all for a value set you intend to use with the Accounting Flexfield.

In general, you may use a WHERE clause and/or an ORDER BY clause for validation tables you intend to use with key flexfields other than the Accounting Flexfield.

Attention: If you need a complex SQL clause to select your values from a table, you should instead first define a view over the table which selects the rows you need, and then define the value set over the view.
WHERE Clauses and Bind Variables for Validation Tables for detailed information on using WHERE clauses with special bind variables.

Using hidden ID columns with value sets: If you specify a hidden ID column in addition to your value column, the flexfield saves your hidden ID value, instead of the value from the value column, in the segment column (in your ATTRIBUTEnn column or SEGMENTnn column) of the underlying flexfield table.
Generally, you use value sets with hidden ID columns only for report parameters. You would not normally use them for most key flexfields. In fact, most key flexfields prevent you from using a value set with a hidden ID column by not displaying those value sets in the list of values you use to assign a value set to a segment.

Attention: You should not specify a hidden ID column for value sets you use with your Accounting Flexfield or most other key flexfields.

- If you specify a hidden ID column in addition to your value column, the report parameter window passes your hidden ID value, instead of the value from the value column, to your report.
- Table validated value sets using the "Standard Date" or "Standard DateTime" formats cannot use the ID column.

- Using multiple tables in a single value setFor value sets that use multiple tables, you should always include the table aliases with your all your column names. You must enter the column name directly, since your list of values cannot retrieve any column names for a "table name" that is not a registered single table. For example, you might enter: f.column_name

- For value sets that use multiple tables, you can and should leave the Table Application field blank, since it is effectively ignored in this case. You enter the table names and aliases you want in the Table Name field. Then, you enter the Value Column and Description Column column names directly, with table aliases, since your list of values cannot retrieve any column names for a "table name" that is not a registered single table.

- Displaying additional columns in your list of valuesYou can design your value set to display several columns in the segment value or report parameter value list of values, and these columns may be in different tables. If all your columns exist in the same table, you simply list the additional columns in the Additional Columns field. If your columns exist in different tables, you must specify more than one table name in the Table Name field. You should always use table names or aliases with your column names for your Additional Columns and WHERE clause.
Finally, you can enter the names of the extra columns you want, with their table aliases, in the Additional Columns field. You can specify column widths to display.

- In some cases you may want to use a SQL expression instead of specifying a single column name. For example, you may want to use a DECODE statement instead of a simple column name, such as:
DECODE(FORM.FORM_NAME, 'OEDEOR', 'Enter Orders', 'Not available')
or
DECODE(FORM.FORM_ID, 1234, 1234, NULL)

- You can also use message names as alias names; this functionality allows for ease of translation of column titles. The syntax for using a message name as an alias name is:
E_FLAG "APPL=;NAME="(width)


Cross-Validation Rules A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.

What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.
You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".


Planning Your Descriptive Flexfield: When you are planning your flexfields, you should consider the following questions and their corresponding decisions:
1. Do you want to capture information that is not otherwise captured by the form? If yes, you define this descriptive flexfield. If no, you need not define this descriptive flexfield at all.
2. Do you want to capture the same information every time, regardless of what other data appears in the form? If yes, you need to define global segments.
3. Do you want to capture certain information sometimes, depending on what other data appears in the form? If yes, you need to define context-sensitive segments.
4. If you want context-sensitive segments, do you want to have the form automatically determine which descriptive flexfield structure to display based on the value of a field somewhere on the form? If yes, you need to define a reference field (note that some descriptive flexfields do not provide reference fields).
5. If you want context-sensitive segments, do you want to have the user determine which descriptive flexfield structure to display by choosing a value in a field inside the pop-up window? If yes, you need to define a context field.
6. How do you want to break down reporting on your descriptive flexfield data? If you want to report on your data by certain criteria or sub-entities, such as account number or project or region, you may want to consider making that sub-entity a distinct segment, rather than combining it with another sub-entity, so that you can categorize and report on smaller discrete units of information.
7. How often does your organization change? This would affect how you set up your values. For example, if you disable old cost centers and enable new ones frequently, you would "use up" cost center values quickly. You would therefore want to use a larger maximum size for your cost center value set so that you can have more available values (for example, you have 999 available values for a 3-character value set instead of 100 available values for a 2-character value set).
8. Do you want to require a value for each segment?


Descriptive Flexfield Concepts:
- Descriptive flexfield segmentsDescriptive flexfields have two different types of segments, global and context-sensitive, that you can decide to use in a descriptive flexfield structure.
A global segment is a segment that always appears in the descriptive flexfield pop-up window, regardless of context (any other information in your form). A context-sensitive segment is a segment that may or may not appear depending upon what other information is present in your form.

- Context-sensitive segmentsIf you have context-sensitive segments, your descriptive flexfield needs context information (a context value) to determine which context-sensitive segments to show. A descriptive flexfield can get context information from either a field somewhere on the form, or from a special field (a context field) inside the descriptive flexfield pop-up window. If the descriptive flexfield derives the context information from a form field (either displayed or hidden from users), that field is called a reference field for the descriptive flexfield.

- A context field appears to an end user to be just another segment, complete with its own prompt. However, a context field behaves differently from a normal flexfield segment (either global or context-sensitive). When a user enters a context value into the context field, the user then sees different context-sensitive segments depending on which context value the user entered. You define a context field differently as well. You use a context field instead of a reference field if there is no form field that is a suitable reference field, or if you want your user to directly control which context-sensitive segments appear.

- A context-sensitive segment appears once the appropriate context information is chosen. The context-sensitive segments may appear immediately if the appropriate context information is derived from a form field before the user enters the descriptive flexfield.

- For a descriptive flexfield with context-sensitive segments, a single "structure" consists of both the global segments plus the context-sensitive segments for a particular context field value. That is, a structure consists of all the segments that would appear in the pop-up window at one time (after the structure has been chosen).


Planning Your Key Flexfield: Your first step in planning your key flexfields is to determine which key flexfields your Oracle Applications product requires. You should also determine the purpose of the key flexfield, as well as the number and length of its available segment columns ( Key Flexfields in Oracle Applications). You should also note whether your key flexfield allows more than one structure, and determine if you do indeed need to define more than one structure. For example, the System Items Flexfield (Item Flexfield) supports only one structure.

- Those key flexfields that allow multiple structures may use different mechanisms to determine which structure a user sees. For example, the Accounting Flexfield uses multiple structures if you have multiple sets of books with differing charts of accounts. Your forms determine which Accounting Flexfield structure to display by using the value of the GL_SET_OF_BOOKS_ID profile option associated with your current responsibility. Other key flexfields may have a field built into the form that allow a user to essentially choose which structure appears.

- You should decide on the number, order and length of your segments for each structure. You must also choose how to validate each segment. See: Overview of Values and Value Sets.
When you are planning your flexfields, you should consider the following questions and their corresponding decisions:

1. How do you want to break down reporting on your key flexfield data? If you want to report on your data by certain criteria or sub-entities, such as account number or project or region, you may want to consider making that sub-entity a distinct segment, rather than combining it with another sub-entity, so that you can categorize and report on smaller discrete units of information.

2. How often does your organization change? This would affect how you set up your values. For example, if you disable old cost centers and enable new ones frequently, you would "use up" cost center values quickly. You would therefore want to use a larger maximum size for your cost center value set so that you can have more available values (for example, you have 1000 available values for a 3-character value set instead of 100 available values for a 2-character value set).

3. Do you want to require a value for each segment?