While dealing with Oracle EBS html based pages, we can modify or create completely new page using any of the below methods:

Personalization

Personalization is the process of making changes to the User Interface (UI) from within an Oracle E-Business Suite Page. Using 'Personalize Page' link or from 'Functional Administrator' responsibility, we can perform personalization. 'Personalize Page' link shows all the regions and items used in the page in hierarchical form for example as shown below:

From here, we can modify/personalize almost any items/region using 'Personalize' icon. We can modify properties such as Prompt, Rendering of item, making fields Required and others as shown below:

All the personalizations get stored in MDS (i.e. JDR_% tables) by creating a new document ID for the page. Thus any patch will modify the original document ID (standard one) and unlike forms these personalizations will not get removed.

Extension

There are not many things we can do using personalization such as changing the logic or control settings of the page. For these modifications we use extension. It is the process of making changes to the programmatic elements of an E-Business Suite form/page. It is possible to extend OA Framework-based pages either using controller extension or AM extension or by performing VO substitutions.

Customization

Customization is the process of creating new OAF pages. While Oracle does provide tools to do this (i.e., JDeveloper 10g with OA Extension), this is the only and least supported option.

A flexfield is a field made up of sub–fields, or segments. There are two types of flexfields - key flexfields and descriptive flexfields.

A key flexfield appears on your form as a normal text field with an appropriate prompt.
A descriptive flexfield appears on your form as a two–character–wide text field with square brackets [ ] as its prompt.

When opened, both types of flexfield appear as a pop–up window that contains a separate field and prompt for each segment. Each segment has a name and a set of valid values. The values may also have value descriptions.

KEY FLEX FIELD [KFF]

Most organizations use ”codes” made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. For example, your organization might use the part number PAD–NR–YEL–8 1/2x14” to represent a notepad that is narrow–ruled, yellow, and 8 1/2” by 14”. Another organization may identify the same notepad with the part number ”PD–8x14–Y–NR”.
Both of these part numbers are codes whose segments describe a characteristic of the part. Although these codes represent the same part, they each have a different segment structure that is meaningful only to the organization using those codes.

The Oracle Applications store these ”codes” in key flexfields. Key flexfields are flexible enough to let any organization use the code scheme they want, without programming. When your organization initially installs Oracle Applications, you and your organization’s implementation team customize the key flexfields to incorporate code segments that are meaningful to your business. You decide what each segment means, what values each segment can have, and what the segment values mean. Your organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). You can also define relationships among the segments. The result is that you and your organization can use the codes you want rather than changing your codes to meet Oracle Applications’ requirements.

For example, consider the codes your organization uses to identify general ledger accounts. Oracle Applications represent these codes using a particular key flexfield called the Accounting Flexfield. One organization might choose to customize the Accounting Flexfield to include five segments: company, division, department, account, and project. Another organization, however, might structure their general ledger account segments differently, perhaps using twelve segments instead of five. The Accounting Flexfield lets your Oracle General Ledger application accommodate the needs of different organizations
by allowing them to customize that key flexfield to their particular business usage.

DESCRIPTIVE FLEX FIELD [DFF]

Descriptive flexfields provide customizable ”expansion space” on your forms. You can use descriptive flexfields to track additional information, important and unique to your business, that would not otherwise be captured by the form. Descriptive flexfields can be context sensitive, where the information your application stores depends on other values your users enter in other parts of the form. A descriptive flexfield appears on a form as a single–character, unnamed field enclosed in brackets. Just like in a key flexfield, a pop–up window appears when you move your cursor into a customized descriptive flexfield. And like a key flexfield, the pop–up window has as many fields as your organization needs.

Each field or segment in a descriptive flexfield has a prompt, just like ordinary fields, and can have a set of valid values. Your organization can define dependencies among the segments or customize a descriptive flexfield to display context–sensitive segments, so that different segments or additional pop–up windows appear depending on the values you enter in other fields or segments.

What exactly is a “360-degree view of a customer”?

 The term a “360-degree view of the customer” has been used in the industry for several years.  But what exactly does it mean, and what information would you actually display on the agent desktop?

Whenever a customer interacts with an organisation, it is vital that the richness of information available on that customer informs and guides the processes that will help to maximise their customer experience, while simultaneously making the interaction as effective and efficient as possible. This includes everything from avoiding repetition of information, to viewing customer history, establishing context and initiating desired actions.

A true 360-degree view needs to include views of the past, present and future:

THE PAST  means providing a meaningful and easily digested view of the customer’s history. This includes product or policy activity, interaction history     across all channels, including community, recent product views, campaign activity and process history.

THE PRESENT requires presenting key customer information about who they are and how they relate to your organisation, but also requires determining     the context of the call. Is there a recent order or current fault, why are they interacting with us now?   

THE FUTURE relates to actions that can be initiated to guide the future of the relationship. Is the customer likely to churn? Are there up-sell or cross-sell     opportunities or targeted messages to bring in at this time?

 

Delivering on the 360-degree view is not simply about having a unified database of all activity, but rather being able to pull together the pieces of information that are relevant for a specific customer and specific interaction into an intuitive workspace for the agent or the customer.

Ultimately, the 360-degree view is the very least that a customer expects of an organisation. They are not concerned with the internal departmental, line of business, political or system silos that all businesses have. They simply see one enterprise; it is vital that organisations see them and serve them just as clearly; this is a basic foundation for delivering a good customer experience.