When it comes to doing forms personalizations in Oracle's eBusiness Suite, it is good to follow certain guidelines.
We all know that forms personalization create a layer of customization on top of the standard Apps D2K Forms.
The Metadata related to forms personalizations is stored in tables FND Tables.
Please find a list of guidelines can be regarded as the best practices when it comes to doing forms personalizations in Oracle Apps.
In case you wish to see different examples of forms personalizations, then please visit link following links
Various examples on Oracle Forms Personalizations
An example for implementation of Oracle Forms Personalizations in HRMS
Comparison between CUSTOM.pll and Forms Personalization in Oracle
Anyway, lets have a look through some of the best practices for Forms Personalizations.
Global Variable Names
All the global variables defined must begin with XX.
This will ensure there is no conflict with global variables that are defined by Oracle’s development team.
You must always use FNDLOAD to transfer Forms Personalizations from one environment to another. However see below point too, which is very relevant to FNDLOAD
Decide a master environment
Decide a master environment onto which all the forms personalization will be entered prior to scripting & patching those personalization using
If "Functional Team" makes changes to TST Environment and then the "Development Team" makes changes to DEV Environment for the same form, then, changes done to TST Environment will be lost when FNDLOAD extract from DEV is uploaded onto TST.
Usually developers make their personalization changes to DEV environment, Functional team makes their changes to TEST/UAT environments and Support team sometimes tends to make their FNDLOAD changes straight into production[ I mean without using FNDLOAD]. This is a bad practice. Do not make any Forms Personalization changes manually onto production.
Decide an environment onto which developers, functional personnel & support staff will manually key in their personalization.
Use this as a master environment to download the Forms Personalizations using FNDLOAD.
To create new Tool Menus, always use MENU1-MENU15, as Oracle guarantees never to use these during development. Same is not true for SPECIAL Menus, as Oracle development may release a patch utilising the same SPECIALx as you may have personalized. MENU1..15 is available starting from 11.5.10 CU2 onwards
Remember the sequence
Keep in mind that “Forms Personalization” code fires prior to CUSTOM.pll code [in case you have the same form extended in both the places].
Use local variables when its usage is restricted to one single form
If a variable scope is limited to single form which is being personalized, then do not unnecessarily create a GLOBAL Variable.
Clear Global Variables once they have been used
Use global variables when you wish to integrate two different screens using Forms Personalizations. In other words global variable act like a bridge between two forms [of course apart from parameters]
Make sure you clear off the GLOBAL Variables after their usage is finished. This will ensure that screen works under normal scenarios too.
Before reporting a bug/SR in Forms via Metalink, reproduce the issue by disabling customizations
The Forms Personalizations can be disabled by turning the custom code off.
Before reporting any form related bug to Oracle, try reproducing the issue by turning Custom Code off
Identify the best possible triggers to use for personalizations
See this link that explains how to recognise the best trigger to trap for forms personalization.
Both forms personalization and CUSTOM.pll are fed the same set of triggers in Forms.
That’s all that I can think off. If you wish to share your experience of best practices, then please feel to add your experience in the comment section.