HRMS AOL

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.

Lookups

Lookups are a set of code and meanings. Sometimes, it can also be used to store extra set of data using contexts. The purpose of having lookup is to have fast recovery of data for validation. For an example, if we were to store the termination codes available in a firm, we will have a structure similar to this.

01 Normal Termination

02 Retirement

03 Retrenchment

04 Personal

Here, the 01, 02 are the codes and the reasons are stored as the meaning. So, if we wish to just key the in code, and we want the system to understand the meaning, then we must store the codes and meanings somewhere. Oracle gives us expedient tables to store codes and meanings which are easy to access. It uses the concepts of Lookups to store the quick reference data in a tabular format, which are easy to store retrieve and amply extensible. Let’s see how to configure one. See Figure 3.8 – Lookup Types.

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

(Figure 3.8 – Lookup Types)

Steps:

Type	The name of the lookup type
Meaning	The meaning. This can be used as a reference to the lookup type, that explains the purpose of the lookup
Application	The application owner of the lookup
Description	Any description, free text
Access Level	The Access Level is automatically set by the system. User: It is created by user and it is updatable. Extensible: Although it is seeded, a user can add records here; however cannot delete a seeded record
Code	The code of the lookup value must be unique for each row.
Meaning	The meaning of the Lookup value
Description	Any description, it can explain the meaning in details.
Tag	These are mostly used in seeded lookups. The system puts the localization information here. If it is ‘+FR’ that means it is applicable for France, if it is ‘-RU’ means the row does not apply for Russia. These are mere data fields, the actual logic of including or excluding the Localization is actually in the code that uses the lookup.
From / To	The Start and End dates are put here
Enabled	We can switch the row to be available or unavailable with this flag.

Eventually when we keep on discussing more about the Application, we will realize the huge dependency we have over Lookups. This is one of the most frequently visited screens, during implementations.

Let’s say we want to add some more data into a lookup; something more than mere codes and meanings. We can do that by adding a context to it. It is a DFF with title as ‘Common Lookups’. See Figure 3.9 – Lookup Contexts.

(Figure 3.9 – Lookup Contexts)

We will just have to add a new context and add on segments. It’s as good as a normal DFF. Once the DFF segments are defined, we can use this as a context related flex field where the data can be stored using the segments, based on the chosen context in the lookup screen.

User Defined Tables

Apart from the seeded tables, Oracle E-Biz gives another set of tables that a user can design, create and use in order to satisfy the business needs. Those are called the User defines tables, in short, UDTs. Let’s see how to define a table. See Figure 3.10 – UDT Structure.

Responsibility: Super HRMS Manager
Navigation: Other Definition -> Table Structure

(Figure 3.10 – UDT Structure)

Steps:

UDTs are date track enabled, so pick a date before creating a table
Enter the name of the table in the Name field
The User table key gets defaulted with the table name, however can be changed. This is the column that uniquely identifies a table.
The Match type defines a certain type of validation. If the type is selected as match, system expects the table rows to store data of one particular type. And the Unit of measure of the types is fetched from the type specified in the key unit of measure field. UOMs can be Date, text or number.
The match type is selected as range, when there is a range to be defined, like a lower bound or upper bound. Similarly the UOM is selected from the UOM field; however it is always a number.
Now, it is time to define the columns. Click on the Columns button to do so. Define the different columns that would be needed in our table. Use a formula to validate the data entered in the formula.
Then the rows. As our table is just in design phase, this is the place where we just define the row labels; the actual row is entered later. Put the row along with the sequence, row key and the exact row name. In case of range types, use the lower and upper boundaries.
This completes the definition of the table. Let’s now put some rows in it. See Figure 3.11 – UDT Values.

Responsibility: Super HRMS Manager
Navigation: Other Definition -> Table Values

(Figure 3.11 – UDT Values)

Steps:

Query the table name.
Now the screen shows us the rows with only the first column.
To navigate through columns, click on the Column Name, and use up and down buttons.
In the Exact field, key in the exact row number and the column value of the row.
Similarly fill in the other columns, using the up and down arrows.

Now, to use the UDTs, we can fetch the table columns from ‘PAY_USER_COLUMN_INSTANCES_F’ and ‘PAY_USER_TABLES’. The other important tables are: ‘PAY_USER_ROWS_F’ and ‘PAY_USER_COLUMNS’.

Value Sets

A Value set, as the name suggests, holds a set of values. The values are then used in different places in the application for validation. For an example, if we have three different Audit Departments, A1, A2 and A3; and we want the Employees to enter an Audit Department number in which they wish to be audited. We wouldn’t want them to enter something other than these three departments. We wouldn’t allow them to save the record if they entered A4; because A4 is not a valid value. So what is the solution?

To manage situations like this, we could define a value set that holds these three values, and attach that value set to the field. So whenever an employee starts filling in details, s/he has to fill in with a value that is valid as per the value set. Let’s see how to define one. See Figure 3.10 – Value Sets.

(Figure 3.12 – Value Sets)

Responsibility: Application Developer
Navigation: Application -> Validation -> Set

Steps:

Value Set Name	Name of the Value set.
Usages	This one shows all the places where the value set is being used, either a Concurrent Program or a KFF or a DFF.
Description	Any description, free text.
List Type	Choose a list type: LOV: For any List of values Long LOV: For a List of Value, that is expected to pull a long list. When we use this, the LOV initially appears with No Values, unless a search String is entered for to do a pattern match. Pop List: A Pop list is used when the list of values is expected to be very small, usually less than 10 values.
Security Type	This is to justify the security rules attached to the value sets, if any. Choose any one of the three: No Security: No Security rules apply. Hierarchical: This ensures we have access to the entire hierarchy of data being entered. Non-Hierarchical: This option does not check for the entire hierarchy. If we have access to the data being entered, we can. For example: If we do not have access / privilege for the Head Cost centre we will not be allowed to enter the Sub divisional Cost Centre name in case of Hierarchical model. In case of Non hierarchical model, it just checks the access for the cost centre being entered.
Format Type	The Format in which the values stored in this Value set are going to be.
Max size	The Maximum size. For some standard Format types, it is fixed.
Precision	Only available with Numbers, sets the precision point.
Numbers Only	Ensures only numbers are entered as values.
Uppercase Only	Ensures only Uppercase Values are entered.
Right Justify	It makes the Value right justified with zero filled to the rest of characters.
Min Value	The Minimum/ Low Value.
Max Value	The Maximum / High value.
Validation Type	Explained later in this chapter.
Edit	This opens a screen based on the validation type, with which the data will be validated.

Validation Types

These define the way the values in the value sets are stored or matched.

None: No validation, other than the ones in Format checks attached in the parent screen.
Independent: with this type, the Values are stored in an AOL Table, along with a meaning. For example, we might have a code as 02 and the meaning as “Boston Division”. We will learn how to set values in an independent Value set.
Table: It is similar to the Independent Value set, however the data is stored in an application table.
Dependent: With this type, although the data is stored in an AOL Table, the values are filtered based on another Independent Value set, which is linked to the dependent Value set. So based upon the value we enter in an Independent Value set, values for the Dependent Value sets are populated
Special: These are like a Flex Field in a value set. So these are like a combination of values, mostly from a Key Flex Field, that appear in the value set.
Pair: This allows us to use a range of Concatenated Flex Field segments in a value set.
Translatable: The Translatable value sets are similar to the Dependent and Independent types. However these enable us to use hidden codes, so that user sees only the meaning and not the codes.

Table Types

In case of a Table type of value set, as we wish to see the values from a Table, we must define the columns and the table from which the data will be pulled. See Figure 3.11 – Table Type Validation.

Steps

Click on the Edit Information.
Enter the name of the application to which the table belongs to.
Enter the table name.
Enter the column in which the Value is being stored in the Value field along with the data type and size.
Enter the meaning if any.
Enter the column that stores the Id, if we want to use the Ids as well; along with the data type and size.
If the value set is used in Concurrent requests, the Value is taken as the front Parameter; however the Id is the one that is fed to the process.

(Figure 3.13 – Table Type Validation)

In parallel, write a query in our database, and park this screen for a minute. Take the value, meaning and Id in the “select clause” and Table name in the “from clause” and in where clause, put the conditions that must match to get the values.
Once the query is complete, put the where clause and the Order by clause if any, in the where section.
If we are using any extra columns, for matching the values or to be used in the Order by Clause; other than the Value, Meaning and ID, then put those in the additional columns field.

Segment Values

We discussed that the dependent and independent value set fetch the valid values from an AOL Table. Let’s see how and where we store the values. See Figure 3.14 – Segment Values.

Responsibility: Application Developer
Navigation: Application -> Validation -> Values

(Figure 3.14 – Segment Values)

Steps:

Name	Name of the Value Set.
Dependent value Set	If it’s a dependent Value set, mention the Value set on which this value set depends on.
Value	The Value.
Translated Value	The Meaning of the Value.
Description	The Description.
From and To Date	The effective dates.
Hierarchy and Qualifiers	This is where we can add extra security based on Qualifiers.

Messages

In an application, there will be errors and warnings at the runtime; and the application will be giving messages based on the errors / warnings. However at times, we might wish to change the error / warning message as per the business needs. And sometimes, we would even need to set up our own personalized messages on the application forms / self service. For this, AOL has functionality in place, called FND Messages. These are pure text messages along with tags, which could be used to fill in specifics related to the messages at the run time. And once the message is defined, it can be attached to different functions or routines from which they will be called and displayed.

Definition

Let’s see how to define one message, and then we will look further in to the usages and the Tags that are used in the messages. See Figure 3.15 – Defining Messages.

Responsibility: Application Developer
Navigation: Application -> Messages

(Figure 3.15 – Defining Messages)

Name	Name of the message can be entered here. It is advised to have a meaningful name along with the application it is being used for and the error number.
Language	Pick a language in which the message will be displayed.
Application	The application in which the message will be used.
Number	The Error Number, this is the number with which the calling routine identifies the message uniquely.
Type	The Type of the Message, whether an Error or hint or a Note or may be the title of the message. It can also be a % of Expansion, which means the system will open up a window of size 30% of the window, and shows the message in there as a Prompt, if it is a 305 Expansion prompt. Likewise for 50 and 100% it works the same way.
Maximum Length	The Maximum Length of the message.
Description	The Description of the message a free text.
Alert Category	The type of alert, like it is an alert on the system, Product or is it about security. All these are usually used by the seeded system messages. Blank or User is the type we want to use in a custom message.
Alert Severity	The type of the severity of the alert is it an Error/ warning or is it critical to the system. For custom messages leave blank.
Log Severity	If the message is being logged for system administrator, then what type of log would this be? Usually this raises another set of routines, to inform the system administrator about the issue via emails / texts.
Text	This is where we add the text of the messages.

Message Text

This is the place that stores the text of the message that gets displayed. There are a lot of possible ways to decorate it and make it more meaningful.

Parameters: We can receive parameters from the calling routine, and use them as part of the message text. We can set variables for the same. They can be used with an Escape Character ‘&’ or ‘:’. For an example:

“The exemption limit is not set up for the legal employer &ORG_NAME for the current period.”

This is a message text, and &ORG_NAME is the variable that can be passed to the Message by the calling routine. So if the routine passes ORG_NAME = ‘ABC Corp.’ then the message will look like this:

“The exemption limit is not set up for the legal employer ABC Corp. for the current period.”

We can also use system parameters in the messages like: <product-code>

Formatting: In formatting, we can use the HTML codes to format our messages. It can start with a <html >tag and can have the required tags in the body. Here is a sample.

<html><b>You cannot complete this task because one of the following events caused a loss of page data:<br> <ul><li>Your login session has expired. <li>A system failure has occurred.</ul></b> To proceed, please select the global Home link to return to the main menu. Then, access this page again using the navigation controls (menu, links, and so on) within the application. </html>

Oracle Apps Essentials

Search This Blog

HRMS AOL

Labels

Comments

Post a Comment

Popular posts from this blog

How to compile all INVALID objects in Oracle

How to setup and use AME - Approval Management Engine

Workflow Important Debug Queries