Oracle Applications provides many key flexfields, such as the Accounting Flexfield, Location Flexfield and System Items Flexfield. In this essay, we use the Accounting Flexfield to present suggestions for designing your cross-validation rules, but you can use cross-validation rules for any key flexfield structure that has cross-validation enabled.
Use the Key Flexfield Segments window to define your flexfield structure and segments and specify Yes in the Cross-Validate Multiple Segments field for your flexfield structure.
To define cross-validation rules:

  1. Select the name and structure of your key flexfield for which you wish to define cross-validation rules. Your list only contains structures with the field Cross-Validate Multiple Segments set to Yes on the Key Flexfield Segments window.
  2. Enter a unique name and a description for your cross-validation rule.
  3. Enter your error message text for this cross-validation rule.                                                                                  Your flexfield automatically displays this error message on the message line whenever a new combination of segment values violates your cross-validation rule. You should make your error messages as specific as possible so that your users can correct any errors easily.
  4. Enter the name of the segment most likely to have caused this cross-validation rule to fail. Your flexfield leaves the cursor in this segment whenever a new segment combination violates this cross-validation rule to indicate where your user can probably correct the error. If you do not specify an error segment name, your flexfield leaves the cursor in the first segment of the flexfield window following a violation of this rule.
  5. If you want to have the rule effective for a limited time, you can enter a start date and/or an end date for the rule. The rule is valid for the time including the From and To dates.
  6. Define the cross-validation rule elements that make up your rule. See: Defining Cross-validation Rule Elements.
  7. Save your changes.


Defining Cross-validation Rule Elements

Use this block to define the cross-validation rule elements that make up your cross-validation rule. You define a cross-validation rule element by specifying a value range that includes both a low and high value for each key segment. A cross-validation rule element applies to all segment values included in the value ranges you specify. You identify each cross-validation rule element as either Include or Exclude, where Include includes all values in the specified ranges, and Exclude excludes all values in the specified ranges. Every rule must have at least one Include rule element, since a rule automatically excludes all values unless you specifically include them. Exclude rule elements override Include rule elements.
 Suggestion: We recommend that you define one all-encompassing Include rule element and several restricting Exclude rule elements.
Select the type of cross-validation rule element. Valid types are:
Include     Your user can enter any segment value combinations that fall in the following range.
Exclude     Your user cannot enter any segment value combinations that fall in the following range.
When you enter the From (low) field, this window automatically displays a window that contains a prompt for each segment in your flexfield structure. You enter both the low and high ends of your value range in this window. After you finish entering your ranges, this zone displays your low segment values in concatenated window in the Low field and displays your high segment values similarly in the High field.
Enter the low end and the high end of your segment combination range. Neither the low nor the high combination has to be a valid key flexfield combination, nor do they need to be made up of valid segment values.
Note that a blank segment value (null value) is considered to fall within a range that has one or both ends specified as a blank. However, if all of your segments require a value, you would not be able to create a combination with a blank segment anyhow.
You may use blank minimum or maximum segment values to create cross-validation rules that can test for blank segments (that are not already required to have a value). For example, if you allow a null value for your last optional segment but not the second-to-last optional segment, you would use a blank minimum or maximum value for the last segment but fill in a value (such as 000 or 999) for both the minimum and maximums for the second-to-last optional segment.
If you want to specify a single combination to include or exclude, enter the same combination in both the Low and High fields.
Disabled rules are ignored when your key flexfield validates a combination of segment values. Deleting the rule has the same effect, but you can re-enable a disabled rule.

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”.

As another example, if you use the Accounting Flexfield, you may decide that all revenue accounts must have a department. Therefore, all your “revenue” account values (such as all values between 4000 and 5999) must have a corresponding department value other than 000 (which means “non-specific”).

For example, suppose you have an Accounting Flexfield where you have a Company or Organization segment with two possible values, 01 and 02. You also have a Natural Account segment, with many possible values, but your company policy requires that Company or Organization 01 uses the natural account values 001 to 499 and Company or Organization 02 uses the natural account values 500 to 999. You can create cross-validation rules to ensure that users cannot create a GL account with combinations of values such as 02-342 or 01-750, for example.

The value sets you define using these windows appear in lists of values you see when you define flexfield segments using the Key Flexfield Segments window or the Descriptive Flexfield Segments window. If you are defining reports that your users run from the Submit Requests window, use this window to define value sets for your report arguments. The value sets you define using this window also appear when you define report parameters using the Concurrent Programs window.

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 share value sets with parameters for your concurrent programs that use the Standard Request Submission feature. Many Oracle Applications reports use predefined value sets that you may also use with your flexfield segments. However, any changes you make to a value set also affect all requests and segments that use the same value set.
This window prevents you from changing the validation type or format type of an existing value set because your changes affect other flexfields that use the same value set. In addition, other changes may affect the values in your value set in ways other than you expect. You cannot delete a value set that a flexfield or parameter currently uses. If you make any changes to your value set after you have used your flexfield or concurrent program that uses this value set, you must either change responsibilities or exit to the operating system and log back in before you can see your changes take effect.
1. List Type
Choose List of Values if your value set should not provide the LongList feature in Oracle Forms applications. A user will not see a poplist in Oracle Self–Service applications.
Choose Long List of Values if your value set should provide the LongList feature in Oracle Forms Applications. The LongList
feature requires a user to enter a partial segment value before the list of values retrieves all available values. You may not enable LongList for a value set that has a validation type of None.
A user will not see a poplist in Oracle Self–Service applications. Choose Poplist if your value set should not provide the LongList feature in Oracle Forms applications, but should provide a poplist in Oracle Self–Service applications.
Here are guidelines for the List Type field:

  •  Poplist – fewer than 10 values expected
  •  List of Values – between 10 and 200 values expected
  •  Long List of Values – more than 200 values expected

2. Security Type
Specify the Security Type you plan to use with any segments that use this value set. Security does not apply to value sets of validation type None, Special, or Pair.
Note: Flexfield value security is not available for Translatable Independent and Translatable Dependent value sets.
The possible security types are:

  • No Security – All security is disabled for this value set.
  • Hierarchical Security – Hierarchical security is enabled. With hierarchical security, the features of value security and value hierarchies are combined. With this feature any security rule that applies to a parent value also applies to its child values.Warning: Within a hierarchical tree of values, a value is subject to a security rule if any parent above it is subject to that security rule.
  • Non-Hierarchical Security – Security is enabled, but the rules of hierarchical security do not apply. That is, a security rule that applies to a parent value does not ”cascade down” to its child values.

3. Format Type
Enter the type of format you want to use for your segment values. Valid choices include: Char, Date, DateTime, Number, Standard Date, Standard DateTime, and Time.

Note: Translatable Independent and Translatable Dependent value sets must have the Char format
 

4. Validation types

There are several validation types that affect the way users enter and use segment or parameter values:
• None (not validated at all)
• Independent
• Dependent
• Table
• Special (advanced)
• Pair (advanced)
• Translatable Independent
• Translatable Dependent
None
You use a None type value set when you want to allow users to enter any value so long as that value meets the value set formatting rules. That is, the value must not exceed the maximum length you define for your value set, and it must meet any format requirements for that value set. For example, if the value set does not allow alphabetic characters, your user could not enter the value ABC, but could enter the value 456 (for a value set with maximum length of three). The
values of the segment using this value set are not otherwise validated, and they do not have descriptions.
Because a None value set is not validated, a segment that uses this value set does not provide a list of values for your users. A segment that uses this value set (that is, a non–validated segment) cannot use flexfield value security rules to restrict the values a user can enter.
Independent
An Independent value set provides a predefined list of values for a segment. These values can have an associated description. For example, the value 01 could have a description of ”Company 01”. The meaning of a value in this value set does not depend on the value of any other segment. Independent values are stored in an Oracle Application Object Library table. You define independent values using an Oracle Applications window, Segment Values.

Table
A table–validated value set provides a predefined list of values like an independent set, but its values are stored in an application table. You define which table you want to use, along with a WHERE cause to limit the values you want to use for your set. Typically, you use a table–validated set when you have a table whose values are already maintained in an application table (for example, a table of vendor names maintained by a Define Vendors form). Table validation also provides some advanced features such as allowing a segment to depend upon multiple prior segments in the same structure.
Dependent
A dependent value set is similar to an independent value set, except that 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. You can think of a dependent value set as a collection of little value sets, with one little set for each independent value in the corresponding independent value set. You must define your independent value set before you define the dependent value set that depends on it. You define dependent values in the Segment Values windows, and your values are stored in an Oracle Application Object Library table
Special and Pair Value Sets
Special and pair value sets provide a mechanism to allow a ”flexfield–within–a–flexfield”. These value sets are primarily used for Standard Request Submission parameters. You do not generally use these value sets for normal flexfield segments.
Special and Pair value sets use special validation routines you define. For example, you can define validation routines to provide another flexfield as a value set for a single segment or to provide a range flexfield as a value set for a pair of segments.
Translatable Independent and Translatable Dependent
A Translatable Independent value set is similar to Independent value set in that it provides a predefined list of values for a segment. However, a translated value can be used. A Translatable Dependent value set is similar to Dependent value set in
that 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. However, a translated value can be used.

Rollup Group is a collection of Parent values for a given segment.
To be used in a rollup group there are a few requirements:
1.  The value MUST be a Parent value.
2.  The Parent Value MUST contain Child values.
3.  The Parent and Child Values MUST belong to the same Value Set.

Users can summarize on any information in any segment using Rollup Groups.
To define rollup groups
1. Enter a code for your rollup group. The code is required and used internally.
2. Enter a name and description for your rollup group.
3. Save your changes.
4. Apply your rollup group name to particular values using the Segment Values window

Use the above window to define rollup groups to which you can assign key flexfield 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 using the Segment Values window.
In Oracle Applications, only the Accounting Flexfield uses rollup groups. Rollup groups are used to create summary accounts for reporting purposes.

Use this window to define valid values for a key or descriptive flexfield segment or report parameter. You must define at least one valid value for each validated segment before you can use a flexfield. These validated segments provide users with a list of predefined valid segment values, and have a validation type of Independent, Dependent, Translatable Independent, Translatable Dependent, or Table.
You should use this window to define values that belong to Independent, Dependent, Translatable Independent, Translatable Dependent, or Table value sets. You can define new segment values, specify value descriptions for your values and to enable or disable existing values as well.

1. The values you define for a given flexfield segment automatically become valid values for any other flexfield segment that uses the same value set. Many Oracle Applications reports use predefined value sets that you may also use with your flexfield segments.
2. If your flexfield segment uses a value set associated with a Standard Request Submission report parameter, creating or modifying values also affects that parameter. If you use the same value set for parameter values, the values you define here also become valid values for your report parameter.
3. You also specify segment value qualifiers, rollup groups, and child value ranges.
You can also view and maintain segment value hierarchies for the Accounting Flexfield or for any custom application flexfields that use the value hierarchies feature.
Attention: Because the Accounting Flexfield is the only Oracle Applications key flexfield that uses the parent, rollup group,hierarchy level and segment qualifier information, you need only enter this information for values that are associated with your Accounting Flexfield.
4. For certain types of changes to value hierarchies, a concurrent request is submitted to rebuild the value hierarchies. One request per value set that the change affects (the value set attached to the segment for which you are defining or maintaining values) may be submitted. For example, if you make hierarchy structure changes for five different key
flexfield segments, all of which use different value sets, up to five concurrent requests may be submitted.
A concurrent request is submitted for the following changes to value hierarchies:
• A new hierarchy range is defined, or an existing hierarchy range is updated or deleted.
• A hierarchy range is moved to another value.
• The value definition for non–parent values is updated in some way. For example, the description is changed.