Flexfields

Flex Fields

In E-Biz, data storage is configurable to a great extent. The entire cycle of storing required data, includes, capturing the data, administering it with ease and embedding the business rules to the data. The product is designed to cater different types of requirements for a largely diverse set of businesses. Every business has a requirement of capturing different set of data, firm ‘A’ might need field ‘X’ to be stored in PER_ALL_PEOPLE_F and Firm ‘B’ might need field ‘Y’ instead of ‘X’. It is just a mere example; however if we look at the diverse set of businesses that use Oracle E-Biz, we will realize, how different can be the business rules of one enterprise from another, and so can be the required data. How does oracle manage to give the liberty to the firms, to store data based on their particular requirement; keeping in mind that it has to keep its table structures and internal programs stable.

The answer is Flex Fields. Oracle takes a Particular table, and analyzes the different types of data, which might be needed to be stored in that table. It takes the maximum possible attributes that might be needed taking the Performance and normalization into consideration. Now, what if we need another attribute to be used in one of my tables, and that attribute is not provided by Oracle? This is where Flex Fields come handy. Oracle E-Biz gives us the liberty to define and use our own set of additional attributes; those attributes are called Flex Fields. Just as the name suggests, they are flexible Fields, which can be used to store extra information.

The advantages of having flex fields are:

• Capturing data specific to ones business needs that are not seeded by the application
• Storing intelligent fields that can be used to store the data along with meanings
• The fields can then be validated against the list of values specific to the requirements
• These extra fields need no extra programming; they can just be configured and used

Flex Fields are of two types:

• Descriptive Flex Fields
• Key Flex Fields

Descriptive Flex Fields

Descriptive Flex Fields or DFFs are the additional attributes provided along with the standard table structures to accommodate the extra data, needed by the enterprise. Every table has extra set of columns / attributes to store the DFFs. If an enterprise has to store a particular data that is not stored in any of the standard columns of the table provided by Oracle E-Biz, that column can be stored in the database using a DFF.

DFFs can be context specific. We could configure the DFFs in a way that, the data will appear based on the value filled in a specific table. For example, if we wish to store the VISA details of the employee, only if the employee is not a resident of the country he works in; we could use the work status as a context column. If the value of the field is Expatriate, we will use the DFF to store the VISA details; else the DFF won’t appear at all. So we can say, the DFF can be so be customized that data entered in one attribute completely depends on the data entered in another, which is the context.

There can be two types of contexts.

• Global Contexts / Global Data Elements
• Business Contexts

The Global data elements always appear on the form, where as the Business Context specific Data Elements appear only when there is a context specified. The context can be set from either any value in the Form or might just be another value from the DFF. If the value is seeded from the forms then it is called a reference field; whereas, if it is just another attribute inside the DFF, it is called a context field. Mostly Context fields are used and it’s put in the DFF itself. Once the Context field is entered, it extends the form to capture the context specific data elements.

Each and every attribute in DFF has a window prompt, an attribute number, on which the data is stored, and a set of values, although being optional. Let’s see, how to define the different contexts and the related attributes.

Register

A user, as the name suggests in an entity that logs in to the system, and uses the system resources for their requirement. So who are the users?

• Responsibility: Application Developer
• Navigation: Flex field -> Descriptive -> Register

(Figure 3.1 – Registering a DFF)

Steps:

This is “Register DFF” Screen. See Figure 3.1 – Registering a DFF. This is the screen, where we need to find the name of the title of the DFF that we are going to use, based on the name of the Table and the Application.

Once the new DFF is registered, the next step is to define / update the DFF structure and the contexts.

Definition

A user, as the name suggests in an entity that logs in to the system, and uses the system resources for their requirement. So who are the users?

• Responsibility: Application Developer
• Navigation: Flex field -> Descriptive -> Segments

(Figure 3.2 – DFF Contexts)

To choose our DFF, we can query for the Title, we got from the Register window / we can just use “View (M) -> Find” to get the list of available DFFs. See Figure 3.2 – DFF Contexts.

Let’s discuss some more things about the Context Field Block. We use this block, when we have a user defined context other than the Global Context. This block can be used to define the context value prompt, the Value set attached to the field, the Default value, and the related reference field on which the context will be dependent on. Finally the other flags like ‘Required’, ‘Displayed’ and ‘Synchronize’ can be used to add actions to the field.

About the Context Field Values Block, this is where we are going to define the Context and the related attributes in use. In here, once the Segments button is clicked, it opens a new screen, which allows us to define the attributes and the related value sets. See Figure 3.3 – DFF Segments.

(Figure 3.3 – DFF Segments)

Let’s click on the Open Button and see the other details of the Flex Field attribute. See Figure 3.4 – Segment Details. We can use the new button, that opens the same screen, to create a new record here itself; without putting the details in the parent screen.

(Figure 3.4 – Segment Details)

Range: The range defines the dependency of a particular attribute. For an example, if we are using a start date and an end date in our context and we want our end date to be later than that of start date, then we might want to put the start date with a low range, and end date on high. That explains the dependency. Again, the sequencing of our attributes must be as per the range. The attribute with high range must be put at a higher number than that of low, so the low range attribute should appear first than the high range one.

Key Flex Fields

As the name suggests, Key Flex Fields / KFFs store the key building blocks of the components used in a module. Although the primary purpose is to store flexible data, unlike the DFFs, the KFFs store combination of data segments called codes. Every organization uses codes to identify the portions of their business components, like Division code, Company code etc.; and every code is related to a meaning. For example, the Department code 02 is the Code, and “Sales department” is the meaning of the code. These codes and meanings can be stored in the KFFs, so that each and every department in the Organization can use their set of codes without any programming efforts.

The set of codes are separated by segment separators and once all the segments are filled in, as a whole the codes are known as the Combination of codes. Each combination of code identifies a particular type of data independently.

Let’s take an example of “Cost Allocation KFF”. This KFF in captures the money spent by each of the departments, and divisions in the enterprise. We have the KFF with the following details:

• Company Code
• Division Code
• Sub division code
• Department Code
• Cost Centre Code

Even our organizational hierarchy is designed in the same order. Now, if we fill in the codes, with the segment separator as ‘;’the combination might look like this:

02; 005; 03; 58; 10586

Here, 02 is the Company code, 005 is the division code and so on. Now, this combination of code identifies our cost centre uniquely. It will also have a code Combination id number, that helps identify the series with upmost ease. The combination codes are also known as “Intelligent keys” that are easy to remember and use in day to day business needs.

KFFs in HRMS and Payroll

Talking about HRMS in specific, there are 10 frequently used KFFs

Unlike DFFs, KFFs are stored in more than one table structure. There will be one table that stores the structure of the KFF, and the other stores the Combinations. The Seeded KFFs always have the Combination tables defined. However if we are planning to create our own KFF, we will have to create and register our own KFF Tables.

Register

Let’s discuss how to setup / update an KFF. We will start with the register screen. See Figure 3.5 – KFF Registration. This screen lists all the KFFs defined in the installation of E-Biz. This screen is used to define a new KFF, and it is also handy to find an already defined / seeded KFF.

• Responsibility: Application Developer
• Navigation: Flex field -> Key -> Register

(Figure 3.5 – KFF Registration)

Qualifiers

A qualifier is a level in which KFF Segments can be updated. Let’s reconsider the Cost Allocation KFF example. The combination looked like this: 02; 005; 03; 58; 10586. Here, if we wish to use this KFF in five different levels, like Organization, Payroll, Elements, Element Entries and Assignment; and we want only a set of segments to be accessible in certain levels; say, we should be able to enter the Company code, only at the KFF attached to the Organization screen, and nowhere else. Similarly, the Department Code should not be entered at the Assignment level, there is a way to do so. To enable the user to do configurations like this, Oracle has come up with a concept of Qualifiers. There are two stages of defining qualifiers; the Flex field qualifiers and the segment qualifiers. While the Flex Field qualifiers define the different stages where the KFF is going to be used, the segment qualifiers define the rules on the usages of the segments in those levels.

Segments

Now, let’s move to the next section, and learn the definition of KFF segments. See Figure 3.6 – KFF Definition.

• Responsibility: Application Developer
• Navigation: Flex field -> Key -> Register

(Figure 3.6 – KFF Definition)

The details in the KFF segments form is exactly the same as the DFF segments with small differences. Like, we cannot have Context Values in KFFs; we do not have a reference field. Considering the similarity, we are not going to reiterate the information; however we will be discussing the differences here.

In the Segments, there is just one extra button that we have not discussed, the Segment Qualifiers Button. This is the screen in which we can see the different Flex Field qualifiers and add the enabled flag to make that particular Segment available at the given level.

Cross Validation Rules

The Cross validation rules can be applied to the KFFs, when we wish to validate the segments based on the business needs, to control and maintain the new combination being inserted into the tables.

Let’s see how to set up rules.

• Responsibility: Application Developer
• Navigation: Flex field -> Key -> Cross Validation

(Figure 3.7 – Cross Validation Rules)

Steps:

• Select the application and the Flex Field title that we want to define
• Enter a unique name for the Validation rule in the Name field along with the description of the rule and make it enabled
• Put the Error Message in the Error field along with the segment on which it should error
• We can also set start and end dates to it; to make the error effective for s certain time
• Now, in rules, put the type as Include or Exclude along with the High and Low range for the segments we want the check for
• As we have defined the Low and High, if the Type in Include, the error will appear, if the user entered value, does not fall in between the lows and high
• If the type is selected as Exclude, the error will appear, if the user value falls in to the low and high range.
• If user enters a blank, it is considered to be a pass, if any one of the Low or High value is put as Blank.

Now we know how to set validations to our KFF Segments. At any point of time, we wish to see the values used in the KFF; we can go to the Values submenu in the Key Flex Field menu to do so.