Implementing DFF in Forms

1)Open the form where DFF is Implemented. and Query the Data

2)find the DFF name from Help Menu =>Diagnastcs =>Examine
       Select  $DESCRIPTIVE_FLEXFIELD$ in the Block field
       select  DFF name in the "Field"
       we will get the DFF Title in the Value field.
 Copy the DFF title

3)goto Application Developer Responsibility.
 flexfield=>Descriptive=>register

4)Query the records by using the  DFF Title.
 Select columns button and find wether Attribute
  columns are enabled or disabled.

5)Goto Segments form and Query the records by using Title.

6)Uncheck the Check box called "freeze Flexfield Defination"

7)Select Segents button and enter the new fields and save transactions.

8)Check the check box called "freeze Flexfield Defination"
and click the Compile Button.

9)System will change the DFF structure and creates



a descriptive flexfield View.





1)define the field in the Canvas
    change the field property database items as "no"

2)Define the Package like follows.

Package Specification:
----------------------
PACKAGE DFF_PKG IS
  PROCEDURE DFF_PROC(EVENT VARCHAR2);
END;
Package Body:
-------------
PACKAGE BODY DFF_PKG IS
    PROCEDURE DFF_PROC(EVENT VARCHAR2) AS
    BEGIN
        IF (EVENT = 'WHEN-NEW-FORM-INSTANCE'       ) THEN
   
         FND_DESCR_FLEX.DEFINE( BLOCK =>  'WIP_ITEMS10',
                 FIELD             =>  'DFF_TEXT',
                 APPL_SHORT_NAME   =>  'WIP',
                     DESC_FLEX_NAME   =>     'WIPDFF');
                 
        END IF;
        END DFF_PROC;
 
END;

3)Call this Package from WHEN-NEW-FORM-INSTANCE Trigger
   packagename.Procedure name('WHEN-NEW-FORM-INSTANCE');
   DFF_PKG.DFF_PROC('WHEN-NEW-FORM-INSTANCE');
4)Call another API from WHEN-NEW-ITEM-ISNATCE Trigger
fnd_flex.event('WHEN-NEW-ITEM-INSTANCE');
-It will Populate the DFF in the Form.



Give me your Feedback.......

Profile Options in Oracle Applications

Implementing User Profiles :

You should define user profile options whenever you want your application to react in different ways for different users, depending on specific user attributes.

You can decide whether your end users can view and update options you define at the User level or you can also define the option such that your end users could not see or change its value.

Predefined User Profile Options :

Database Profile Options :

Oracle Application Object Library provides many user profile options that the Oracle System Administrator or the users can see and update.

Internally Generated Profile Options :

Oracle Application Object Library also provides a set of profile options that you can access via the user profile routines. You can retrieve values for these profile options in your forms and programs.

However, except for the profiles CONC_PRINT_OUTPUT and CONC_PRINT_STYLE, you cannot change their values. System administrators and end users cannot see the values for, nor change the values of, these profile options.

FND_PROFILE: User Profile APIs :
FND_PROFILE.PUT :
FND_PROFILE.GET
FND_PROFILE.VALUE
What is Profile Options in Oracle Apps:

You can use the user profile routines to manipulate the option values stored in client and server user profile caches.
On the client, a single user profile cache is shared by multiple form sessions. Thus, when Form A and Form B are both running on a single client, any changes Form A makes to the client’s user profile cache affect Form B’s run–time environment, and vice versa.

On the server, each form session has its own user profile cache. Thus, even if Form A and Form B are running on the same client, they have separate server profile caches. Server profile values changed from Form A’s session do not affect Form B’s session, and vice versa.

Similarly, profile caches on the server side for concurrent programs are separate.

Also, note that the server–side profile cache accessed by these PL/SQL routines is not synchronized with the C–code cache. If you put a value using the PL/SQL routines, it will not be readable with the C–code routines.

Any changes you make to profile option values using these routines affect only the run–time environment.

The effect of these settings ends when the program ends, because the database session (which holds the profile cache) is terminated.



Summary procedure FND_PROFILE.PUT

(name IN varchar2,

value IN varchar2);

Location FNDSQF library and database (stored procedure)

Description Puts a value to the specified user profile option. If the option does not exist, you can also create it with PUT.

Arguments (input)

name The (developer) name of the profile option you want to set.

Value The value to set in the specified profile option.



Summary procedure FND_PROFILE.GET

(name IN varchar2,

value OUT varchar2);

Location FNDSQF library and database (stored procedure)

Description Gets the current value of the specified user profile option, or NULL if the profile does not exist.

Arguments (input)

name The (developer) name of the profile optionwhose value you want to retrieve.

Arguments (output)

Value The current value of the specified user profile option as last set by PUT or as defaulted in the current user’s profile.

Example FND_PROFILE.GET (’USER_ID’, user_id);



Summary function FND_PROFILE.VALUE

(name IN varchar2) return varchar2;

Location FNDSQF library and database (stored function)

Description VALUE works exactly like GET, except it returns the value of the specified profile option as a function result.

Arguments (input)

Name The (developer) name of the profile option whose value you want to retrieve.
Profiles :

A user profile is a set of changeable options that affects the way your applications run. Oracle Application Object Library establishes a value for each option in a user’s profile when the user logs on or changes responsibility. Your user can change the value of profile options at any time. Oracle Application Object Library provides many options that your users can set to alter the user interface of your applications to satisfy their individual preferences.

Oracle Applications user profiles help you satisfy the following business needs. You should be able to:

* Set options that affect your application’s behavior to your preference
* Modify product–specific variables that affect the functionality of your application to suit your business environment


User profile options exist at Site, Application, Responsibility and User levels. Oracle Application Object Library treats user profile levels as a hierarchy, where User is the highest level of the hierarchy, followed by Responsibility, Application and at the lowest level, Site. Higher–level option values override lower–level option values. Each user profile option ordinarily exists at each level.


* Site Level is the lowest user profile level. Site–level option values affect the way all applications run at a given installation.


* Application : Application is the user profile level immediately above Site. Application–level option values affect the way a particular application runs.


* Responsibility Level :Responsibility is the user profile level immediately above Application. Responsibility–level option values affect the way applications run for all users of a responsibility.


* User Level : User is the highest user profile level and is immediately above Responsibility. User–level option values affect the way applications run for an application user.

Value Sets

Oracle Application Object Library uses values; value sets and validation tables as important components of key FLEXFIELDs, descriptive FLEXFIELDs, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables. When you first define your FLEXFIELDs, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values. You define your value sets first, either before or while you define your FLEXFIELD segment structures. You typically define your individual values only after your FLEXFIELD has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your FLEXFIELD.
You can share value sets among segments in different FLEXFIELDs, segments in different structures of the same FLEXFIELD, and even segments within the same FLEXFIELD structure. You can share value sets across key and descriptive FLEXFIELDs. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.
Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right–Justify Zero–fill set to Yes.
Value set is nothing but List of Values with validations. We can use the Value Sets when ever the Concurrent Program has parameters and while defining the Flex Fields. We have to attach the value sets to the Concurrent Program. Validations are depending on Client Requirement. 
Value sets are of 8 types.There are several validation types that affect the way users enter and use segment or parameter values:
1. None (not validated at all)
2. Independent
3. Dependent
4. Table
5. Special (advanced)
6. Pair (advanced)
7. Translatable Independent
8. Translatable Dependent

You cannot change the validation type of an existing value set, since your changes affect all FLEXFIELDs and report parameters that use the same value set.

None: You use a None type value set when you want to allow users to enter any value so long as that value meets the value set formatting rules. That is, the value must not exceed the maximum length you define for your value set, and it must meet any format requirements for that value set. For example, if the value set does not allow alphabetic characters, your user could not enter the value ABC, but could enter the value 456 (for a value set with maximum length of three). The values of the segment using this value set are not otherwise validated, and they do not have descriptions. Because a NONE value set is not validated, a segment that uses this value set does not provide a list of values for your users. A segment that uses this value set (that is, a non–validated segment) cannot use FLEXFIELD value security rules to restrict the values a user can enter.
Independent > An Independent value set provides a predefined list of values for a segment. These values can have an associated description. For example, the value 01 could have a description of ‘Company 01’. The meaning of a value in this value set does not depend on the value of any other segment. Independent values are stored in an Oracle Application Object Library table. You define independent values using an Oracle Applications window, Segment Values.

Table > A table–validated value set provides a predefined list of values like an independent set, but its values are stored in an application table. You define which table you want to use, along with a WHERE cause to limit the values you want to use for your set. Typically, you use a table–validated set when you have a table whose values are already maintained in an application table (for example, a table of vendor names maintained by a Define Vendors form). Table validation also provides some advanced features such as allowing a segment to depend upon multiple prior segments in the same structure.

Dependent > A dependent value set is similar to an independent value set, except that the available values in the list and the meaning of a given value depend on which independent value was selected in a prior segment of the FLEXFIELD structure. You can think of a dependent value set as a collection of little value sets, with one little set for each independent value in the corresponding independent value set. You must define your independent value set before you define the dependent value set that depends on it. You define dependent values in the Segment Values windows, and your values are stored in an Oracle Application Object Library table.

Special and Pair Value Sets: 
Special and pair value sets provide a mechanism to allow a”FLEXFIELD–within–a–FLEXFIELD”. These value sets are primarily used for Standard Request Submission parameters. You do not generally use these value sets for normal FLEXFIELD segments. Special and Pair value sets use special validation routines you define. For example, you can define validation routines to provide another FLEXFIELD as a value set for a single segment or to provide a range FLEXFIELD as a value set for a pair of segments.

Translatable Independent and Translatable Dependent :A Translatable Independent value set is similar to Independent value set in that it provides a predefined list of values for a segment. However, a translated value can be used. A Translatable Dependent value set is similar to Dependent value set in that the available values in the list and the meaning of a given value depend on which independent value was selected in a prior segment of the FLEXFIELD structure. However, a translated value can be used. FLEXFIELD Value Security cannot be used with Translatable Independent or Translatable Dependent value sets. For format validation, translatable value sets must use the format type Char. The maximum size must be no greater than 150. The Number Only option and the Right–justify and Zero–Fill Numbers option cannot be used with translatable value sets. Range FLEXFIELDs cannot use Translatable Independent or Translatable Dependent value sets.