For reader not yet familiar with Form Personalization, here is some summary information: SECURING ACCESS AND

D TESTING When using Form Personalization, it is recommended to take some precautions when implementing it. 1. Only trusted users should have access to this feature. Use the system profiles: 'Hide Diagnostics menu entry' and 'Utilities:Diagnostics' to control the visibility of the menu and the direct access to the feature (user requires Apps password or not?); 2. It is a good idea to test all Form Personalizations in a DEV or TEST environment before moving them to a Production environment. Remember that changes made could impact or interfere with the base code of a form; 3. Follow diligently the Support statements communicated by Oracle. OVERVIEW AND BASIC CONCEPTS Form Personalization is a declarative feature that alter the behavior of Oracle Forms-based screens, including changing properties, executing built-ins, displaying messages, and adding menu entries. RULES For each function, 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 a startup (WHEN-NEW-FORM-INSTANCE), or a new record (WHEN-NEW-RECORD-INSTANCE). Oracle forms sends standard and product-specific events. A Condition is an optional SQL code fragment that is evaluated when an Event occurs. If the Condition evaluates to TRUE then the Actions are processed. A Scope is evaluated based on the current runtime context to determine if a Rule should be processed or not. The Scope can be Site, Responsibility or User. Each Rule can have one or more Scopes associated with it. When defining new Rules in your DEV or TEST environment, I recommend setting the Scope to your User first just to be safe. If all is well with your personalization, then proceed in setting the Scope to it's intended level. If a Rule has a context of "Site", it will apply for everyone. A Rule with a context of Responsibility doesn't override Site. A Rule with a context of User doesn't override Site or Responsibility.

ACTIONS Each Action consists of 'Setting a property', such as making a required field or hiding a Tab page, 'Executing a Built-in', such as GO_BLOCK, DO_KEY or END_FUNCTION.EXECUTE, 'Displaying a Message' or 'Enabling a Special menu entry', such as a zoom. Once Rules are defined, save and close the form and re-run the function (the form). Then the Rules are automatically applied as Events occur within that form. EXAMPLE OF A BASIC FORM PERSONALIZATION For this example, we will define a basic Forms Personalization by hiding the Person, Customer and Fax fields of the User form. Follow the following steps. Responsibility: System Administrator 1 - Ensure to set system profile 'Hide Diagnostics menu entry' to 'No' and 'Utilities:Diagnostics' to 'Yes' at the user level. 2 - Open the Users form. (N) Security > User > Define. 3 - This is the basic Users form as shown here:

4 - From the menu, select (M) Help > Diagnostics > Custom Code > Personalize. 5 - If some Rules are already defined in the Users form, you will see them this window (as in this example). 6 - Add a new Rule by selecting (M) File > New. 7 - This is the Form Personalisation form and it's Rules already defined. We will be adding seq. 40.

A - Rules Seq.: 40 B - Description: Hide Person, Customer and Fax fields

C - Trigger Event: WHEN-NEW-FORM-INSTANCE D - Context or Scope: Set at User level and enter your user in the Value field E - Select the Actions tab. This is the Actions tab of Rule seq. 40

F - Action Seq.: 1 G - Type: Property H - Object Type: Item I - Select the Select By Text button

J - Select the Person (Users) item from the LOV K - Property Name: DISPLAYED L - Value: False M - Save your work

N - When you are done, it should look like this:

O - Repeat Steps F to L for the Customer and Fax items. Save all of your work. It should now look like this:

P - Close the Form Personalization form, close the User form and reopen it. Your User form should now look like this: Notice that the User, Customer and Fax fields are no longer displayed.

Other basic Forms Personalization are just as easy as this example, such as changing prompts, concealing data or hiding tabs. On my next entry, I will try to cover an intermediate Form Personalization as an example. Elements such as triggers, conditions, sequences, contexts, string evaluation, multi-lingual issues, common actions and debugging will be covered. ---------------------------------------------------------------------------------------------------REFERENCES:
Customization and Development for the E-Business Suite Form Personalization in Oracle Applications User Guide

Form Personalization System Administrator's Guide

White Papers and Webcasts

Popular

Related

Optimize Corporate Investments in Information Technology

Application Grid: Ideal Platform for IT Consolidation Dramatically Accelerate Oracle Database Performance Achieving the Impossible: Unlimited App Scale

More White Papers

Related Products

Oracle 11i: Personalization of Forms and OA Framework Pages Microsoft .NET Framework 4.0: Web Form Controls with VB 2010 Business Grammar: Working with Words

More Products

Jobs by
PeopleSoft Developer Arlington VA CRM Expert Consultant - Any US Location! (Remote)

How to Restrict Finally Close control Action in Purchase Summary Form using Form Personalization.

AP users are not able to match to PO to a finally closed POs as PO User are Closing the PO with Finally Closed options without the PO being invoiced. When AP users try to match the invoice to the PO they get the following error message. Error: APP-SQLAP-97198: You cannot match to this Purchase order shipment because it is finally closed. To avoid such issues going forward PO and AP supers user have advised IT team to Inactive the finally close option to users.

This can be achieved through Form Personalization as given below: 1. Go to Purchase Orders Summary form > query for a PO > after the header of the PO is shown go to Help >Diagnostics > Custom Code > Personalize. the Form Personalization open.

Function Name = PO_POXPOVPO Form Name = POXPOVPO Debug Mode = Off Steps: - Seq = 1 - Description = Stop Final Close from Control Menu - Level = Function - Enable is checked. Condition tab: - Trigger Event = WHEN-VALIDATE-RECORD - Trigger Object = PO_DOCON_CONTROL

- Condition =:po_docon_control.action= 'FINALLY CLOSE' - Processing Mode = Both Actions tab: - Seq = 1 - Type = Message - Description= Blank - Lanuage=All - Enabled is checked - Message Type = Show

- Message Text = :You do not have the permission to Finally Close Purchase Order. Finally Closed is a restricted function that should only be performed once A/P has been consulted - Please use another function.

- Seq = 2 - Type = Property

- Language = All - Enabled is checked - Object Type = Item - Target Object = PO_DOCON_CONTROL.ACTION - Property Name = VALUE - Value = Leave it blank. - Save

In tab Condition in zone Context can chose level= User and select users for which this restriction to be done

Context: Level Value ------ ------Responsibility US Purchase Requestor Responsibility US Purchase Manager

2. Logout/login with the user set on the personalize window and try to finallyclose a PO. After press on Finally Close action a message appear as given below: :You do not have the permission to Finally Close Purchase Order. Finally Closed is a restricted function that should only be performed once A/P has been consulted - Please use another function.

click OK and perform other action and exist. Datafix To open the PO from Finally close to Close: =========================================== (Please test in your test instance before you migrate to Prod) Data Fix: ======= --1) Find po_header_id: select po_header_id from po_headers_all where segment1 in ('1920','3116'); --2) Verify status on PO Header select closed_code from po_headers_all

where po_header_id in (971,3622); --2a) Update closed_code from FINALLY CLOSED to CLOSED: update po_headers_all set closed_code = 'CLOSED' where po_header_id in (971,3622) and closed_code = 'FINALLY CLOSED'; commit; --3) Verify status on PO Line select closed_code from po_lines_all where po_header_id in (971,3622); --3a) Update closed_code from FINALLY CLOSED to CLOSED: update po_lines_all set closed_code = 'CLOSED' where po_header_id in (971,3622) and closed_code = 'FINALLY CLOSED'; commit; --4) Verify status on PO Shipment select closed_code from po_line_locations_all where po_header_id in (971,3622); --4a) Update closed_code from FINALLY CLOSED to CLOSED: update po_line_locations_all set closed_code = 'CLOSED'

where po_header_id in (971,3622) and closed_code = 'FINALLY CLOSED'; commit; --5) Verify Action History on Finally Closed record select count(*) from po_action_history where object_id in (971,3622) and action_code = 'FINALLY CLOSE'; --5a) Remove Action History on Finally Closed record delete from po_action_history where object_id in (971,3622) and action_code = 'FINALLY CLOSE'; commit; 6) Go to Purchasing Order Entry form. Query the PO. Navigate to Special -> Control. Open the PO. Note:Oracle does't recommend to re-open Finally Closed PO's as this leaves a very poor audit trail and there is a potential