Steps to Perform India localization in R12
The following table lists setup steps required for India localization.

Form Personalization – How to Change Field Name

Form Personalization feature allows us to alter the behavior of Forms-based screens, including changing properties, displaying messages etc.
For a single form-function
(a form running in a particular context based on parameters passed to it defined at function level) 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.

Here we will discuss about how can we change the field display name.

Basic Requirement

Our basic requirement is to change name the ‘Latest Start Date field to ‘ABCD‘ in people Screen. Remember this name change should only be applicable for persons who are using ‘UK HRMS Manager’.

Solution ApproachForm Personalization feature is declarative and any personalization to form may interfere with base code of a  form.
before we start personalization please ensure that the following security profiles are properly set   1) FND_HIDE_DIAGNOSTICS (Hide Diagnostics menu entry)
  2) DIAGNOSTICS (Utilities:Diagnostics)


a) Now open the people & Assignment form from the navigator menu. Click on the ‘Latest Start Date field’. Now go to  Help >> Diagnostics >>  Properties >>  Item.
    It will display the ‘Object Properties’ window. Note Down the  Object2 value (HIRE_DATE) which is nothing but the name of the item.

b) Now to personalize the screen, go to  Help >> Diagnostics >> Custom Code >> Personalize
 Set the following values

Condition TabSeq:- Next highest available number.
Description:-
Test Personalization
Level:-
Function
Trigger Event:- WHEN-NEW-FORM-INSTANCE
Trigger Object**:-
Condition:-
Processing Mode:- Both
Scope:- Site

** Depending on the Trigger Event, this field may be Disabled, or Enabled and Required in which case it will validate against a List of Values. For example, if Trigger Event WHEN-NEW-ITEM-INSTANCE is selected, then we must enter a specific block.field for that trigger to be processed.

Action Tab
Seq:- 10
Type:- Property
Description:-
Language***:- All
Object Type:- Item
Target Object:- PERSON.HIRE_DATE (Search with string that we copied from step a)
Property Name:- PROMPT_TEXT
Value:- ABCD

 ***  Select All’ to have the action processed for any language, or select a specific language.Generally text-related personalizations are applied for a specific
       language
.

c) Validate the design and click on Apply Now.

Note:- 1) Since we have selected processing mode as ‘Both’, hence the field name ‘ABCD’ will appear under both the condition ‘New form is open’ and
             ‘Enter-Query Mode’.

                If we select the processing mode as ‘Only in Enter-Query Mode’, then we will see the original name of the field while opening the form.Where as  if we
            query the form it will execute the trigger event and change the name of the field.

      2) Each Rule consists of one or more Scope rows, and one or more Actions. If a Rule has no Scope rows or Action rows, it is not processed. Note that
         upon saving a Rule, if no Scope rows have been entered the form will automatically create a row at the Site level. If any scope matches the current
         runtime context then the Rule will be processed.

Sometime I’m quite annoyed by the typo mistake when creating a DFF context. The DFF segment screen doesn’t allow deletion of context. Fortunately, Oracle has internal API to do such thing. Following is a sample.
–*******************************************
–* Delete a descriptive flexfield
–*******************************************
SET ECHO OFF
SET FEEDBACK OFF
SET SERVEROUTPUT ON SIZE 1000000
DECLARE
l_application_id                NUMBER := 0;
l_descriptive_flexfield_name    VARCHAR2(100) :=  ‘FND_COMMON_LOOKUPS’ ;
l_descriptive_flex_context_cod  VARCHAR2(100) :=  ‘XFND_CLWW_PURGE_FOLDER’;
BEGIN
–FND_DESCRIPTIVE_FLEXS_PKG –this package is for DFF
–FND_DESCR_FLEX_CONTEXTS_PKG –this package is for DFF Context
–FND_DESCR_FLEX_COL_USAGE_PKG –this package is for DFF Column useage
–When creating a new DFF Context, it will check the DFF Column usage if the context is already used.
–so when deleting a DFF Context, both the context and column usage should be deleted.
FOR c IN (SELECT application_column_name
FROM fnd_descr_flex_column_usages
WHERE application_id = l_application_id
AND descriptive_flexfield_name = l_descriptive_flexfield_name
AND descriptive_flex_context_code = l_descriptive_flex_context_cod)
LOOP

fnd_descr_flex_col_usage_pkg.delete_row(
x_application_id                => l_application_id
,x_descriptive_flexfield_name    => l_descriptive_flexfield_name
,x_descriptive_flex_context_cod  => l_descriptive_flex_context_cod
,x_application_column_name       => c.application_column_name
);
END LOOP;
fnd_descr_flex_contexts_pkg.delete_row(
x_application_id                => l_application_id,
,x_descriptive_flexfield_name    => l_descriptive_flexfield_name
,x_descriptive_flex_context_cod  => l_descriptive_flex_context_cod
);

–commit;
end;

Bug 1930586: MATCH_OPTION COLUMN/METHOD MISSING IN PDOI

=========================================================================== 
                            PROBLEM DESCRIPTION
===========================================================================
  ** DESCRIPTION OF PROBLEM, INCLUDING ALL ERRORS:
     There is no column that accepts the value for match_option (invoice
   matching 'P'or'R') in PO_LINES_INTERFACE. (The enhanced PDOI now supports
   standard PO import.) If there is a method to populate the matching
   option value via the PDOI, it should be documented in the PDOI update
   release note. "matching option" is stored in the following table in EBS.   
PO_LINE_LOCATIONS_ALL.MATCH_OPTION

===========================================================================
                            ADDITIONAL DETAILS
===========================================================================
  ** TAR NUMBER (ALSO ENSURE BUG NUMBER FIELD IS UPDATED IN TAR):
  ** LIST ADDITIONAL DOCUMENTATION AVAILABLE (LOG FILE, REPORT, TRACE, ETC.):
N/A    
  ** HOW WILL DEVELOPMENT RECEIVE THE ADDITIONAL DOCUMENTATION?:
Via Email or ess30 upon request.
  ** DESCRIBE ANY WORKAROUND(S) AVAILABLE TO THE CUSTOMER:
Open POXPOEPO and update the option for all imported POs, which is rediculous.

  ** LIST NAME & VERSION OF ALL MODULES INVOLVED (FORM,REPORT,PACKAGE,ETC.):
EBS 11.5.3
Please ask if you need specific file versions.
  ** IS THE PROBLEM OCCURRING IN TEST OR PRODUCTION?
Production.
  ** DOES THE CUSTOMER HAVE ANY CUSTOMIZATIONS OR 3RD PARTY PRODUCTS?
No.

===========================================================================
                                 HISTORY
===========================================================================
  ** WAS THE CUSTOMER ABLE TO COMPLETE THE SAME PROCESS PREVIOUSLY?:
No.
  ** LIST PATCHES APPLIED RECENTLY WHICH COULD AFFECT THIS PROBLEM:
N/A
Defaulting of match_option is as follows
1. From Supplier Site
2. From Supplier
3. From Financials System Parameters
The HLD for STD PO do not mention anything about this column.
Will be an ER to create the column in CASE and to add the necessary
validations.
PREMCOR REFINING GROUP is requesting this ER be changed to a priority 3 bug so 
a fix can be included in a future PO Family Pack.   They have 100's of PO's
that they import from a 3rd party system (Maximo) using the PDOI.  These
multi-line POs are primarily Service Type POs and whether the line can either
be Invoice Match Option to Receipt or Invoice Match Option to Purchase Order
needs to be controlled at the Line level when inserting into the PO Interface
tables.





Here is the solution for the invoice matching, someone needs to update the
bug to include this solution:

Invoice matching, populate the following columns in PO_LINES_INTERFACE table:
'2WAY'  inspection_required_flag = 'N'
         receipt_required_flag    = 'N'

'3WAY'  inspection_required_flag = 'N'
         receipt_required_flag    = 'Y'

'4WAY'  inspection_required_flag = 'Y'
         receipt_required_flag    = 'Y'
Check the process_code in the po_headers_interface and po_lines_interface, if it is ‘REJECTED’,

select process_code from po_headers_interface;
select process_code from po_lines_interface;

please do the following:
Run the program – Purchasing Interface Errors Report
choose parameter : PO_DOCS_OPEN_INTERFACE

The report will list all the errors you have during importing. You can fix the data, then reset process_code = Null in both interface tables, rerun the Purchasing Document Open Interface.

update po_headers_interface set process_code = null
where process_code = ‘REJECTED’;
update po_lines_interface set process_code = null
where process_code = ‘REJECTED’;