Understanding Lookups in Oracle Fusion Application

Introduction

Of late I have received some feedback/inputs from some of my peers and well-wishers that my articles are getting more tech-savvy with less content (explanation) and more of screenshots. A very valid point considering few of my fast formula related articles but point well taken, going forward will try to keep things simple so as to cater to an audience with practically no hands on experience on the application.

I am sure most of the us (including those who are starting their careers either with EBS or Fusion) must have heard of terms like Lookups, Value-Sets too often and at times do get used to them without actually trying to understand what are they and why are they used.

In this article, I will try to explain what is meant by a lookup, why is it required, how many types of lookups, where it is used and so on…

So let-us start and the first and foremost question is:

What is a Lookup?

The literal meaning of lookup stands as

“an act or instance of looking something up, as information in a reference book or an online database” and the Oracle Fusion definition of Lookup isn’t too far away either, defined in the simplest terms “a lookup is a way to provide validation (using list of values) for a user input field in a user interface”. A typical example could be a field on UI form say Gender which might only allow values like ‘Male’ or ‘Female’. The application would not allow any other value apart from the ones listed in the drop down list attached to the form field.

What are the different types of Lookup?

A Lookup may be classified in multiple ways depending on the UI View Page where the same is defined and also depending upon the various customization levels (namely user, extensible and system).We would discuss both these type of classification here.

Lookup Classification Based on UI View Page Definition

Note: A reference data set may be considered as a data partitioning layer. For a set-enabled lookup the lookup-code (a lookup component discussed in detail later) is associated with specific data-set for example if the lookup-code is associated with US (short code for United States Legislation) it would not be used for EU (short code for European Union) and vice versa.

The different lookup types based on this classification are:

1. Common Lookups

These are the lookups which got migrated from the Legacy Systems as is (they belonged to the Common Lookups Category in other ERP systems) and are provided to ensure backward compatibility is maintained. They are defined in the Common Lookup View

Standard Lookups

Standard lookups are the simplest form of lookup types consisting only of codes and their translated meaning. They are defined in the Standard Lookup View

Set-Enabled Lookups

Set enabled lookup types store lookup codes that are enabled for reference data sharing. At runtime, a set-enabled lookup code is visible because the value of the determinant identifies a reference data set in which the lookup code is present.

Standard, set-enabled, and common lookups are defined in the Standard, Set-enabled, and Common views, respectively. Applications development may define lookups in an application view to restrict the UI pages where they may appear.

In lookups management tasks, lookups may be associated with a module in the application taxonomy to provide criteria for narrowing a search or limiting the number of lookups accessed by a product specific task such as Manage Purchasing Lookups

Components of a Lookup

A Typical lookup comprises of the following elements/attributes:

1. Lookup Type

Each of the lookup values (referred to as lookup-code) are clubbed into one or another groups depending on their specific use.

For example,

A MAR_STATUS Lookup Type will hold values like Single, Married, Divorced ….etc

Similarly a EMP_CAT Lookup Type will hold values like Full Time Regular, Part Time Regular, Permanent, Temporary..etc

2. Meaning

This field gives the meaning of the Lookup Type field. While the Lookup Type field holds only a short code (used for internal reference within application) and doesn’t allows spaces in between the Meaning field is the one which gives a more clear understanding of the Lookup Type.

For Example

MAR_STATUS lookup type has Meaning as Marital Status

EMP_CAT lookup type has Meaning as Assignment Category

3. Description

This field holds the complete description of the lookup type.

MAR_STATUS lookup type has description as Status of Person’s Marriage

EMP_CAT lookup type has description as Employment assignment categories.

4. Module

Each of the lookup type belongs to one or another module depending on the area where it is used. A lookup which is used for Absence Management would typically have a module name as Absence Management one which belongs to Human Resources ( MAR_STATUS is an example) will have a Module Name as HR ( stands for Human Resource)

5. Customization Level

Last but definitely not the least important attribute of any lookup this field helps us to identify whether we would be able to edit the lookup values of a lookup. They are of three types namely:

1. User: A Lookup Type which provides complete control on the lookup values. Adding, Deleting, editing…etc

2. Extensible: These lookup types have some lookup values which are pre-defined but can be extended to meet business needs. We can add/edit new values but are not allowed to make changes to existing pre-defined ones.

3. System: You are only allowed to change the Meaning field of the Lookup

If a product depends on a lookup type, the customization level should be system or extensible to prevent deletion. Once the customization level is set for a lookup type, it cannot be modified. The customization level for lookup types created using the Define Lookups page is by default set at the User level.

The various lookup Management tasks which are allowed at various customization layer when captured in a tabular format would look as:

Till now we only have covered the components of a Lookup Type but just having a lookup type does not make any sense until there are lookup values in it.

So let us spend some time to understand the various attributes of a Lookup Value too

1. Lookup Code

These are the actual values which are displayed as a List of value items on the user interface. Each value should be unique (for a specific lookup) and there should not be any spaces in between.

‘S’ which stands for Single and

‘M’ which stands for Married are typical examples for MAR_STATUS lookup type

2. Display Sequence

Each lookup code is assigned a display sequence basis which the value appears in the drop down list. We may change the sequence at any time but care should be taken that no two lookup codes hold the same sequence at any given point of time

3. Enabled

This attribute ensures whether a particular value would be displayed to the end user or not. If the ‘Enabled’ checkbox is checked than the specific lookup-code maybe used while performing transactions from user interface and if the same is unchecked the same would not be visible on the User Interface.

4. Start Date

This field holds the date from which a particular lookup-code can be used. It is always advised to have a very early date so that inconsistencies are avoided while performing transactions.

5. End Date

As the name suggests this field controls the end-date of a lookup-code. If we had a Lookup-code which was used till a particular date but is not supposed to be used post a specific date we may put the same date value here and this would ensure that the lookup-code does not shows up in the List of value post the end-date.

6. Meaning

The actual value which is displayed to the user. For example, ‘Yes’ for lookup-code of ‘Y’ and ‘No’ for lookup-code ‘N’

7. Description

This field holds the detailed info about a specific lookup-code. The field length is large enough and is used to give a clear idea to consultants and business users about a specific lookup-code.

8. Tag

One of the most important field which controls lookup code usage legislation wise. Say for example we have three legislations namely US, UK and IN and as per the country specific rules all unmarried individuals in India have a Lookup Meaning as ‘Unmarried’ for India (IN) while for US and UK they are referred to as ‘Single’. In this scenario although both the lookup-codes say U (for unmarried individuals used in India) and S (for individuals based in US,UK) would be present in the MAR_STATUS lookup type but only ‘U’ should be visible for users who belong to India legislation and similarly ‘S’ should be visible to users of ‘US’ and ‘UK legislation. In this scenario the TAG fields comes to the rescue. We would need to tag the legislation code beside the specific lookup-code value (Using a + sign followed by Legislation Code ensures the lookup-code is enabled with the legislation)