http://oracleapps88.blogspot.com/2013/12/oracle-forms-personalization-interview.html?_sm_au_=itHDNvkRQs057s17
--> 1) What is Forms Personalization? Where it is used? What For?
Forms Personalization is a standard feature provided by oracle and supported by oracle to customize the forms. With Forms personalization you can hide fiedls, make fields mandatory, create zoom functionality, change lov dynamically e.t.c
--> 2) What are different triggers that can be used in personalization?
WHEN-NEW-FORM-INSTANCE WHEN-NEW-BLOCK-INSTANCE WHEN-NEW-RECORD-INSTANCE WHEN-NEW-ITEM-INSTANCE WHEN-VALIDATE-RECORD MENUS SPECIAL EVENTS
--> 3) What is the difference between having personalization at function level rather than form level?
A Form can have multiple functions. Having the personalization at function level limits the scope of the personalization. Forexample in Inventory for both 'Master Item form' and 'Organization Item form' uses same form named INVIDITM where as both have different fucntions linked to them.
--> 4) Can you use global variables in forms personalization? If so How?
Yes.
--> 5) Can you hide a text field using personalization? How?
Yes. In the actions set DISPLAYED property to false.
--> 7) Can you transfer the data from one form to another form using personalization?
Yes. Using global Variables.
--> 8) How do you move personalization from one instance/database to other?
Form Personalizations can be moved easily through FNDLOAD from one instance to other. Refer to the Article FNDLOAD for more details:http://www.erpschools.com/Apps/oracle-applications/articles/General/FNDLOAD-to-transfer-the-menus-concurrent-programs-personalization-from-one-instance-to-other/index.aspx
--> 9) What is personalization and what features can be achieved through personalization?
Personalization gives us the ability to customize Forms in a very easy manner. The below customizations are possible through Personalization: Zoom from one form to another Pass data from one form to another through global variables Change LOV valuesdynamically Enable/Disable/Hide fields dynamically Display user friendly messages when required Launch URL directly from oracle formExecute PL/SQL programs through FORM_DDL package Call custom libraries dynamically
--> 12) At what level you can restrict personalization code?
FORM level and FUNCTION level
--> 13) What can be implemented through Forms Personalization?
The below can be done using PErsonalization: Zoom from one form to another Pass data from one form to another through globalvariables Change LOV values dynamically Enable/Disable/Hide fields dynamically Display user friendly messages when required Launch URL directly from oracle form Execute PL/SQL programs through FORM_DDL package Call custom libraries dynamically
--> 14) How to do implement ZOOM Functionality using personalization?
Refer to the Forms Personalization Tutorial article: http://erpschools.com/articles/forms-personalization-tutorial
--> 15) What are the advantages/disadvantages of Forms Personalization when compared to CUSTOM.pll?
Advantages: Personalizations are stored in tables rather than files Will not have a bigger impact when you upgrade or apply patchesto the environment Can be moved easily through FNDLOAD from one instance to other Can be restricted at site/responsibility/userlevel Easy to disable/enable with click of a button. Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don¿t have that ability. Disadvantages: Not all can be customized usingPersonalization.
--> 16) When you display a error message at WHEN-VALIDATE Trigger will the data will be saved into database?
No. If it is normal message or warning data will be saved but not for error message.
-> Oracle has provided a simple and easy feature to implement the customer specific requirements without modifying the underlying forms code or Custom library.
--> This personalization feature provides easy, faster way to customize Oracle apps forms with
minimum development effort.
--> The Form Personalization feature allows you to declarative alter the behavior of Forms-based screens like changing properties, executing built-ins, displaying messages, and adding menu entries…etc
Why personalization :-
Oracle Supports personalization unlike customization.
Personalizations are stored in tables rather than files.
Will not have a bigger impact when you upgrade or apply patches to the environment.
Can be moved easily through FNDLOAD from one instance to other.
Can be restricted at site/responsibility/user level.
Easy to disable/enable with click of a button.
Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
Can be applied to new responsibilities/users easily.
Can be restricted to function or form.
What can be done through personalization:-
Zoom from one form to another.
Pass data from one form to another through global variables.
Change LOV values dynamically
Enable/Disable/Hide fields dynamically.
Display user friendly messages when required.
Launch URL directly from oracle form.
Execute PL/SQL programs through FORM_DDL package.
Call custom libraries dynamically.
To create personalization for a particular function/form, first invoke the function/form in Oracle
applications.
Navigation: choose “Help -> Diagnostics -> Custom Code -> Personalize” from the pull down
Personalization Tables:-
All personalization’s that we have made to Oracle application forms will be stored in following
tables :
1. FND_FORM_CUSTOM_RULES
2. FND_FORM_CUSTOM_ACTIONS
3. FND_FORM_CUSTOM_SCOPES
4. FND_FORM_CUSTOM_PARAMS
5. FND_FORM_CUSTOM_PROP_LIST
6. FND_FORM_CUSTOM_PROP_VALUES
Rules:
- Contains Sequence, description of the rule. Level either Form or Function depends on requirement.
- Enable or Disable Rules using check box
Condition:
- Provide Trigger Event, Trigger Object, Sql statement in Condition.
Real-Time Examples
1. Change Displayed data in LOV
Goal:
Change the LOV in “Supplier Name” field in the Find “Invoice Form (AP_APXINWKB)”
Navigation: Payables Manager > Entry > Invoices
Double Click it to open
In the first filed, Supplier Name change LOV In such a way that no one can see the TaxPayerID in LOV. It should be masked with *’s.
Navigation: Help Menu >> Diagnostics >> Custom Code >> Personalize
Enter the following information:
Seq: 5 Description: Disable Tax Payer Id
Level: Form Enabled: checked
Trigger Event: WHEN-NEW-FORM-INSTANCE
Processing Mode: Not in Enter-Query Mode
Click on Actions and enter the following.
Seq: 10 Type: Builtin Language: all
Builtin type: Create Record Group from Query
Argument:
SELECT vendor_name, vendor_number,
DECODE (active_flag, ‘Y’, ‘Yes’, ‘N’, ‘No’, ‘Yes’) active, ‘***’ num_1099,vat_registration_num, vendor_id, ”, ”, ”, ”, hold_all_payments_flag
FROM po_vendors_ap_v
WHERE num_active_pay_sites > 0 OR num_inactive_pay_sites > 0
ORDER BY UPPER (vendor_name)
Group Name: ERP_SCHOOLS_ALL_VENDORS_NAME
Now Create New Record with below information
Seq:12 Type: Property Language: All Enabled: Checked
Object Type: LOV
Target Object: INV_ALL_VENDORS_NAME
Property Name: GROUP_NAME
Value: ERP_SCHOOLS_ALL_VENDORS_NAME
Save it.
Click Validate
Click Apply Now.
Go to tools Menu >> click Validate All
Once it is successfully validated you are ready to go.
Click ok and close personalization form.
Close your find invoices form and invoices form completely.
Open it again and click on Supplier name field LOV
Query any supplier. You will see your changes to the LOV as shown below.
Message
Builtin
Menu
--> This personalization feature provides easy, faster way to customize Oracle apps forms with
minimum development effort.
--> The Form Personalization feature allows you to declarative alter the behavior of Forms-based screens like changing properties, executing built-ins, displaying messages, and adding menu entries…etc
Why personalization :-
Oracle Supports personalization unlike customization.
Personalizations are stored in tables rather than files.
Will not have a bigger impact when you upgrade or apply patches to the environment.
Can be moved easily through FNDLOAD from one instance to other.
Can be restricted at site/responsibility/user level.
Easy to disable/enable with click of a button.
Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
Can be applied to new responsibilities/users easily.
Can be restricted to function or form.
What can be done through personalization:-
Zoom from one form to another.
Pass data from one form to another through global variables.
Change LOV values dynamically
Enable/Disable/Hide fields dynamically.
Display user friendly messages when required.
Launch URL directly from oracle form.
Execute PL/SQL programs through FORM_DDL package.
Call custom libraries dynamically.
To create personalization for a particular function/form, first invoke the function/form in Oracle
applications.
Navigation: choose “Help -> Diagnostics -> Custom Code -> Personalize” from the pull down
Personalization Tables:-
All personalization’s that we have made to Oracle application forms will be stored in following
tables :
1. FND_FORM_CUSTOM_RULES
2. FND_FORM_CUSTOM_ACTIONS
3. FND_FORM_CUSTOM_SCOPES
4. FND_FORM_CUSTOM_PARAMS
5. FND_FORM_CUSTOM_PROP_LIST
6. FND_FORM_CUSTOM_PROP_VALUES
The Personalization form mainly contains four sections.
- Rules
- Conditions
- Context
- Actions
Rules:
- Contains Sequence, description of the rule. Level either Form or Function depends on requirement.
- Enable or Disable Rules using check box
Condition:
- Provide Trigger Event, Trigger Object, Sql statement in Condition.
- Processing mode: not in Enter-Query mode, only in Enter-Query mode or both
Context:
- Like profile options: Industry, Site, Responsibility, User
Actions:
- Property, Message, Builtin, Menu
1. Change Displayed data in LOV
Goal:
Change the LOV in “Supplier Name” field in the Find “Invoice Form (AP_APXINWKB)”
Navigation: Payables Manager > Entry > Invoices
Double Click it to open
In the first filed, Supplier Name change LOV In such a way that no one can see the TaxPayerID in LOV. It should be masked with *’s.
Navigation: Help Menu >> Diagnostics >> Custom Code >> Personalize
Enter the following information:
Seq: 5 Description: Disable Tax Payer Id
Level: Form Enabled: checked
Trigger Event: WHEN-NEW-FORM-INSTANCE
Processing Mode: Not in Enter-Query Mode
Click on Actions and enter the following.
Seq: 10 Type: Builtin Language: all
Builtin type: Create Record Group from Query
Argument:
SELECT vendor_name, vendor_number,
DECODE (active_flag, ‘Y’, ‘Yes’, ‘N’, ‘No’, ‘Yes’) active, ‘***’ num_1099,vat_registration_num, vendor_id, ”, ”, ”, ”, hold_all_payments_flag
FROM po_vendors_ap_v
WHERE num_active_pay_sites > 0 OR num_inactive_pay_sites > 0
ORDER BY UPPER (vendor_name)
Group Name: ERP_SCHOOLS_ALL_VENDORS_NAME
Now Create New Record with below information
Seq:12 Type: Property Language: All Enabled: Checked
Object Type: LOV
Target Object: INV_ALL_VENDORS_NAME
Property Name: GROUP_NAME
Value: ERP_SCHOOLS_ALL_VENDORS_NAME
Save it.
Click Validate
Click Apply Now.
Go to tools Menu >> click Validate All
Once it is successfully validated you are ready to go.
Click ok and close personalization form.
Close your find invoices form and invoices form completely.
Open it again and click on Supplier name field LOV
Query any supplier. You will see your changes to the LOV as shown below.
Now Taxpayer ID is shown as ***** instead of number
Q. Have you heard about Zoom function in Oracle Apps Forms?
Yes. It is CUSTOM.ZOOM_AVAILABLE function
Q. What is the use?
Generally the function CUSTOM.ZOOM_AVAILABLE was used for navigation from a block to another and it by default returns BOOLEAN value; False. It was used in earlier time in Oracle Apps. Now we are using Open_Form, Call_Form etc.
Ex: If Zoom is available for this block, then return TRUE; otherwise FALSE.Always test for the form and block name. Refer to the SYSTEM variables for form name and block name in your code and branch accordingly. The module name of your form must match the form file name.
By default this routine must return FALSE.
The following example enables Zooms in the following places:
Q. What is the sequence of Trigger firing in Form?
a) Pre-Form
Q. What is the process of Form registration in Oracle Apps?
Q. What is the default directory of Forms in Oracle Apps?
Application top(autop)/forms/US
Q.
System Administrator (Responsibility) > Security > Responsibility -> Define (at Menu) > Find Responsibility Name & The Menu attached to it > Exclusion > Exclude the Function of the Form
Q. How can you call DFF from Form?
By using a procedure called fnd_descr_flex.define
Ex: FND_DESCR_FLEX.DEFINE(BLOCK=>’ORDER_DETAIL’, FIELD=>’DESCFF’,
APPL_SHORT_NAME=>’FND’,
DESC_FLEX_NAME=>’MYDESC’)
Yes. It is CUSTOM.ZOOM_AVAILABLE function
Q. What is the use?
Generally the function CUSTOM.ZOOM_AVAILABLE was used for navigation from a block to another and it by default returns BOOLEAN value; False. It was used in earlier time in Oracle Apps. Now we are using Open_Form, Call_Form etc.
Ex: If Zoom is available for this block, then return TRUE; otherwise FALSE.Always test for the form and block name. Refer to the SYSTEM variables for form name and block name in your code and branch accordingly. The module name of your form must match the form file name.
By default this routine must return FALSE.
The following example enables Zooms in the following places:
Form: FNDSCAUS, Block USER and
Form: FNDCPMCP, Block PROCESS
FUNCTION zoom_available RETURN BOOLEAN IS
form_name VARCHAR2(30) := NAME_IN(‘system.current_form’);
block_name VARCHAR2(30) := NAME_IN(‘system.cursor_block’);
BEGIN
IF (form_name = ’FNDSCAUS’ AND block_name = ’USER’) OR
(form_name = ’FNDCPMCP’ AND block_name = ’PROCESS’)
THEN
RETURN TRUE;
ELSE
RETURN FALSE;
END IF;
END zoom_available;Q. What is the sequence of Trigger firing in Form?
a) Pre-Form
b) Pre-Block
c) Pre-Record
d) Pre-Text-Item
e) When-New-Form-Instance
f) When-New-Block-Instance
g) When-New-Record-Instance
h) When-New-Item-Instance
i) Post-Text-Item
j) Post-Record
k) Post-Block
l) Post-Form
Q. What is the process of Form registration in Oracle Apps?
- Send the file through FTP in binary mode to …/forms/US
- Generate *.fmx by running the fmx script
- f60gen module=<FORMNAME.fmb> userid=APPS/adm1n output_file=<FORMNAME.fmx> module_type=form batch=no compile_all=special
Q. What is the default directory of Forms in Oracle Apps?
Application top(autop)/forms/
System Administrator (Responsibility) > Security > Responsibility -> Define (at Menu) > Find Responsibility Name & The Menu attached to it > Exclusion > Exclude the Function of the Form
Q. How can you call DFF from Form?
By using a procedure called fnd_descr_flex.define
Ex: FND_DESCR_FLEX.DEFINE(BLOCK=>’ORDER_DETAIL’, FIELD=>’DESCFF’,
APPL_SHORT_NAME=>’FND’,
DESC_FLEX_NAME=>’MYDESC’)
In Brief,
We need to follow the following steps in your form:
a) Create a displayed field to hold your concatenated segment values (the [ ] field).
b) Create fields (normally hidden) for each of the flexfield columns in your table (the
a) Create a displayed field to hold your concatenated segment values (the [ ] field).
b) Create fields (normally hidden) for each of the flexfield columns in your table (the
one used for your flex).
c) In the form-level WHEN-NEW-FORM-INSTANCE,
c) In the form-level WHEN-NEW-FORM-INSTANCE,
call FND_DESCR_FLEX.DEFINE,
setting BLOCK parameter to the name of the block containing your [ ] field,
the FIELD parameter to the name of your [ ] field,
the APPL_SHORT_NAME parameter to the short name of your application and the DESC_FLEX_NAME parameter to the name of your descriptive flex.
In the form-level WHEN-NEW-ITEM-INSTANCE,
In the form-level WHEN-NEW-ITEM-INSTANCE,
WHEN-VALIDATE-ITEM,
PRE-INSERT,
PRE-UPDATE,
POST-QUERY and
PRE-QUERY triggers place a call to FND_FLEX.EVENT as follows:
FND_FLEX.EVENT ( 'TRIGGER_NAME');
where TRIGGER_NAME is the name of the trigger,
e.g. in the PRE-QUERY trigger .... FND_FLEX.EVENT('PRE-QUERY');where TRIGGER_NAME is the name of the trigger,
These days Form personalization is keyword and almost all developer and analyst working in oracle application must be aware and conversant with feature and how-to use this. I recommend to have good amount of practice on this. here i am presenting very brief overview and like to know if it useful need kind of tutorial kind of article.
Form Personalization in Oracle Applications
The Form Personalization feature allows you to declaratively alter the behavior of Forms-based screens, including changing properties, executing builtins, displaying messages, and adding menu entries.
For each function (a form running in a particular context based on parameters passed to it), you can specify one or more Rules. Each Rule consists of an Event, an optional Condition, the Scope for which it applies, and one or more Actions to perform. An Event is a trigger point within a form, such as startup (WHEN-NEW-FORM-INSTANCE), or when focus moves to a new record (WHEN-NEW-RECORD-INSTANCE). There are standard events that almost every form sends, and certain forms send additional product-specific events.The Scope is evaluated based on the current runtime context to determine if a Rule should be processed or not. The Scope can be at the Site, Responsibility, User, or Industry level. Each Rule can have one or more Scopes associated with it.
The Condition is an optional SQL code fragment that is evaluated when the Event occurs; if it evaluates to TRUE then the Actions are processed.
Each Action consists of one of the following:
· setting a Property, such as making a field Required or hiding a Tab page
· executing a Builtin, such as GO_BLOCK, DO_KEY or FND_FUNCTION.EXECUTE
· displaying a Message
· enabling a Special menu entry
Once Rules are defined, when the target function is run then the Rules are automatically applied as events occur within that form.Although the Form Personalization feature is declarative, the intended audience is a person familiar with Oracle Forms including the PL/SQL programming language, and the Oracle Applications Development Guide. Additionally, any change made could interfere with the base code of a form (the code that Oracle ships), thus the Support statements discussed later in this chapter must be followed diligently.
Using the Personalization Form
To create personalizations for a particular function, first invoke that function from the Navigation menu. While in the form, choose Help->Diagnostics->Custom Code-> Personalize from the pulldown menu. This menu entry is secured by the FND_HIDE_DIAGNOSTICS (Hide Diagnostics menu entry) and DIAGNOSTICS (Utilities:Diagnostics) profiles, as are most other entries on the Diagnostics menu.
The Personalization form will open and automatically query existing Rules for that function. After making changes, Save them then close and re-run the function to have them take effect. You can also Validate or Apply certain changes immediately to test them without having to re-run the target form by pressing the ‘Validate’ or ‘Apply Now’ buttons.
Why personalization?
Ø Oracle Supports personalization unlike customization
Ø Personalization are stored in tables rather than files
Ø Will not have a bigger impact when you upgrade or apply patches to the environment
Ø Can be moved easily through FNDLOAD from one instance to other
Ø Can be restricted at site/responsibility/user level
Ø Easy to disable/enable with click of a button.
Ø Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
Ø Can be applied to new responsibilities/users easily.
Ø Can be restricted to function or form.
What can be done through personalization?
Ø Zoom from one form to another
Ø Pass data from one form to another through global variables
Ø Change LOV values dynamically
Ø Enable/Disable/Hide fields dynamically
Ø Display user friendly messages when required
Ø Launch URL directly from oracle form
Ø Execute PL/SQL programs through FORM_DDL package
Ø Call custom libraries dynamically
Personalization Tables:
FND_FORM_CUSTOM_RULES
FND_FORM_CUSTOM_ACTIONS
FND_FORM_CUSTOM_SCOPES
FND_FORM_CUSTOM_PARAMS
FND_FORM_CUSTOM_PROP_LIST
FND_FORM_CUSTOM_PROP_VALUES
What Is Forms Personalization? Where It Is Used? What For?
Forms Personalization Is A Standard Feature Provided By Oracle And Supported By Oracle To Customize The Forms. With Forms Personalization You Can Hide Fiedls, Make Fields Mandatory, Create Zoom Functionality, Change Lov Dynamically E.T.C
What Are Different Triggers That Can Be Used In Personalization?
When-New-Form-Instance When-New-Block-Instance When-New-Record-Instance When-New-Item-Instance When-Validate-Record Menus Special Events
What Is The Difference Between Having Personalization At Function Level Rather Than Form Level?
A Form Can Have Multiple Functions. Having The Personalization At Function Level Limits The Scope Of The Personalization. For Example In Inventory For Both “Master Item Form” And “Organization Item Form” Uses Same Form Named Inviditm Where As Both Have Different Fucntions Linked To Them.
Can You Use Global Variables In Forms Personalization? If So How?
Yes.
Can You Hide A Text Field Using Personalization? How?
Yes. In The Actions Set Displayed Property To False.
Can You Transfer The Data From One Form To Another Form Using Personalization?
Yes. Using Global Variables.
How Do You Move Personalization From One Instance/Database To Other?
Form Personlizations Can Be Moved Easily Through Fndload From One Instance To Other. Refer To The Article Fndload For More Details:Http://Www.Erpschools.Com/Apps/Oracle-Applications/Articles/General/Fndload-To-Transfer-The-Menus-Concurrent-Programs-Personalization-From-One-Instance-To-Other/Index.Aspx
What Is Personalization And What Features Can Be Achieved Through Personalization?
Personalization Gives Us The Ability To Customize Forms In A Very Easy Manner. The Below Customizations Are Possible Through Personalization: Zoom From One Form To Another Pass Data From One Form To Another Through Global Variables Change Lov Values Dynamically Enable/Disable/Hide Fields Dynamically Display User Friendly Messages When Required Launch Url Directly From Oracle Form Execute Pl/Sql Programs Through Form_Ddl Package Call Custom Libraries Dynamically
At What Level You Can Restrict Personalization Code?
Form Level And Function Level
What Can Be Implemented Through Forms Personalization?
The Below Can Be Done Using Personalization: Zoom From One Form To Another Pass Data From One Form To Another Through Global Variables Change Lov Values Dynamically Enable/Disable/Hide Fields Dynamically Display User Friendly Messages When Required Launch Url Directly From Oracle Form Execute Pl/Sql Programs Through Form_Ddl Package Call Custom Libraries Dynamically
What Are The Advantages/Disadvantages Of Forms Personalization When Compared To Custom.Pll?
Advantages: Personalizations Are Stored In Tables Rather Than Files Will Not Have A Bigger Impact When You Upgrade Or Apply Patches To The Environment Can Be Moved Easily Through Fndload From One Instance To Other Can Be Restricted At Site/Responsibility/User Level Easy To Disable/Enable With Click Of A Button. Personalization Will Store Who Columns With Which We Have The Ability To Track Who Created/Modified It Where As In Custom.Pll We Don¿T Have That Ability. Disadvantages: Not All Can Be Customized Using Personalization.
When You Display A Error Message At When-Validate Trigger Will The Data Will Be Saved Into Database?
No. If It Is Normal Message Or Warning Data Will Be Saved But Not For Error Message.
3. What are the main differences between Forms Personalization when compared to personalization done through CUSTOM.pll?
Difference Between Forms Vs Custom.pll Personalization
Forms Personalization
- It is stored in tables
- It can be restricted at site/responsibility/user level
- It is easy to disable/enable with click of a button
- It is applied once you create personalization and re open the form.
- Functional/ Technical consultant can do it.
- It can be moved easily through FNDLOAD from one instance to other
- It is stored in tables which contain who columns with which we have the ability to track who created/modified it
Personalization through Custom.pll
- It is stored in files
- It is complicated in it
- In order to enable or disable, you need to change in custom.pll and recompile it
- It needs recompilation of custom.pll which involves mostly DBA involvement.
- It is migrated by migrating the custom.pll
- No such option available for custom.pll
Oracle forms have triggers that we trap to write our business logic. Oracle has a standard practice of calling a generic piece of code from each trigger(at form level). In this generic piece of code Oracle checks in personalization tables to see if anything extra needs to be done for the events being executed. For details of example, see the article for forms personalizations.
Just like any technology, forms personalization has its limitations. Limitation example of forms personalizations:
For example you wish to prompt a message to user DO YOU WISH TO CREATE THIS PERSON AS SUPPLIER OR CUSTOMER OR EMPLOYEE. Lets say this message will prompt three options, create customer , create supplier or create vendor. Depending upon what user selects, you wish to navigate to one of relevant screens from the current TCA screen. For this, you have no choice but to use CUSTOM.pll
For example you wish to prompt a message to user DO YOU WISH TO CREATE THIS PERSON AS SUPPLIER OR CUSTOMER OR EMPLOYEE. Lets say this message will prompt three options, create customer , create supplier or create vendor. Depending upon what user selects, you wish to navigate to one of relevant screens from the current TCA screen. For this, you have no choice but to use CUSTOM.pll
Personalization form automatically queries the function, form and pre-definedpersonalization rules, if any exists for the specific form. For example, the form name is INVTOMAI i.e. Move Order form on which the personalization form is opened.
Personalization Form
The Personalization form mainly contains four sections.
- Rules
- Conditions
- Context
- Actions
For each function (a form running in a particular context based on parameters passed to it), we can specify one or more Rules. Each Rule consists of an Event, an optional Condition, the Scope for which it applies, and one or more Actions to perform.
Rules administer the personalization needs to be implemented on the form. Each rule contains a sequence number, description and level (Rules may now be specified as acting either at the Function level (the default) or at the Form level). The rule can be activated or de-activated using the “Enabled” checkbox. The rule can be deleted when no longer needed.
Defining rules doesn’t identify, when the rule should get evaluated or applied. For each rule, there should be conditions attached, which power the execution of the rule.
Conditions decide the event the rule to be executed. Each condition mainly contains three sections i.e. Trigger Event, Trigger Object and Condition.
Condition Tab with Trigger events
Trigger Event specifies the occurrence where the rule should be executed.
Trigger Object is the object on the form to determine at what level the rule should be executed. The value can be “” or “- ”
Condition is an optional SQL code fragment that is evaluated when the Event occurs; if it evaluates to TRUE then the Actions are processed.
Processing Mode is a pop-list which controls when the Rule should be processed i.e., Rules can be applied while not in Enter-Query mode (the default), only in Enter-Query mode, or in both modes.
Context manages to whom the personalization should apply. This is similar to the concept of using profile options in Oracle Applications. The various levels are Site, Responsibility, Industry and User. During runtime, the values provided in the context are evaluated andpersonalization rules will be applied. Usage of context is very vital in implementing thepersonalization to prevent the inappropriate users accessing these customizations of the form.
Context levels
While saving a Rule, if no Context rows have been entered the form will automatically create a row at the Site level.
Actions decide the exact operation to be performed when the event occurs and the condition evaluates to true during the runtime.
Each Action consists of one of the following:
- setting a Property
- displaying a Message
- executing a Builtin
- enabling a Menu/Special entry
Action Types
Each action contains a sequence number, description and language. Actions can be enabled, disabled or deleted. Based on the action type selected, the fields on the right sector of the actions tab will be refreshed, where the action parameters are entered.
Insert 'Get' Expression… button can be used to automatically construct the expression.
Insert Item Value… button can be used to consider the item name along with colon (:)
Example :TOMAI_MAIN_HEADER_BLK.REQUEST_NUMBER
Validate used to test if the syntax of your string is valid. If the evaluation fails, the processing engine will return an ORA error as if the string had been part of a SQL expression. Otherwise, it will display the text exactly as it would appear at runtime in the current context.
Apply Now used to apply the changes immediately to the target form to test its effect
Property
The action type “Property” is used to set the properties of the objects. The various objects include “Item, Window, Block, Global Variable etc”.
Property Type
Select By Text button used to select an object based on text appearing on the screen atthe point in time, the Personalization form is invoked, including any changes that current rules might have performed. Target Object can be selected from the list.
Target Object, either name defined in the form or variable name should be entered depending on the object type selected.
Property Name is the property to be changed.
Value is the new desired value for the property.
The current value of the property will be displayed when clicked on the Get Valuebutton.
SQL functions and operators can be used to assign value. Any value started with “=” operator will be evaluated at runtime otherwise the value is treated as is entered in the value field.
Message
The action type “Message” is used to display custom messages during runtime. MessageType and Message Text should be entered after selecting the action type as “Message”. The available message types are “Show, Hint, Error, Debug and Warn”.
Message Type
Builtin
The action type “Builtin” is used to execute the form and AOL functions. Depending on the builtin type selected, the arguments should be entered.
Builtin Type
Add Parameter… list of Values displays currently used parameters. Applies to the builtin ‘Launch a Function’ only.
Menu
The action type “Menu” is used to activate the available special menus on the Tools menu. Oracle Applications provide 45 special menus under Tools menu which can be used by customers based on their requirements. The menus are arranged in 3 sets of 15 each under the Tools, Reports and Actions pull-down menus. If you select a menu that the base form is already using, your functionality will override the form's functionality.
Select the Menu Entry which is not used by the form.
Menu Label is the prompt which appears to the users when Tools menu is invoked.
Icon name is the .ico file name.
Enabled in Block(s) specifies the blocks for which the special menu should beactivated.
Menu Type
A separator can be created above the activated special menu by selecting the “Render line before menu” checkbox.
This property can be used only in WHEN-NEW-FORM-INSTANCE event.
With the Oracle E-Business Suite release 11.5.10, the Oracle has introduced a mechanism which revolutionizes the way the forms can be customized to fulfill the customer needs. For many years, Oracle Applications has provided a custom library using which the look and behavior of the standard forms can be altered, but the custom library modifications require extensive work on SQL and PL/SQL. In the release 11.5.10, Oracle has provided a simple and easy feature to implement the customer specific requirements without modifying the underlying forms code or CUSTOM library. Although CUSTOM library still can be used for forms customization to implement the complex business logic, the personalization feature provided in the latest release is easy, faster and requires minimum development effort.
FND_FORM_CUSTOM_ACTIONS
FND_FORM_CUSTOM_SCOPES
FND_FORM_CUSTOM_PARAMS
FND_FORM_CUSTOM_PROP_LIST
FND_FORM_CUSTOM_PROP_VALUES
The personalization form is invoked by…
Menu Navigation: Help > Diagnostics > Custom Code > Personalize
Why Forms Personalization?
- Oracle Supports personalization unlike customization.
- Personalizations are stored in tables rather than files.
- Will not have a bigger impact when you upgrade or apply patches to the environment.
- Can be moved easily through FNDLOAD from one instance to other.
- Can be restricted at site/responsibility/user level.
- Easy to disable/enable with click of a button.
- Personalization stores who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
- Can be applied to new responsibilities/users easily.
- Can be restricted to a function or form.
What can be implemented through Forms Personalization?
The below can be done using Personalization:- Zoom from one form to another.
- Pass data from one form to another through global variables.
- Change LOV values dynamically.
- Enable/Disable/Hide fields dynamically
- Display user friendly messages when required
- Launch URL directly from oracle form
- Execute PL/SQL programs through FORM_DDL package
- Call custom libraries dynamically
Personalization Tables:
FND_FORM_CUSTOM_RULESFND_FORM_CUSTOM_ACTIONS
FND_FORM_CUSTOM_SCOPES
FND_FORM_CUSTOM_PARAMS
FND_FORM_CUSTOM_PROP_LIST
FND_FORM_CUSTOM_PROP_VALUES
Invoking the Personalization screen:
The personalization form should be used to implement the custom rules on a specific form. The specific form refers to the desired form on which you want to apply the custom business logic or modify the form behavior.The personalization form is invoked by…
Menu Navigation: Help > Diagnostics > Custom Code > Personalize
Disable the personalization feature:
It is possible that a change you make completely breaks a form, to the point that it will not even run! Here’s how to recover:- On the pulldown menu, choose Help > Diagnostics > Custom Code > Off
- This will disable all callouts to Forms Personalization
- Run the form of interest
- It should run now, because your changes were skipped
- Invoke the Personalization screen and correct the problem
- On the pulldown menu, choose Help > Diagnostics > Custom Code > Normal to re-enable processing of Personalizations
Limitations:
Although it is faster than a speeding bullet, it is not able to leap over tall buildings:- You can only change what Forms allows at runtime:
- Cannot create new items
- Cannot move items between canvases
- Cannot display an item which is not on a canvas
- Cannot set certain properties
- Cannot change frames, graphics, boilerplate
- You can only respond to certain Trigger Events:
- WHEN-NEW-FORM-INSTANCE, WHEN-NEW-BLOCK-INSTANCE, WHEN-NEW-RECORD-INSTANCE, WHEN-NEW-ITEM-INSTANCE
- WHEN-VALIDATE-RECORD (not in all forms)
- Product-specific events
- May interfere with, or be overridden by, base product code
- Expected user is an Admin/Developer
- Knowledge of Oracle Developer is extremely desirable
- Knowledge of PL/SQL, Coding Standards and/or APIs required in some cases
- Normal rules for customizations apply
- Extensive testing in a Test environment is required!
Relationship with CUSTOM library:
- CUSTOM is a stub library Oracle ships that receives Trigger Events. Customers are free to add any code they like to it.
- CUSTOM and Form Personalizations drive off the same Trigger Events.
- Form Personalizations are processed first, then the event is sent to CUSTOM
- CUSTOM can do more because it has complete access to all PL/SQL and SQL.
- But for most changes, Form Personalizations is adequate and is significantly simpler.
Why personalization?
* Oracle Supports personalization unlike customization
* Personalizations are stored in tables rather than files
* Will not have a bigger impact when you upgrade or apply patches to the environment
* Can be moved easily through FNDLOAD from one instance to other
* Can be restricted at site/responsibility/user level
* Easy to disable/enable with click of a button.
* Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
* Can be applied to new responsibilities/users easily.
* Can be restricted to function or form.
What can be done through personalization?
* Zoom from one form to another
* Pass data from one form to another through global variables
* Change LOV values dynamically
* Enable/Disable/Hide fields dynamically
* Display user friendly messages when required
* Launch URL directly from oracle form
* Execute PL/SQL programs through FORM_DDL package
* Call custom libraries dynamically
What is Forms Personalization? Where it is used? What For?
Forms Personalization is a standard feature provided by oracle and supported by oracle to customize the forms. With Forms personalization you can hide fiedls, make fields mandatory, create zoom functionality, change lov dynamically e.t.c
What are different triggers that can be used in personalization?
WHEN-NEW-FORM-INSTANCE WHEN-NEW-BLOCK-INSTANCE WHEN-NEW-RECORD-INSTANCE WHEN-NEW-ITEM-INSTANCE WHEN-VALIDATE-RECORD MENUS SPECIAL EVENTS
Can you use global variables in forms personalization? If so How?
Yes.
Can you hide a text field using personalization? How?
Yes. In the actions set DISPLAYED property to false.
Can you transfer the data from one form to another form using personalization?
Yes. Using global Variables.
At what level you can restrict personalization code?
FORM level and FUNCTION level
* Oracle Supports personalization unlike customization
* Personalizations are stored in tables rather than files
* Will not have a bigger impact when you upgrade or apply patches to the environment
* Can be moved easily through FNDLOAD from one instance to other
* Can be restricted at site/responsibility/user level
* Easy to disable/enable with click of a button.
* Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
* Can be applied to new responsibilities/users easily.
* Can be restricted to function or form.
What can be done through personalization?
* Zoom from one form to another
* Pass data from one form to another through global variables
* Change LOV values dynamically
* Enable/Disable/Hide fields dynamically
* Display user friendly messages when required
* Launch URL directly from oracle form
* Execute PL/SQL programs through FORM_DDL package
* Call custom libraries dynamically
What is Forms Personalization? Where it is used? What For?
Forms Personalization is a standard feature provided by oracle and supported by oracle to customize the forms. With Forms personalization you can hide fiedls, make fields mandatory, create zoom functionality, change lov dynamically e.t.c
What are different triggers that can be used in personalization?
WHEN-NEW-FORM-INSTANCE WHEN-NEW-BLOCK-INSTANCE WHEN-NEW-RECORD-INSTANCE WHEN-NEW-ITEM-INSTANCE WHEN-VALIDATE-RECORD MENUS SPECIAL EVENTS
Can you use global variables in forms personalization? If so How?
Yes.
Can you hide a text field using personalization? How?
Yes. In the actions set DISPLAYED property to false.
Can you transfer the data from one form to another form using personalization?
Yes. Using global Variables.
At what level you can restrict personalization code?
FORM level and FUNCTION level
Oracle has provided a simple and easy feature to implement the customer specific requirements without modifying the underlying forms code or CUSTOM library. Although CUSTOM library still can be used for forms customization to implement the complex business logic, the personalization feature provided in the latest release is easy, faster and requires minimum development effort.
If user needs to personalize any details in a form like changing field names, adding some validations, etc, then Form Personalization can provide the way out in few simple steps.
Please follow here to go through Steps with example
Steps:
Step – 1:
Go to the specific form where you need the changes
Then we need to note down the block and field name which is needed in next steps.
So keep the cursor on the required field and then Go to Help --> Diagnostics -->Examine
Note down the Block and Field value.
Step -2:
Now the step to do the personalization
Follow this navigation
Help à Diagnostics à Custom Code à Personalize
This will show the Form Personalization window
Here you need to do the customization as per the requirement.
As you can see in this form, there are mainly 4 sections
1. Rule
2. Condition
3. Actions
4. Context
Step – 3:
Rule:
This is the section where you need to create the rules how your requirement is going to be executed. This section contains 4 segments, Seq, description, Level and Enabled flag.
Seq : Need to give the Sequence how the rule will execute (a number)
Description: Write a sort description of the rule which you are going to create
Level: Select the level where you want the rule to execute
Enabled: This is the flag which will enable or disable the rule.
Example:
Step – 4:
Condition:
Now need to set the condition.
This is the section where you will define when the rule will be executed.
This section contains 4 segments, Trigger Event, Trigger Object, Condition and Processing mode.
Trigger Event: This specifies where the rule will be executed. There are mainly 5 types of event which decided the trigger of the rule.
Trigger Object: This is the Object in the form which decides at what level the rule will be executed.
The values can be “<Form Name>”, ‘<Block Name>” or “<Item Name>”
Condition: Here mention any SQL statement to control the execution of the rule when the mentioned criterion is met.
Processing Mode: This is the mode where you want the rules to be executed.
Example:
Step – 5:
Actions:
This decides what will happen when the rule will execute.
This contains 2 sections.
Left sections contains Seq, Type, Description, Language, Enabled
Seq: Mention the Action sequence which this rule will execute
Type: This is of 4 types, Property, Message, Builtin, Menu.
This decides which type of action, the rule will perform.
According to this the right section will come and need to fill the detailed actions.
Description: Write a description on the action which this will perform.
Language: Select the language
Enabled: You can enable or disable the actions here.
Right Section is a dynamic section; it appears depending on the Type field value in Left section.
Action Types:
Property
The action type “Property” is used to set the properties of the objects. The various objects include
“Item, Window, and Block etc.”. Actual object name defined in the form should be entered after selecting the object type.
Property Name is the property to be changed
Value is the new desired value for the property.
The current value of the property will be displayed when clicked on the “Get Value” button.
Example:
Object Type = “Item”
Target Object = “:ORDER.ORDER_NUMBER”
Property Name = “PROMPT_TEXT”
Value = “Claim Number”
The value is interpreted at runtime, so you can use SQL functions and operators. Any value started with “=” operator will be interpreted at runtime; otherwise the value is treated as is entered in the value field
Message:
The action type “Message” is used to display custom messages during runtime. Message Type and Description should be entered after selecting the action type as “Message”. The available message types are “Error, Warning, Hint, Question and Debug”. Depending on the response expected from the user, the appropriate message type should be selected.
Example:
Message Type = “Hint”
Message Text = “Please Follow the Date format DD-MON-YYYY”
Builtin:
The action type “Builtin” is used to execute the form and AOL API’s. Depending on the API type selected, the parameters should be entered.
Example:
Builtin Type = FND_UTILITIES.OPEN_URL
Argument = http://www.oracle.com
Menu:
The action type “Menu” is used to activate the available special menus on the Tools menu.
Oracle Applications provide 45 special menus under Tools menu which can be used by customers based on their requirements.
Select the SPECIAL menu which is not used by the form. Menu label is the prompt which appears to the users when Tools menu is invoked, block specifies the blocks for which the special menu should be activated and Icon name is the .ico file name.
A separator can be created above the activated special menu by selecting the “Render line before menu” checkbox.
Example:
Menu Entry = SPECIAL4
Menu Label = Additional Order Header Information
Enabled in Blocks(s) = ORDER
Icon Name = Flower.ico
Step – 6:
Context:
Context manages to whom the personalization should apply. This is similar to the concept of using profile options in Oracle Applications. The various levels are Site, Responsibility, Industry and User. During runtime, the values provided in the context are evaluated and personalization rules will be applied. Usage of context is very vital in implementing the personalization to prevent the inappropriate users accessing these customizations of the form.
Example:
Context = Responsibility
Value = Order Management Super User
STEP BY STEP ANALYSIS
Requirement: Don’t allow the user to use more than 1 qty in Order line Qty field during creation of a sales order.
Solution:
Step -1:
Go to the specific form where you need the changes
Here in this case this will be the Sales Orders form and then Line Items tab.
Then we need to note down the block and field name which is needed in next steps.
So keep the cursor on the required field and then Go to Help à Diagnostics à Examine
Note down the Block and Field value.
Step -2:
Help --> Diagnostics --> Custom Code --> Personalize
Step – 3:
Fill the Rule section
Step – 4:
Fill the Condition section
Step – 5:
Fill the Actions section
Step – 6:
Fill the context As you need.
Save this.
Log out of the application and login again, then in Sales Order line item tab enter Qty field value as 1 and try to save, you can see the message.
It is indeed time to stop using CUSTOM.pll
If you are on 11.5.10, then it is important for development team to enforce the usage of Forms Personalization over CUSTOM.pll, where possible.
Most of the things that can be done using CUSTOM.pll can now be done via Forms Personalization.
However there are certain gaps for which we have no option but to rely on CUSTOM.pll
This article compares the two techniques i.e. CUSTOM.pll versus Forms Personalizations
Why should we prefer FP over CUSTOM.pll ?1. CUSTOM.pll is a single file/entity, hence only one developer can make changes to CUSTOM.pll at any given point in time.
You may also read best practices in CUSTOM.pll at this link
2. If for some reasons CUSTOM.pll causes issues in Production, you will have to re-release the code changes after another round of UAT.
Form Personalizations makes this much simpler by allowing you to disable specific personalizations.
3. You do not need to resort to programming for trivial tasks like changing prompt, and more so for changing prompts in Muli-Lang environment
Lets do a quick comparison between Forms Personalization and CUSTOM.pll
Important: Oracle will keep on improving capabilities in Forms Personalizations.
Hence some of these limitations that we see now in Forms Personalization might disappear over a period of time.
Note-1
Once a menu has been enabled using Forms Personalization, it then can not be conditionally disabled. However the proposed workaround over this issue is to display a message when MENU is clicked in the scenario’s it was meant to be disabled.
Note-2
Lets say you want to change the window title for all the screens within a responsibility. In this case, in CUSTOM.pll you could do so by a pseudo code similar to below
If fnd_global.responsibility like ‘XX%CASH%’ THEN
Set window title ( ‘Note: All transactions are audited’);
End if
As you can see, this can be achieved quite easily in CUSTOM.pll and the changes will be visible across multiple screens in the context.
However, for Forms Personalization, you will have to go and personalize each and every screen for which you want this change to be effective.
Note-3
The proposed workaround is to display the message that is returned as a result from SQL Statement.
Time for some Q&A
Question: Should we migrate code from CUSTOM.pll into Forms Personalization?
Not really, there is no value in doing so, given that CUSTOM.pll is still supported and will remain so within the realms of Apps Unlimited.
Where is the metadata for Forms Personalization stored?
These personalizations are stored in FND tables
What is called first? Forms Personalization or CUSTOM.pll
First your form personalization is called, and then CUSTOM.pll is called.
Is forms personalization called for additional set of triggers vis-Ã -vis CUSTOM.pll?
Not really, the same set of triggers are passed to both CUSTOM.pll and Forms Personalization. To understand the fundamentals, visit this link CUSTOM.pll concepts
If you are on 11.5.10, then it is important for development team to enforce the usage of Forms Personalization over CUSTOM.pll, where possible.
Most of the things that can be done using CUSTOM.pll can now be done via Forms Personalization.
However there are certain gaps for which we have no option but to rely on CUSTOM.pll
This article compares the two techniques i.e. CUSTOM.pll versus Forms Personalizations
Why should we prefer FP over CUSTOM.pll ?1. CUSTOM.pll is a single file/entity, hence only one developer can make changes to CUSTOM.pll at any given point in time.
You may also read best practices in CUSTOM.pll at this link
2. If for some reasons CUSTOM.pll causes issues in Production, you will have to re-release the code changes after another round of UAT.
Form Personalizations makes this much simpler by allowing you to disable specific personalizations.
3. You do not need to resort to programming for trivial tasks like changing prompt, and more so for changing prompts in Muli-Lang environment
Lets do a quick comparison between Forms Personalization and CUSTOM.pll
Task/Business Requirement
|
CUSTOM.pll
|
Forms Personalization
|
Change LOV Query
|
Yes
|
Yes
a. Create a New Record Group
b. Attach new RG to LOV
|
Change field properties like Mandatory/Display etc
|
Yes
|
Yes
|
Zoom to another screen
|
Yes
|
Yes
a. Enable Menu
b. Trap the Menu event |
Disable a Menu entry when certain conditions are met
|
Yes
|
No
See Note-1 |
Display messages, warnings, hints etc
|
Yes
|
Yes
|
Display message with Questions, and conditionally execute code based on users response to the question
|
Yes
|
No
|
Execute PL/SQL Stored procedures
|
Yes
|
Yes
|
Change Navigation and Navigational Properties
|
Yes
|
Yes
|
Change block properties like “Query Where Clause†etc
|
Yes
|
Yes
|
Change is applicable across multiple screens, like Changing window title for all screens within one Organization/Responsibility
|
Yes
|
Yes
See Note-2 |
Show FND Messages with their tokens replaced
|
Yes
|
See Note-3
|
Important: Oracle will keep on improving capabilities in Forms Personalizations.
Hence some of these limitations that we see now in Forms Personalization might disappear over a period of time.
Note-1
Once a menu has been enabled using Forms Personalization, it then can not be conditionally disabled. However the proposed workaround over this issue is to display a message when MENU is clicked in the scenario’s it was meant to be disabled.
Note-2
Lets say you want to change the window title for all the screens within a responsibility. In this case, in CUSTOM.pll you could do so by a pseudo code similar to below
If fnd_global.responsibility like ‘XX%CASH%’ THEN
Set window title ( ‘Note: All transactions are audited’);
End if
As you can see, this can be achieved quite easily in CUSTOM.pll and the changes will be visible across multiple screens in the context.
However, for Forms Personalization, you will have to go and personalize each and every screen for which you want this change to be effective.
Note-3
The proposed workaround is to display the message that is returned as a result from SQL Statement.
Time for some Q&A
Question: Should we migrate code from CUSTOM.pll into Forms Personalization?
Not really, there is no value in doing so, given that CUSTOM.pll is still supported and will remain so within the realms of Apps Unlimited.
Where is the metadata for Forms Personalization stored?
These personalizations are stored in FND tables
What is called first? Forms Personalization or CUSTOM.pll
First your form personalization is called, and then CUSTOM.pll is called.
Is forms personalization called for additional set of triggers vis-Ã -vis CUSTOM.pll?
Not really, the same set of triggers are passed to both CUSTOM.pll and Forms Personalization. To understand the fundamentals, visit this link CUSTOM.pll concepts
Form Personalization and CUSTOM.PLL are two utilities provided by Oracle E-Business suite to alter the standard behaviour of user interfaces. They are handy to perform tasks such as disabling the fields, implement zoom functionality, change caption (prompt) values, display custom message and create custom menus for a particular form. CUSTOM.PLL and form personalization both are equally capable to change the working process of all the modules. Yet they still have minor differences which surpass the power of one over the other depending on the situation.
PLL in CUSTOM.PLL stands for programming link library provided in Oracle E-Business Suite package to modify the standard working of a function using PL/SQL programming language while form personalization accomplishes the same thing using a fairly easy user interface.
The difference in CUSTOM.PLL and form personalization is one of the widely asked interview questions. Oracle E-business Suite developers prepares for it thoroughly before Oracle Apps interviews.
Difference between Form Personalization and CUSTOM.PLL
Form Personalization
|
CUSTOM.PLL
|
| Form Personalization is a graphical user interface | CUSTOM.PLL is a programming linked library |
| Multiple developers can work simultaneously in the form personalization activity | Only one developer can work in CUSTOM.PLL if an ideal version maintenance process is followed |
| PL/SQL programming knowledge is a must to perform tasks such as disabling the fields, changing the prompts etc. | No need of programming knowledge to disable fields, change prompts etc. |
| Form personalization changes can be previewed using Validate button | CUSTOM.PLL changes preview is not possible. The library needs to be compiled every time you make changes |
| You have to visit multiple forms equally multiple times to disable form personalization | All the codes of CUSTOM.PLL can be commented at once |
| Multiple choices of action message box are not possible with form personalization | Multiple choices of actions message box can be created using CUSTOM.PLL |
| Module-specific form personalization is not possible | Module specific CUSTOM.PLL changes such as XXCUSTOMPO.PLL or XXCUSTOMAR.PLL is possible |
| Easier to implement than CUSTOM.PLL | Requires UAT testing, impact analysis and re-release of CUSTOM.PLL in case of errors in the same |
| A menu cannot be disabled conditionally in the form personalization | Menu can be disabled conditionally through CUSTOM.PLL |
| Form Personalization has less precedence over CUSTOM.PLL | CUSTOM.PLL has more precedence over form personalization |
http://www.erpschools.com/articles/forms-personalization-tutorial
http://www.learnoracle.in/2012/11/form-personalization-in-oracle-apps.html
Why personalization?
- Oracle Supports personalization unlike customization
- Personalizations are stored in tables rather than files
- Will not have a bigger impact when you upgrade or apply patches to the environment
- Can be moved easily through FNDLOAD from one instance to other
- Can be restricted at site/responsibility/user level
- Easy to disable/enable with click of a button.
- Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.
- Can be applied to new responsibilities/users easily.
- Can be restricted to function or form.
What can be done through personalization?
- Zoom from one form to another
- Pass data from one form to another through global variables
- Change LOV values dynamically
- Enable/Disable/Hide fields dynamically
- Display user friendly messages when required
- Launch URL directly from oracle form
- Execute PL/SQL programs through FORM_DDL package
- Call custom libraries dynamically
Zoom Functionality through Forms Personalization
What is Zoom?
Directly going from one form to another form with click of a button is called zoom functionality in oracle applications. This can be done in different ways. Firstly, We can just call the second form and then leave it for user to enter the data. Second way is call the second form from first and then dynamically populate the data in second form based on first forms data.
How to implement Zoom functionality?
In this tutorial we will zoom from Order Organizer form to Shipping transactions form and also populate the order number dynamically in destination form.
Know the following things before you start
- Know the names of source form and destination form
- If you need to populate the data dynamically know what fields that you need to populate.
- Global Variables: These variables can be initialized in any form and can be used in any form all over the applications
- Trigger & Action: trigger is an event and action is operation/execution that we do. When an event occurs we do operation/execution
Source form: Order Organizer form ( )
Destination form: Shipping transactions form (WSHFSTRX)
Source field: Order number ()
Destination field1: Order number low (QM_DLVB.DLVB_SOURCE_HEADER_NUMBER_LO)
Destination field2: Order number high (QM_DLVB.DLVB_SOURCE_HEADER_NUMBER_HI)
Destination field3: Line Status (QM_DLVB.DLVB_LINE_RELEASED)
Process flow:
- Initialize the menu/icon in source form
- Initialize the global variables
- When the menu/icon is clicked copy the order number from source form filed to global variable and then launch the destination form
- In the destination form copy the value from global variable to destination form field.
Initialize the menu/icon in source form
Navigation: Order Management Super User > Orders, Returns > Order Organizer
Navigation: Help > Diagnostics > Custom Code > Personalize
Follow the screenshots
Personalization in Destination Form
Form Personalization
Oracle has provided a simple and easy feature to implement the customer specific requirements without modifying the underlying forms code or CUSTOM library. Although CUSTOM library still can be used for forms customization to implement the complex business logic, the personalization feature provided in the latest release is easy, faster and requires minimum development effort.
If user needs to personalize any details in a form like changing field names, adding some validations, etc, then Form Personalization can provide the way out in few simple steps.
Please follow here to go through Steps with example
Steps:
Step – 1:
Go to the specific form where you need the changes
Then we need to note down the block and field name which is needed in next steps.
So keep the cursor on the required field and then Go to Help -->Diagnostics --> Examine
Note down the Block and Field value.
Step -2:
Now the step to do the personalization
Follow this navigation
Help à Diagnostics à Custom Code à Personalize
This will show the Form Personalization window
Here you need to do the customization as per the requirement.
As you can see in this form, there are mainly 4 sections
1. Rule
2. Condition
3. Actions
4. Context
Step – 3:
Rule:
This is the section where you need to create the rules how your requirement is going to be executed. This section contains 4 segments, Seq, description, Level and Enabled flag.
Seq : Need to give the Sequence how the rule will execute (a number)
Description: Write a sort description of the rule which you are going to create
Level: Select the level where you want the rule to execute
Enabled: This is the flag which will enable or disable the rule.
Example:
Step – 4:
Condition:
Now need to set the condition.
This is the section where you will define when the rule will be executed.
This section contains 4 segments, Trigger Event, Trigger Object, Condition and Processing mode.
Trigger Event: This specifies where the rule will be executed. There are mainly 5 types of event which decided the trigger of the rule.
Trigger Object: This is the Object in the form which decides at what level the rule will be executed.
The values can be “<Form Name>”, ‘<Block Name>” or “<Item Name>”
Condition: Here mention any SQL statement to control the execution of the rule when the mentioned criterion is met.
Processing Mode: This is the mode where you want the rules to be executed.
Example:
Step – 5:
Actions:
This decides what will happen when the rule will execute.
This contains 2 sections.
Left sections contains Seq, Type, Description, Language, Enabled
Seq: Mention the Action sequence which this rule will execute
Type: This is of 4 types, Property, Message, Builtin, Menu.
This decides which type of action, the rule will perform.
According to this the right section will come and need to fill the detailed actions.
Description: Write a description on the action which this will perform.
Language: Select the language
Enabled: You can enable or disable the actions here.
Right Section is a dynamic section; it appears depending on the Type field value in Left section.
Action Types:
Property
The action type “Property” is used to set the properties of the objects. The various objects include
“Item, Window, and Block etc.”. Actual object name defined in the form should be entered after selecting the object type.
Property Name is the property to be changed
Value is the new desired value for the property.
The current value of the property will be displayed when clicked on the “Get Value” button.
Example:
Object Type = “Item”
Target Object = “:ORDER.ORDER_NUMBER”
Property Name = “PROMPT_TEXT”
Value = “Claim Number”
The value is interpreted at runtime, so you can use SQL functions and operators. Any value started with “=” operator will be interpreted at runtime; otherwise the value is treated as is entered in the value field
Message:
The action type “Message” is used to display custom messages during runtime. Message Type and Description should be entered after selecting the action type as “Message”. The available message types are “Error, Warning, Hint, Question and Debug”. Depending on the response expected from the user, the appropriate message type should be selected.
Example:
Message Type = “Hint”
Message Text = “Please Follow the Date format DD-MON-YYYY”
Builtin:
The action type “Builtin” is used to execute the form and AOL API’s. Depending on the API type selected, the parameters should be entered.
Example:
Builtin Type = FND_UTILITIES.OPEN_URL
Argument = http://www.oracle.com
Menu:
The action type “Menu” is used to activate the available special menus on the Tools menu.
Oracle Applications provide 45 special menus under Tools menu which can be used by customers based on their requirements.
Select the SPECIAL menu which is not used by the form. Menu label is the prompt which appears to the users when Tools menu is invoked, block specifies the blocks for which the special menu should be activated and Icon name is the .ico file name.
A separator can be created above the activated special menu by selecting the “Render line before menu” checkbox.
Example:
Menu Entry = SPECIAL4
Menu Label = Additional Order Header Information
Enabled in Blocks(s) = ORDER
Icon Name = Flower.ico
Step – 6:
Context:
Context manages to whom the personalization should apply. This is similar to the concept of using profile options in Oracle Applications. The various levels are Site, Responsibility, Industry and User. During runtime, the values provided in the context are evaluated and personalization rules will be applied. Usage of context is very vital in implementing the personalization to prevent the inappropriate users accessing these customizations of the form.
Example:
Context = Responsibility
Value = Order Management Super User
Step by Step Analysis
Requirement: Don’t allow the user to use more than 1 qty in Order line Qty field during creation of a sales order.
Solution:
Step -1:
Go to the specific form where you need the changes
Here in this case this will be the Sales Orders form and then Line Items tab.
Then we need to note down the block and field name which is needed in next steps.
So keep the cursor on the required field and then Go to Help à Diagnostics àExamine
Note down the Block and Field value.
Step -2:
Help --> Diagnostics --> Custom Code --> Personalize
Step – 3:
Fill the Rule section
Step – 4:
Fill the Condition section
Step – 5:
Fill the Actions section
Step – 6:
Fill the context As you need.
Save this.
Log out of the application and login again, then in Sales Order line item tab enter Qty field value as 1 and try to save, you can see the message.
hyper personalization in retail
ReplyDeleteBanks have a dual challenge today – a demanding customer and a whole new set of competitors. User experiences in e-commerce and other industries with digital offerings are so seamlessly designed that today’s customer sees that as the norm.