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. 

Application

Name of the application to which the DFF belongs to.

Name

Name of the Structure; this will be used by the routines, to call the DFF from Forms or Programs.

Title

This is the identifier that identifies each DFF uniquely.

Description

Description, free text.

Table Application

The application to which the Parent Table belongs to.

Table Name

Name of the Table.

Structure Column

The name of the column in the table that can be used by the DFF to distinguish between structures. Based on the data supplied to this Column different DFF structures will be opened. 

Context Prompt

The Prompt we want to see for the field on which the user will be specifying the context.

DFF View Name

This shows us the view created by the application to store the DFF data.

Protected

This check box makes sure that, there cannot be any changes to the structure of the DFF.

Reference Fields

This is the place where, we mention all the possible reference fields for the DFF. Although we use them or not, it is always better to list the reference items for future use.

Columns

This screen lists all the fields in the table along with the DFF attributes with an Enabled Flag against them. The flag denotes the fields that are part of the DFF structure.

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.

 

Application

The Application to which the DFF belongs to.

Title

The Title of the DFF.

Freeze Flex field Definition

This flag is checked to freeze the definition, this does not allow updates to the DFF, to update something in the DFF< we need to uncheck the flag first before doing changes.

Segment Separator

This is the character that is going to separate one segment from the other in case of Concatenated Description fields.

Context Field Block

 

Prompt

This is where we choose the prompt for the Context fields. Based on the data entered against this prompt, the dependent attributes will appear.

Value Set

This is the value set for the context. If we have a context that holds the valid set of contexts for the DFF, then this is the place to use that.

Default Value

The Default Context Value, if any.

Reference Field

Enter the reference field that we want to use, from which the context will be automatically derived. The Reference field must be defined in Reference Field section in Register screen to be used here.

Required

This makes the context field mandatory. If the flag is checked, we cannot leave the context field blank for any record.

Displayed

This check box was earlier known as the “Override Allowed” flag. By checking this check box, we make sure; the context value is visible and updatable to users. If the flag is unchecked, the context value is auto populated by the reference field and later just the dependent attributes appear based on the hidden context. A user can not choose its own context, if the flag is unchecked.

Synchronize with Reference Field

This flag makes sure, whenever there is a change in Reference Field, the context is updated automatically; so that the synchronization happens.

Context Field Values Block

 

Code

This is the name of the DFF Context Structure, must be unique.

Name

The name of the Context.

Description

The Description, free text.

Enabled

Makes the Context available to the application

Compile

This button is clicked only after the contexts are defined to compile them.

Segments

This button leads us to a new screen on which we are going to define the attributes.

 

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)

 

Number

The sequence Number. Never use 1, 2, 3... Use a sequence of 10 with increment of 10, like 10.20, 30. It enables us to insert records in between.

Name

Name of the Attribute

Window Prompt

The window Prompt for the attribute.

Column

The Column on which it is going to be stored.

Value Set

The value set attached to the attribute.

Displayed

Enables the attribute to be displayed on the application.

Enabled

Makes the attribute usable.

The caption-less flag on the top

This flag synchronizes the dependent screens opened using the buttons downstairs.

Value Set

This opens the value set Button; we are going to discuss more about this in Value set Section.

Open

This button opens a screen that explains more about the Flex Field.

New

This is similar to that of Open; but this button creates a new row in the context.


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)

 

Name

Name of the field as entered in the Previous window.

Description

The description of the attribute.

Column

The column on which the data is going to be stored.

Number

The sequence Number.

Enabled

Makes the attribute usable.

Displayed

Enables the attribute to be displayed on the application.

Value Set

The Value set to be used against the attribute.

Description

Auto populated with the Value set description.

Default Type

The type of Default value for the attribute. Could be a Constant, a Field, a Profile Value, a Segment or even a SQL statement.

Default Value

The Default value of the segment.

Required

Makes the attribute a Mandatory one.

Security Enabled

Makes the Security rules apply based on the security Profile and responsibilities.

Range

The Range could be High or Low. This is additional security, to make the High attributes depend on the Low Attributes.

Display Size

The size of the text field which will be displaying this field.

Description Size

The size of the description of the field.

Concatenated size

This is the size to be displayed when the application shows the attribute on a concatenated Flex field values.

LOV Prompt

The Prompt to be displayed in the List Of Values.

Window Prompt

The Prompt to be displayed on the Screen.

 

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

Name

Application

Type

Job

Human Resources

Mandatory

Position

Human Resources

Mandatory

Grade

Human Resources

Mandatory

Competence

Human Resources

Mandatory

People Group

Payroll

Mandatory

Cost Allocation

Payroll

Mandatory

Personal Analysis

Human Resources

Optional

CAGR

Human Resources

Optional

Soft Coded

Human Resources

Optional

Bank Details

Payroll

Optional; However if the country does not have a seeded localization, this becomes Mandatory

Item Contexts

Human Resources

Optional

Training Resources

Learning Management

Optional

 

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)

 

Application

The Application that owns this KFF

Code

Every KFF has a unique code

Title

The Name of the title, this is unique as well

Description

Description of KFF, Free Text

Table Application

The application owner of the table on which the KFF sits

Table Name

The name of the Table

Unique Id Column

The unique id to be used in the Combination table

Structure Column

The column to be used in the combination table to distinguish between the flex field structures

KFV View Name

The name of the view that shows the KFF details.

Qualifiers

This buttons opens up a screen in which we enter the Flex Field Qualifiers.

Columns

Lists the available columns along with the enabled flag telling about the availability of the column in the database.

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.

 

Cross Validate Segments

We can define Cross validation rules against segments. These are the additional checks we can perform over the KFF segments. If we are going to use the Cross validation on this structure, we must check this box.

Freeze Rollup Groups

This is more for Oracle Financial. This is used for grossing up / summing up the segment values.

Allow dynamic inserts

This tells the system whether to allow a save, if the combination that the user is entering at the runtime, is unavailable as a valid combination in the Combination table. If the flag is marked Yes, then the system allows the user to enter new valid combinations.


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.