, , , ,

Value Set Windows

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.

/by
, , , ,

Segment Values Window

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.
/by
, , , ,

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.
/by
, , , , ,

Flexfields 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, such as PAD–YEL–11×14 or 01–COM–876–7BG–LTN (where the dash ”–” is the segment separator). 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). A combination would have different segments depending on the flexfield structure being used for that combination. Any combination is associated with only one particular flexfield structure (arrangement of segments).
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–11×14, 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–11×14.

/by
, , , , ,

Basic Flexfields Concepts – Structure, Segment and Qualifiers

We use the following terms for both key and descriptive flexfields:

  1. Structure, Segment & Qualifier
  2. Value (Parent, Group, Hirearchy & Qualifier) , Value Description & Value Set
  3. Security Rule, Cross-Validation & Alias

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.
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.
You must choose two lengths for each segment, the displayed length and the maximum length. The maximum length is the length of the longest value a user can enter into a segment. The largest maximum length you can choose must be less than or equal to the length of the underlying column that corresponds to the segment. Because these column sizes vary among flexfields, you need to know what column lengths are available for your flexfield. The displayed length is the segment length a user sees in the pop–up window. If the displayed length is less than the maximum length, the
user must scroll through the segment to see its entire contents.
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/2×14, 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 (which may also have value descriptions). 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.

Accounting Flexfield : The code you use to identify a general ledger (GL) account in Oracle.
Flexfield Qualifiers : Balancing segment, cost center segment, natural account, inter-company segment.

 

Balancing Segment – Balancing segment is the level for balancing the accounting entries.
A balancing entity is one for which you prepare a balance sheets as a balancing segment value in the accounting flexfield structure. In any OU, you can have multiple balancing entities and each of these must balance within itself.If you define the balancing segment as company, then both debit and credit should be balanced at the company level when the transactions are posted to GL.
A Legal entity may consist of one or more balancing segments. If you define multiple divisions of a company in your chart of accounts for which you produce a balance sheet then each compnay is setup as a legal entity and each division as an OU.
(Notes: There is no hard and fast rule what should be the values of your balancing segment. While doing the implementation the client should specify at what level they want to see the net balance, profit/loss etc. The values can be some customers for which they want to track the profit-loss, some joint venters..etc. It should aslo contain one value for the whole business for which you want to track the net retained earnings)
Cost Center Segment – This attribute is used to identify the cost center segment.
Cost centres are divisions that add to the cost of the organization, but only indirectly add to the profit of the company. Typical examples include Research and Development, Marketing and Customer service. Companies may choose to classify business units as cost centres, profit centres, or investment centres.
(Examples: Corporate transaction, Engineering Dept,Material Dept, XYZ Exepense, Sales, Discount, ABC A/P )
Natural Account Segment – The natural account number is that portion of the account number that identifies what the financial activity is in pure accounting terms.  Some people (and some general ledger systems) confuse this definition by referring to the natural account number as the account number, implying that it is the entire basis for the chart of accounts.
Natural segment is nothing but the account heads type. In other words, natural segment determines the account type. There are five types of account types assets, liabilities, expenses, revenue and owner’s equity. Typically ACCOUNT segment would be your natural segment.
ex: Current Assets, Fixed Assets, Other Assets, Current liabilities
Code Combination : One full accounting flexfield with all segment values.
Dynamic Insertion / Cross-Validation : Automatic creation of account code combination based on rules defined with code combinations.
Secondary Tracking Segment is a Flex field qualified added in the 11.5.10 release. The secondary tracking segment is used in the revaluation, translation, and fiscal year-end close processes. The system will automatically maintain unrealized gain/loss, retained earnings, and cumulative translation adjustments by unique pairs of balancing segment and secondary tracking segment values. you can assign Secondary tracking segment flex field qualifier to an segment which haven’t assigned Natural account, balensing Segment and inter company.
What exactly it does:
Secondary tracking segment is not another balancing segment; it allows you to maintain accounting data at a finer level of detail for unrealized gain/loss account (Revaluation) account, Cumulative Translation Adjustment (CTA) account & Retained Earnings account (closing).
If you specified to use a Secondary Tracking Segment for Revaluation, the Unrealized Gains/Losses account will be tracked by the balancing segment and secondary tracking segment.
If you specified to use a Secondary Tracking Segment for Closing and Translation, the Retained Earnings account and the Cumulative Translation Adjustment (CTA) accounts will be tracked by both the balancing segment and secondary tracking segment.

Advantages of using Secondary Tracking Segment
• Secondary tracking segments provide better audit and analysis capabilities.
You now have more visibility into the detailed components of Retained Earnings, Cumulative Translation Adjustment, and Unrealized Gains and Losses. Instead of tracking these accounts by a balancing segment alone, you can track them by the balancing segment and another segment of your choice, such as Department, Line of Business, or Cost Center.
• A secondary tracking segment also provides better control and consistency of similar transactions because this option is set at the ledger level instead of through a profile option.
•By being able to nominate any segment other than your primary balancing segment or natural account segment to act as your secondary tracking segment, you have greater flexibility in tracking accounts by pairs of segments.
Disadvantages of using Secondary Tracking Segment
Secondary tracking segment does not support suspense adjustment, intercompany segment value balancing and rounding imbalance processing.

/by