12Applications Core Configuration

This chapter contains the following:

The Define Applications Core Configurations task list contains the Oracle Middleware Extensions for Oracle Application (Applications Core) tasks that support implementation of common functionality such as lookups, profile options, document sequences, and so on. Some of the tasks are also available in the Application Extensions functional area. You may also find specific versions of this task list depending upon the product family or the offering that uptakes those tasks.

Use this task list to manage configuration objects that are defined centrally and shared across applications, in addition to tasks classified in the Maintain Common Reference Objects task list. You can search for this task list in the Setup and Maintenance work area.

Import Flexfields, Lookups, or Profile Values Using Web Services

You can import lookups, profile option values, and extensible flexfields into an application using the import function on the application page. Alternatively, you can use the web service FndManageImportExportFilesService for the import task. The web service uses the following methods:

Loader Name Asynchronous Method Synchronous Methods Supported methods for backward compatibility (without UUID)

Flex data uploader

processFlexDataAsync(List<String> inputFileIdTypeList, String UUID)

processFlexData(LIst<String>inputFileIdTypeList, String UUID)

processFlexDataFiles(List<Strig> inputFileIdTypeList)

Lookups data uploader

processLookupsDataAsync(long lookupTypesFileID, long lookupCodesFileID, long viewApplicationID, String UUID)

processLookupsData (long lookupTypesFileID, long lookupCodesFileID, long viewApplicationID, String UUID)

processLookupsUploadFiles (long lookupTypesFileID, long lookupCodesFileID, long viewApplicationID)

User profile values uploader

processUserProfileValuesAsync(long userProfilesFileID, String UUID)

processUserProfileValues(long userProfilesFileID, String UUID)

processUserProfileValuesFile(long userProfilesFileID)

Valueset Values data uploader

processValueSetValuesAsync(Long fileIdAtRepository, String UUID)

processValueSetValues(Long fileIdAtRepository, String UUID)

valueSetValuesDataLoader(Long fileIdAtRepository)

Generic method

 

downloadProcessLogFile(String UUID)

 

Example

The following example is about importing the profile values using the web service. To import lookups or extensible flexfields, initiate the web service in the same way as shown here, after replacing the methods and other relevant values in the code.

To import profile values:

  1. Perform the following substeps to generate keystore for the security policy "oracle/wss11_saml_or_username_token_with_message_protection_service_policy":

    1. Generate keystore using the command keytool -genkeypair -keyalg RSA -alias mycompkey -keypass password -keystore mycompclient-keystore.jks -storepass password -validity 3600.

    2. Open the WSDL using the URL http://<host>:<port>/fndAppCoreServices/FndManageImportExportFilesService?wsdl through a web browser, and get the public key <wsdl:service>/<wsdl:port>/<wsa:EndpointReference>/<wsid:Identity>/<dsig:keyInfo>/<dsig:X509Data>/<dsig:X509Certificate>. Then, enclose it with ---- BEGIN CERTIFICATE ---- and ---- END CERTIFICATE ---- and save it to a file by name cdrmpk.cer.

    3. Store the key information in the truststore using the command keytool -importcert -alias cdrmkey -file cdrmpk.cer -keystore mycompclient-keystore.jks -storepass password.

  2. Open the WSDL page using the browser of your choice.

  3. Export and save the associated security certificates Verisign Class 3 Public Primary Certification Authority - G5 and Verisign Secure Server CA - G3.

  4. Use the following command to import the saved certificates into the trust store of the client computer.

    keytool -importcert -keystore <truststore> -storepass <truststorepassword> -file <file location where the mentioned certificate is stored> -alias <alias for certificate>
  5. Run the following command to generate the JAX-WS proxy for the FndManageImportExportFilesService web service.

    C:\Program Files\Java\jdk1.7.0_04\bin>wsimport -s "d:\wsimport\FndManageImportExport" -d "d:\wsimport\FndManageImportExport" http://<host>:<port>/fndAppCoreServices/FndManageImportExportFilesService?wsdl
  6. Save the generated code as a JAR file and name it FndManageImportExportProxy.jar.

  7. Use the following code to create another JAR file to initiate the web service:

    package com.oracle.xmlns.oracle.apps.fnd.applcore.webservices;
     
    import com.sun.xml.ws.developer.WSBindingProvider;
     
    import java.io.File;
    import java.io.IOException;
     
    import java.util.List;
     
    import java.util.Map;
     
    import javax.xml.ws.BindingProvider;
    import javax.xml.ws.WebServiceRef;
     
    import javax.xml.ws.handler.Handler;
     
    import oracle.webservices.ClientConstants;
     
    import weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature;
    // !THE CHANGES MADE TO THIS FILE WILL BE DESTROYED IF REGENERATED!
    // This source file is generated by Oracle tools
    // Contents may be subject to change
    // For reporting problems, use the following
    // Version = Oracle WebServices (11.1.1.0.0, build 130224.1947.04102)
     
    public class FndManageImportExportFilesServiceSoapHttpPortClient
    {
      @WebServiceRef
      private static FndManageImportExportFilesService_Service fndManageImportExportFilesService_Service;
     
      public static void main(String [] args)
      {
           System.setProperty("javax.net.ssl.trustStore","<location of truststore which is used in II) to import the certificates>");
           System.setProperty("javax.net.ssl.trustStorePassword", "<truststore password>");
     
        fndManageImportExportFilesService_Service = new FndManageImportExportFilesService_Service();
            SecurityPoliciesFeature securityFeatures =
                new SecurityPoliciesFeature(new String[] { "oracle/wss11_username_token_with_message_protection_client_policy",
                                                           });
            FndManageImportExportFilesService
     fndManageImportExportFilesService =  
    fndManageImportExportFilesService_Service.getFndManageImportExportFilesServiceSoapHttpPort
     (securityFeatures);
            // Add your code to call the required methods.
     
     
            WSBindingProvider wsbp = (WSBindingProvider) fndManageImportExportFilesService;
               Map<String, Object> requestContext = wsbp.getRequestContext();
     
     
            requestContext.put(ClientConstants.WSSEC_KEYSTORE_TYPE,"jks");
            // Provide location of 'mycompclient-keystore.jks' which was created during Step I)
            requestContext.put(ClientConstants.WSSEC_KEYSTORE_LOCATION,"/home/user1/mycompclient-keystore.jks");
            requestContext.put(ClientConstants.WSSEC_KEYSTORE_PASSWORD,"password");
            requestContext.put(ClientConstants.WSSEC_RECIPIENT_KEY_ALIAS,"cdrmkey");
     
            //Provide user who is having permission to initiate the service
            requestContext.put(WSBindingProvider.USERNAME_PROPERTY,"<username>");
            requestContext.put(WSBindingProvider.PASSWORD_PROPERTY, "<password>");
     
     
            String id =          invokeUploadFiletoUCMMethod(fndManageImportExportFilesService);
     
            if (id != null) {
                invokeUserProfileValuesDataLoader(fndManageImportExportFilesService,  new Long(id));
     
            }
      }
     
        static String invokeUploadFiletoUCMMethod(FndManageImportExportFilesService fndManageImportExportFilesService) {
     
            String response = null;
            DocumentDetails document = new DocumentDetails();
            ObjectFactory objfactory = new ObjectFactory();
            document.setFileName(objfactory.createDocumentDetailsFileName("import_data.txt"));
            // Provide UCM repository - if repository is fin/tax/import then suffix each value with $ as mentioned here
            document.setDocumentAccount(objfactory.createDocumentDetailsDocumentAccount("fin$/tax$/import$"));
            document.setDocumentTitle(objfactory.createDocumentDetailsDocumentTitle("VS"));
            document.setContentType(objfactory.createDocumentDetailsContentType("plain/text"));
     
            try {
     
                // Provide location of bulk import data file in prescribed format
                byte[] content =
                org.apache.commons.io.FileUtils.readFileToByteArray(new File("/home/user1/import_data.txt"));
     
                //System.out.println("File content:" + new String(content, "UTF-8"));
                document.setContent(objfactory.createDocumentDetailsContent(content));
     
            } catch (IOException e) {
                System.out.println(e.getMessage());
            }
            catch(Exception e) {
                System.out.println("Exception: "+e.getMessage());
            }
     
            try {
                response = fndManageImportExportFilesService.uploadFiletoUCM(document);
                System.out.println("Response: " + response);
     
            } catch (ServiceException e) {
                System.out.println(e.getMessage());
            }
     
            return response;
        }
     
        static void invokeUserProfileValuesDataLoader(FndManageImportExportFilesService fndManageImportExportFilesService,
                                                   Long id) {
            String response;
            try {
                response = fndManageImportExportFilesService.processUserProfileValuesFile(id);
                System.out.println("Response: " + response);
            } catch (ServiceException e) {
                System.out.println(e.getMessage());
            }
        }
    }
    
    Note: Wherever applicable, replace the values referring to the profile values with those of the lookups or flexfields value sets.
  8. Save the generated output as a JAVA file and name it FndManageImportExportFilesServiceSoapHttpPortClient.java.

  9. Use the JAVA file to build a JAR file, and name it FndManageImportExportClient.jar.

  10. Use the following command to run the web service:

    java -cp ./FndManageImportExportProxy.jar:./ws.api_1.1.0.0.jar:./FndManageImportExportClient.jar FndManageImportExportFilesServiceSoapHttpPortClient

Here's a sample program that is a web service client for the asynchronous method deployFlexAsync(). This client program starts callback client and does the asynchronous call. The required callback web service starts at the line no 58.

Endpoint e = Endpoint.publish(callbackServiceAddress, new ApplicationsCoreSetupServiceResponseImpl());

The callback web service will still be in Running state after the client program execution completes and you need to close it manually. Alternatively, you can also comment the above line here and run it in a separate client program.

package com.ws.client;

import com.sun.xml.ws.api.addressing.AddressingVersion;
import com.sun.xml.ws.api.addressing.WSEndpointReference;
import com.sun.xml.ws.developer.WSBindingProvider;
import com.sun.xml.ws.message.StringHeader;

import com.ws.client.callback.ApplicationsCoreSetupServiceResponseImpl;
import com.ws.client.types.DeployFlexAsyncResponse;

import java.util.Map;
import java.util.UUID;

import javax.xml.ws.Endpoint;
import javax.xml.ws.Response;
import javax.xml.ws.WebServiceRef;

import oracle.webservices.ClientConstants;

import weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature;
// !THE CHANGES MADE TO THIS FILE WILL BE DESTROYED IF REGENERATED!
// This source file is generated by Oracle tools
// Contents may be subject to change
// For reporting problems, use the following
// Version = Oracle WebServices (11.1.1.0.0, build 150302.2135.1.30348)

public class ApplicationsCoreSetupServiceSoapHttpPortClient
{
	@WebServiceRef
	private static ApplicationsCoreSetupService_Service applicationsCoreSetupService_Service;


	private static final AddressingVersion WS_ADDR_VER = AddressingVersion.W3C;

	public static void main(String [] args) throws InterruptedException {
		applicationsCoreSetupService_Service = new ApplicationsCoreSetupService_Service();
			SecurityPolicyFeature[] features = new SecurityPolicyFeature[]
				{ new SecurityPolicyFeature("policy:oracle/wss_username_token_client_policy") };

		ApplicationsCoreSetupService applicationsCoreSetupService = applicationsCoreSetupService_Service.getApplicationsCoreSetupServiceSoapHttpPort(features);


		// Get the request context to set the outgoing addressing properties

		WSBindingProvider wsbp = (WSBindingProvider)applicationsCoreSetupService;
			Map<String, Object> requestContext = wsbp.getRequestContext();

			requestContext.put(ClientConstants.WSSEC_KEYSTORE_TYPE, "jks");
			requestContext.put(ClientConstants.WSSEC_KEYSTORE_LOCATION,
											  "/scratch/vgarikip/view_storage/work/keys/mycompclient-keystore.jks");
			requestContext.put(ClientConstants.WSSEC_KEYSTORE_PASSWORD,
												"mypassword1");
			requestContext.put(ClientConstants.WSSEC_RECIPIENT_KEY_ALIAS,
												"cdrmkey");
			requestContext.put(WSBindingProvider.USERNAME_PROPERTY,
												"app_impl_consultant");
			requestContext.put(WSBindingProvider.PASSWORD_PROPERTY, "mypassword1");

			String callbackServiceAddress = "http://<server>:<port>/TestAsyncMani-Project1-context-root/ApplicationsCoreSetupServiceResponseImplPort";
			Endpoint e = Endpoint.publish(callbackServiceAddress, new ApplicationsCoreSetupServiceResponseImpl());

		WSEndpointReference replyTo = new WSEndpointReference(callbackServiceAddress, WS_ADDR_VER);
		String uuid = "uuid:" + UUID.randomUUID();

		wsbp.setOutboundHeaders( new StringHeader(WS_ADDR_VER.messageIDTag, uuid), replyTo.createHeader(WS_ADDR_VER.replyToTag));

	applicationsCoreSetupService.deployFlexAsync("PER_CITIZENSHIPS_DFF", "DFF", false);      //.deployPatchedFlexAsync(mode, pCustomizationId, pCustomizationSetLoc);



		System.out.println("####END OF WS CALL");

		Thread.sleep(10000);

		// Add your code to call the desired methods.
	}
}

Example callback web service start utility if you comment line no 58 in the above program:

package com.ws.client;


import com.ws.client.callback.ApplicationsCoreSetupServiceResponseImpl;

import javax.xml.ws.Endpoint;


public class RunCallbackServtest {
	public RunCallbackServtest() {
		super();
	}

	public static void main(String[] args) throws InterruptedException {
		RunCallbackServtest runCallbackServtest = new RunCallbackServtest();
		runCallbackServtest.runServ();

	}

	private void runServ() throws InterruptedException {

		System.out.println("$$$$$ BEFORE Server Start ###################");
		String callbackServiceAddress = "http://<server>:<port>/TestAsyncMani-Project1-context-root/ApplicationsCoreSetupServiceResponseImplPort";
		Endpoint e = Endpoint.publish(callbackServiceAddress, new ApplicationsCoreSetupServiceResponseImpl());

		System.out.println("$$$$$ AFTER Server Start ###################");

	}
}

Lookups

Lookups are lists of values in applications. You define a list of values as a lookup type consisting of a set of lookup codes, each code's translated meaning, and optionally a tag. End users see the list of translated meanings as the available values for an object.

Lookups provide a means of validation and lists of values where valid values appear on a list with no duplicate values. For example, an application might store the values Y and N in a column in a table, but when displaying those values in the user interface, Yes or No (or their translated equivalents) should be available for end users to select. For example, the two lookup codes Y and N are defined in the REQUIRED_INDICATOR lookup type.

The following table contains an example of a lookup type for marital status (MAR_STATUS) that has lookup codes for users to specify married, single, or available legal partnerships.

Lookup Code Meaning Tag

M

Married

Not applicable

S

Single

Not applicable

R

Registered Partner

+NL

DP

Domestic Partner

-FR, AU

In this case, tags are used for localizing the codes. All legislations list Married and Single. Only the Dutch legislation lists Registered Partner. And all legislations except France and Australia also list Domestic Partner.

When managing lookups, you need to understand the following.

  • Using lookups in applications

  • Configuration levels

  • Accessing lookups

  • Enabling lookups

  • The three kinds of lookups: standard, common, and set-enabled

Using Lookups in Applications

Use lookups to provide validation or a list of values for a user input field in a user interface.

An example of a lookup used for validation is a flexfield segment using a table-validated value set with values from a lookup type. An example of a lookup in a list of values is a profile option's available values from which users select one to set the profile option. Invoice Approval Status gives the option of including payables invoices of different approval statuses in a report. The lookup code values include All, so that users can report by all statuses: Approved, Resubmitted for approval, Pending or rejected, and Rejected.

Configuration Level

The configuration level of a lookup type determines whether the lookups in that lookup type can be edited. This applies data security to lookups.

Some lookup types are locked so no new codes and other changes can be added during implementation or later, as needed. Depending on the configuration level of a lookup type, you may be able to change the codes or their meanings. Some lookups are designated as extensible, so new lookup codes can be created during implementation, but the predefined lookup codes cannot be modified. Some predefined lookup codes can be changed during implementation or later, as needed.

The configuration levels are user, extensible, and system. The following table shows the lookup management tasks permitted at each configuration level.

Permitted Task User Extensible System

Deleting a lookup type

Yes

No

No

Inserting new codes

Yes

Yes

No

Updating start date, end date, and enabling the lookup code

Yes

Yes, only if the code is not predefined data

No

Deleting codes

Yes

Yes, only if the code is not predefined data

No

Updating tags

Yes

No

No

Updating module

Yes

No

No

Predefined data means LAST_UPDATED_BY = SEED_DATA_FROM_APPLICATION.

If a product depends on a lookup, the configuration level must be system or extensible to prevent deletion.

Once the configuration level is set for a lookup type, it can't be modified. The configuration level for newly created lookup types is by default set at the User level.

Standard, Common, and Set-Enabled Lookups

The following table shows the available types of lookups.

Lookup Type Description

Standard

Lists the available codes and translated meanings.

Set-enabled

Associates a reference data set with the lookup codes.

Common

Legacy lookups or lookups that have attributes.

Standard lookups are the simplest form of lookup types consisting only of codes and their translated meaning. They differ from common lookups only in being defined in the standard lookup view. Common lookups exist for reasons of backward compatibility and differ from standard lookups only in being defined in the common lookup view. These can also be lookups having attribute columns. Set-enabled lookup types store lookup codes that are enabled for reference data sharing. At runtime, a set-enabled lookup code is visible because the value of the determinant identifies a reference data set in which the lookup code is present.

Accessing Lookups

Standard, set-enabled, and common lookups are defined in the Standard, Set-enabled, and Common views, respectively. Applications development may define lookups in an application view to restrict the UI pages where they may appear.

In lookups management tasks, lookups may be associated with a module in the application taxonomy to provide criteria for narrowing a search or limiting the number of lookups accessed by a product specific task such as Manage Purchasing Lookups.

Enabling Lookups

A lookup type is reusable for attributes stored in multiple tables.

Enable lookups based on the following.

  • Selecting an Enabled check box

  • Specifying an enabled start date, end date, or both

  • Specifying a reference data setdeterminant

If you make changes to a lookup, users must sign out and back in before the changes take effect. When defining a list of values for display rather than validation, limit the number of enabled lookup codes to a usable length.

To view the predefined lookups and their lookup codes, use the following tasks in the Setup and Maintenance work area:

  • Manage Standard Lookups

  • Manage Common Lookups

  • Manage Set-Enabled Lookups

Translating Lookups

You can translate the lookups that you defined to the preferred language(s) without changing the language session of the application. Use the translation option available on the lookup code table. By default, for each lookup, all the permitted language rows in the translator dialog box appear in the source language (the current session language). When you edit a particular language entry, you can modify the translated meaning and description to the language in which you want the lookup to appear. Once the updates are made, the end-users can view the lookup in the translated text.

Note: You can add the translation for only as many languages as are permitted by the administrator. The functionality to limit the number of languages displayed on the dialog box is controlled through the Translation Editor Languages profile option. It can be set at the SITE or USER level. If nothing is specified, all active languages are displayed.

Creating a new standard lookup involves creating or selecting a lookup type containing the lookup code. The task also involves determining appropriate values for the lookup codes and their meanings. You can only create or edit lookup codes for a particular lookup type if its configuration level supports it.

Creating a Lookup Type Called COLORS

Your enterprise needs a list of values to be used as different statuses on a process. Each status is indicated using a color. Therefore, you create a lookup type called COLORS. The following table lists a mapping between the lookup type parameters and the actual values assigned to those parameters to create the required list of values.

Lookup type parameters Value

Lookup type name

COLORS

Meaning

Status

Description

Status by color

Module

Oracle Fusion Middleware Extensions for Oracle Application

After you define the lookup type, you need to define the lookup codes and their related details. The following table lists the lookup codes you define for the COLORS lookup type.

Lookup Code Meaning Enabled Display Sequence

BLUE

Urgent

No

4

RED

Stop

Yes

1

GREEN

Proceed

Yes

3

YELLOW

Check

Yes

2

The Resulting Data Entry List of Values

Only the enabled lookup codes appear in the list of values for the COLORS lookup type. You must select one of them to complete the activity.

The following table lists the meanings and the codes that were enabled. They appear in the order of the defined display sequence.

Meaning Lookup Code

Stop

RED

Check

YELLOW

Proceed

GREEN

Analysis

The BLUE lookup code was not enabled and does not appear in the list of values. The display sequence of values in the list of values is alphabetic, unless you enter a number manually to determine the order of appearance. Number 1 indicates the first value that appears in the list. Only lookups that are enabled and active between start and end dates are visible.

The Transaction Table

When users enter one of the values from the list of values for the lookup type COLORS, the transaction table records the lookup code. The following table contains an example, where the lookup code is stored in the Status column of the transaction table.

Transaction number User name Status

1

Jane

RED

2

Bob

YELLOW

3

Alice

BLUE

The status for one user is BLUE because at the time they entered a value, BLUE was enabled. Disabling a lookup code does not affect transaction records in which that code is stored. Data querying and reporting have access to disabled lookup codes in transaction tables.

Creating a new set-enabled lookup is similar to creating a standard lookup with the addition of specifying a reference data setdeterminant for the lookup codes. You can only create or edit lookup codes for a particular lookup type if its configuration level supports it.

The reference data set for a set-enabled lookup code is part of its foreign key. This is unlike other set-enabled entities. Use the Manage Set Assignments task to define and manage reference data set assignments.

Selecting a Reference Group for a Set-Enabled Lookup Type

Specify a reference group for a set-enabled lookup type to indicate which reference data set assignments are available for its lookup codes. For example a COLORS lookup type might be set-enabled for a Countries reference group that includes the US and EU reference data set assignments.

Selecting a Reference Data Set for a Set-Enabled Lookup

The reference data set determines which lookup code is included in the list of values. For example, there are two references data sets - one for the US and the other for EU. If a COLORS lookup type contains RED, YELLOW, ORANGE, and GREEN lookup codes, you can enable one RED lookup code from the US reference data set and another RED lookup from the EU reference data, each lookup code having different meanings.

The following table elaborates the example, how these two reference data sets (US and EU) contain one lookup code that is common, but each differing in its lookup meaning.

Reference Data Set Lookup Code Lookup Meaning

US

RED

Red

US

YELLOW

Yellow

US

GREEN

Green

EU

RED

Rouge

EU

ORANGE

Orange

Some lookup codes may be unique to one or another reference data set as the ORANGE lookup is to the EU reference data set in the example.

In another example in the following table, a lookup type called HOLD_REASON provides a list of reasons for putting a contract renewal on hold. Reference data sets determine which codes are included in the Hold Reason list of values.

Reference Data Set Lookup Code Lookup Meaning

US

SEC

SEC Compliance Review

US

DIR

Needs Director's Approval

US

VP

Needs Vice President's Approval

CHINA

CSRC

Pending China Securities Regulatory Commission Review

CHINA

PR

Needs President's Approval

COMMON

REQUESTED

Customer Request

Referring to the example in the table, when end-users place a contract on hold in the US business unit, the three reason codes in the US set are available. When placing a contract on hold in the China business unit, the two codes in the China set are available.

Import Lookups

On each page pertaining to the tasks of managing the Standard, Common, and Set Enabled lookups, use the Import option to import the lookup type and lookup code information.

Prerequisite

The separate files containing the lookup types and lookup codes are already available in the document repository of Oracle WebCenter Content.

Importing Lookups

To import lookups:

  1. In the Setup and Maintenance work area, go to the Manage Standard Lookups task. Depending on the lookup you want to import, you may select the other lookup tasks.

  2. In Search Results, from the Actions menu, select Import.

    The Import Lookups dialog box appears.

  3. Select the WebCenter Content account to which the files were uploaded.

  4. Enter the names of the separate files containing the lookup type and lookup code information. The names here must match with the names of the files uploaded to the selected account.

  5. Click Upload. The lookup details are imported.

    Note: If the import fails, click the link to the log file on the confirmation dialog box and examine the cause of failure.

File Format for Importing Lookups

To import lookups into an application, you create separate text files containing the lookup types and lookup codes and upload them to the Oracle WebCenter Content document repository. The files must follow a specific format, as described here. After the files are in the document repository, you can then import the lookup types and lookup codes into the application following the instructions in the Importing Lookups: Procedure topic.

While creating the file, adhere to the following guidelines:

  • Use a vertical bar or pipe ( | ) as a delimiter between fields for both header and value rows.

  • Set the file encoding to UTF-8 without the Byte Order Mark (BOM), as per the Oracle WebCenter Content specification.

The following sections contain details about the specific lookup types and codes.

Prerequisite

You must have worked with lookups in Oracle Cloud applications.

Standard and Common Lookups

The lookup types and codes are similar for standard and common lookups. To create a file containing the lookup types, include the following headers:

  • LookupType: The lookup type.

  • Meaning: The display name of the lookup type.

  • Description: The description of the lookup type. This header is optional.

  • ModuleType: The module with which the lookup type is associated.

  • ModuleKey: The module code.

Here's a sample file that contains the header values at the beginning of the file, followed by line entries of the two lookup types that are to be imported. For importing several lookup types, add more line entries in a similar format.

LookupType|Meaning|Description|ModuleType|ModuleKey
AFLOG_22APR_1|Log1|AFLOG_desc_1|APPLICATION|FND
PROD_22APR_2|Product1|PROD_desc_2|APPLICATION|FND

To create a file containing the lookup codes, include the following headers.

  • Required headers:

    • LookupType: The lookup type.

    • LookupCode: The lookup code associated with the lookup type.

    • DisplaySequence: The sequence position at which the lookup code appears in the list of values.

    • EnabledFlag: Indicates the status of the lookup code, whether it's enabled for display or not.

    • Meaning: The display name of the lookup code.

  • Optional headers:

    • StartDateActive: Beginning of the date range during which the lookup code is active and visible on the page.

    • EndDateActive: End of the date range during which the lookup code is active and visible on the page.

    • Description: Description of the lookup code.

    • Tag: Any tag associated with the lookup code that may be used for a quick reference or retrieval of information.

Here's a sample file that contains two lookup codes:

LookupType|LookupCode|DisplaySequence|EnabledFlag|StartDateActive|EndDateActive|Meaning|Description|Tag
TASK_22APR_1|Code1_1|1|Y|11/12/2014|1/5/2015|TASK_22apr_1|Task_desc_1|Tag1_1
TASK_22APR_1|Code1_2|2|N|1/1/2014|1/11/2015|TASK_22apr_2|Task_desc_2|Tag1_2
TASK_22APR_2|code2_1|3|N|11/12/2012|1/7/2015|TASK_22qpr_2_1|Task_desc_2|tag2_1
TASK_22APR_2|code2_2|3|Y|11/12/2012|1/7/2015|TASK_22qpr_2_2|Task_desc_2_2|tag2_2

Set Enabled Lookups

To create a file containing the set enabled lookup types, include the following headers:

  • LookupType: The lookup type.

  • Meaning: The display name of the lookup type.

  • Description: The description of the lookup type. This header is optional.

  • ModuleType: The module with which the lookup type is associated.

  • ModuleKey: The module code.

  • ReferenceGroupName: Name of the reference group that contains the reference data set.

Here's a sample that contains two set enabled lookup types:

LookupType|Meaning|Description|ModuleType|ModuleKey|ReferenceGroupName
CODE_22APR_1|CODE_22apr_1|Code_desc_1|APPLICATION|FND|BU_APAC
CODE_22APR_2|CODE_22qpr_2|Code_desc_2|APPLICATION|FND|BU_APAC

To create a file containing the set enabled lookup codes, include the following headers.

  • Required headers:

    • LookupType: The lookup type.

    • LookupCode: The lookup code associated with the lookup type.

    • DisplaySequence: The sequence position at which the lookup code appears in the list of values.

    • EnabledFlag: Indicates the status of the lookup code, whether it's enabled for display or not.

    • Meaning: The display name of the lookup code.

    • SetName: Name of the reference data set.

  • Optional headers:

    • StartDateActive: Beginning of the date range during which the lookup code is active and visible on the page.

    • EndDateActive: End of the date range during which the lookup code is active and visible on the page.

    • Description: Description of the lookup code.

    • Tag: Any tag associated with the lookup code that may be used for a quick reference or retrieval of information.

Here's a sample file that contains the header values at the beginning and lists four set enabled lookup codes to be imported. For importing several lookup codes, add more entries in the same format.

LookupType|LookupCode|DisplaySequence|EnabledFlag|StartDateActive|EndDateActive|Meaning|Description|Tag|SetName
DATA_22APR_1|Code1_1|1|Y|11/12/2014|1/5/2015|DATA_22apr_1|Data_desc_1|Tag1_1|TEST SET CODE 2
DATA_22APR_1|Code1_2|2|N|1/1/2014|1/11/2015|DATA_22apr_2|Data_desc_2|Tag1_2|TEST SET CODE 3
DATA_22APR_2|code2_1|3|N|11/12/2012|1/7/2015|DATA_22qpr_2_1|Data_desc_2|tag2_1|TEST SET CODE 2
DATA_22APR_2|code2_2|3|Y|11/12/2012|1/7/2015|DATA_22qpr_2_2|Data_desc_2_2|tag2_2|TEST SET_ERR_CODE_Z

FAQs for Lookups

How can I access predefined lookups?

Search for predefined lookups using any of the manage lookups tasks.

  1. In the Setup and Maintenance work area, go to any of the following tasks that contains the lookups you are looking for:

    • Manage Standard Lookups

    • Manage Common Lookups

    • Manage Set-enabled Lookups

  2. Enter any of the search parameters and click Search. If you don't know the lookup type or the meaning, use the Module field to filter search results.

  3. Click a lookup type to view its lookup codes.

    Tip: Click the Query By Example icon to filter the lookup codes.

On any of the Manage Lookups pages, you can edit the existing lookup codes of a lookup type or add new lookup codes. You can edit lookups using the following tasks in the Setup and Maintenance work area:

  • Manage Standard Lookups

  • Manage Common Lookups

  • Manage Set-enabled Lookups

Each task contains a predefined set of lookup types that are classified and stored. Open a task to search and edit the required lookup. However, you may not be able to edit a lookup if its configuration level doesn't support editing.

Lookup types are classified using tasks that involve a group of related lookups, such as Manage Geography Lookups. Each task gives you access only to certain lookup types. However, the generic tasks provide access to all lookups types of a kind, such as common lookups associated with the Manage Common Lookups task.

If the lookup types in an application are available in the standard, common, or set-enabled lookups view, they're are central to an application. However, lookup types defined for a specific application are managed using the task or task list for that application.

A lookup type consists of lookups that are static values in a list of values. Lookup code validation is a one to one match.

A table-validated value set may consist of values that are validated through a SQL statement, which allows the list of values to be dynamic. The following table brings out the differences between a lookup type and a value set.

Tip: You can define a table-validated value set on any table, including the lookups table. Thus, you can change a lookup type into a table-validated value set that can be used in flexfields.
Area of Difference Lookup Type Value Set

List of values

Static

Dynamic if the list is table-validated

Validation of values

One to one match of meaning to code included in a lookup view, or through the determinant of a reference data set

Validation by format or inclusion in a table

Format type of values

char

varchar2, number, and so on

Length of value

Text string up to 30 characters

Any type of variable length from 1 to 4000

Duplication of values

Never. Values are unique.

Duplicate values allowed

Management

Both administrators and end-users manage these, except system lookups or predefined lookups at the system configuration level, which can't be modified.

Usually administrators maintain these, except some product flexfield codes, such as GL for Oracle Fusion General Ledger that the end-users maintain.

Both lookup types and value sets are used to create lists of values from which users select values.

A lookup type cannot use a value from a value set. However, value sets can use standard, common, or set-enabled lookups.

A tag is an additional label attached to the lookup. Tags are user defined and can be grouped depending on the user's requirement to make search convenient and effective.

The same tag may be used across lookup categories. In such cases, tags are used as a refined search criterion to filter information across several groups and get the search result.

Use the Query By Example functionality to sort through hundreds of lookup codes for a lookup type, and display a specific lookup code. Enter the first few characters of the lookup code value in any of the relevant fields to filter the records.

Note: The search functionality is case sensitive.

Messages

Messages provide users with information about business or application errors or warnings.

Typically, messages inform the users about the following:

  • Missing or incorrect data

  • Status of an application, page, or a business object

  • Status of an ongoing process

  • Result of a user action

Besides notifying users about the problem, messages provide guidance to users on taking corrective action. Messages also warn users about the consequences of a certain action.

Oracle provides a set of predefined messages that are stored in a message dictionary. You can create additional messages or modify the existing ones using the Manage Messages task in the Setup and Maintenance work area.

Note: Don't delete predefined messages unless you are sure that they aren't used anywhere.

Message Dictionary

The message dictionary stores messages that the application requires at run time. Messages are predefined for specific applications and modules, but a few are common messages that can be used in any application or module.

When you create messages, use the message text and the following components to cover additional details addressing users and help desk personnel:

  • User Details: A detailed explanation of the message short text meant for users.

  • Administrator Details: Details of the identified problem meant for the help desk personnel. The end users don't see this text.

  • Cause: An end-user version of the cause of error.

  • User Action: Instructions to users for addressing the identified problem. Where there is no guidance for end users, they must approach the help desk.

  • Administrator Action: Corrective action that help desk personnel must take to correct the problem. This information is not available to the end users.

All messages must be associated with a message type. You can select the message type based on the message severity.

The available message types are:

  • Error

  • Warning

  • Information

  • UI String

Error Messages

Use the Error message to inform users about, for example, entering incorrect data or performing actions that trigger validation. Error messages also inform users how to correct the situation so that they can continue with their task.

For example: You cannot specify a task without specifying the project.

Error messages also tell users about any serious problem with the application or process, and when they must seek assistance from the help desk. Some error messages trigger incidents or logs and have a mechanism to notify the help desk automatically.

Warning Messages

Use the Warning message type to inform users about an application condition or a situation that might require their decision before they can continue.

Warning messages:

  • Describe the reason for the warning and potential consequence of the selected or intended user action.

  • Can be either a question or a statement.

For example: You delete the primary user. Do you want to continue?

The message is usually followed by Yes and No buttons.

Information Messages

The Information message type tells users about changes in the application, a page, or a business object. These messages aren't triggered by users, and they don't have to take any immediate action in response.

For example: No events have been started or processed for this employee.

Use the Information message type to communicate information that is neither an error nor a warning.

UI String Messages

Use the UI string message type to store shorter messages such as UI prompts, titles, or translated text, in the message dictionary.

You can group messages by severity to internally define logging and classifying incident policies. You can group by category based on the functionality or program.

Category and severity values don't appear in logging entries, incidents, or on the UI.

Note: The values in both options are predefined lookups but you can modify them. However, the maximum size of this field is 30 characters.

To group the messages, in the Setup and Maintenance work area, use the Manage Messages task.

Group by Category

Use this option to group messages that relate to one functionality, such as a scheduled process, together into one category. Select one of the predefined categories to enable automatic incident creation when the error message activates. By default, the following categories are available:

  • Product: Issues related to product functionality, setup, and maintenance. Such messages are typically intended for functional administrators or product super users.

  • System: Issues concerning the application, database, technology stack, and so on. Such messages are typically intended for technical users such as application administrators or database administrators.

  • Security: Issues concerning permissions, access, compliance, passwords, and so on. Such messages are typically intended for security administrators.

Group by Severity

This grouping attribute is very specific and indicates the severity of the message. You must set the severity to High to enable automatic incident creation for the message. The following are predefined values, but you can add more if required.

  • High: Used for serious messages that completely stop the progress of an important business process or affect a large user community, and require help desk's attention. Use this option to enable implicit incident creation for the message.

  • Medium: Used for less severe and more isolated messages.

  • Low: Used when you can't determine whether the message has a negative impact on end users or business processes.

Logging and Incidents

Select the Logging Enabled check box to include the UI message in the stored log file. To enable automatic incident creation when the error message appears on the UI, set the severity to High.

Incidents collect information about the application errors for which users may require assistance from help desk. An incident contains information about the state of the application at the time the problem occurred. Help desk can use the information in the incidents to resolve the problems.

You can create messages or edit the predefined messages stored in the message dictionary.

Creating a Message

To create a message, perform the following steps:

  1. In the Setup and Maintenance work area, go to the Manage Messages task.

  2. On the Manage Messages page, click the New icon.

  3. On the Create Message page, enter details in each section.

  4. In the Message Properties section:

    1. Enter a unique message name that helps you find the messages you create and avoid name conflicts with predefined messages. Use underscore as a separator if the name contains multiple parts.

    2. Select the application and module to associate the message with.

    3. Enter a unique number that can be used as an identifier for the message. Users can quote this number when they contact the help desk for assistance.

      Note: You can use any number between 10,000,000 and 10,999,999. This number range is allocated for the messages you create. At runtime, this number appears along with the application code after the message text, for example FND-2774.
    4. In the Translation Notes field, enter a description of the message indicating its use.

    5. Select the relevant message type, category, and severity.

    6. Select the Logging Enabled check box to create incidents or logs when messages appear on the UI.

  5. In the Message Text section:

    1. In the Short Text field, provide the actual message text that appears on the page at runtime.

      The short text can include tokens that are placeholders for displaying dynamic values at runtime. However, to support easy translation, keep the message length (including values of tokens) within 160 characters in American English.

    2. In the User Details field, enter information for the users to know why the message appeared. You can also include information for the users to resolve the issue themselves.

      If your Short Text component has tokens that expand the text beyond the 160-character limit, move that portion of text here.

    3. In the Administrator Details field, provide a detailed technical explanation of the message. This field is only visible to the help desk.

    4. In the Cause field, provide a concise explanation of why the message appears. This text is visible to the users.

      This information is optional and is only applicable to messages of type Error and Warning. However, if you mention the cause, you must mention in the User Action field the action that users must take.

    5. In the User Action field, enter the user action to guide the users with steps to respond to the message and complete the task.

    6. In the Administrator Action field, provide information that the help desk can use to resolve the problem.

  6. In the Message Tokens section, define tokens that you want to use in this message.

  7. Click Save and Close.

Editing a Message

You can edit a predefined message or a message that you created.

To edit a message, search for a message on the Manage Messages page and perform the following steps:

  1. Select the existing message and click the Edit icon.

  2. On the Edit Message page, modify the existing details according to the instructions provided in the Creating a Message procedure.

    Note: Don't edit the message number for predefined messages.
  3. Click Save and Close.

While creating and editing messages, you can translate the message details to the preferred languages without changing the language session of the application. To specify the translations in all the enabled language rows, use the Translation Editor option. Once the updates are made, users can view the translated text for the specific details.

Use of Tokens in Messages

Certain messages must display variable information at run time to help users clearly relate to the actual data and perform the required action. You can use tokens to contain variable values at run time, instead of writing a unique message for every possible situation.

Tokens are programmatic parts of message text that are placed within curly brackets when creating the message. Tokens serve as placeholders for the actual data. At run time, tokens dynamically display the actual text or value in the message, making a message specific to the situation. For example, the message "Enter an effective date that is the same as or later than {MATURITY_DATE}" contains the token {MATURITY_DATE}. At run time, instead of the token, the represented value (the actual date) appears. Thus, users see the message "Enter an effective date that is the same as or later than 25-APR-2015".

Use the Manage Messages task in the Setup and Maintenance work area to create and manage tokens. You must edit a message to define tokens for it. You can create tokens for a message and also delete them. However, you can't edit or delete the predefined tokens.

Token Definition

To define a token, you must provide the following information:

  • A unique name for the token.

  • The type of data that the token replaces at run time. Available types are Date, Number, or Text.

  • A description about what the token represents at run time.

Guidelines

Follow these general guidelines while defining tokens:

  • Use curly brackets and all uppercase letters for the token names.

  • Use underscore as a separator for a name containing two words or more.

  • Don't use a space between words.

The following table contains specific guidelines for each token data type.

Data Type Guideline

Text

Use tokens for substituting any variable text element that qualifies as a noun.

Number

Plan carefully while using tokens for numbers especially, where a token could refer to either a singular or a plural number. You can use tokens for numbers representing an order, customer, or any other business object bearing a numeric value.

Date

Clearly define the context of the date, such as the start date, or end date, or a date range.

Message names that begin with FND_CMN are common messages. Each common message can appear in multiple places in any product family across Oracle Applications Cloud. For example, the FND_CMN_NEW_SRCH message can be used for any search to indicate that no results were found. Common messages of type error or warning are part of the message dictionary.

Creating and Editing Common Messages

You can create common messages for use in multiple places. However, ensure that you follow the predefined naming convention and numbering series associated with the application or module.

Note: Don't use FND_CMN as the prefix for the messages you create because all the predefined common messages begin with it.

Common messages can be used in any application. Therefore, consider the ramifications if you edit any aspect of the message, including incident and logging settings. Changes would be reflected in all instances where the message is used. For example, if you change the message text, ensure that the text is generic and applies to the entire site of Oracle Applications Cloud implementation.

How can I make message components visible only to specific users?

Use the Manage Administrator Profile Values task to determine the visibility of the message components. For the Message Mode profile option, set the profile value to either User or Administrator. Based on the set value, the administrator or user actions and details appear for the intended audience.

However, the message components are visible to the audience based on their predefined access rights. Anyone having a user level access can't view the Administrator message components. If you set the profile value to the administrators of a specific product, the message components are visible only to that specific audience.

Note: If you don't set any value to the profile option, the visibility of the message component is determined by the default profile option settings.

Document Sequences

You can assign a document sequence number to each business document or business event to uniquely identify it. For example, you can assign a document sequence number to an invoice that gets generated in response to a purchase order. However, you must enable the document sequencing option for that business document or event to start assigning the number. A document sequence number is useful in tracking completed or failed transactions.

You can set up document sequencing in three different modes:

  • Automatic

  • Manual

  • Gapless

Note: Plan your document sequencing carefully before you start applying sequence numbers. Avoid switching to a different mode after you saved your work on the Manage Document Sequences and Manage Document Sequence Categories pages.

Automatic Sequencing

Automatic document sequencing assigns a unique number to each document automatically when the document is generated. That unique number is stored in the database. You can set an initial value for the numbering sequence. Thereafter, the numbering is sequential by date and time of creation. If you don't provide an initial value, the application sets the default initial value as 1.

Manual Sequencing

Use the manual sequencing mode to assign a unique number to each document before the document is generated. In manual sequencing, the numeric ordering and completeness of a transaction is not automatically enforced. As a result, users can skip or omit numbers when entering the sequence value. However, each time a user assigns a number, the application validates its uniqueness.

Gapless Sequencing

Gapless sequencing is similar to automatic sequencing. It automatically generates a unique number for each document, but does that only for successfully generated documents. Sequence numbers are not assigned to incomplete or failed documents. As a result, the sequence is maintained for all the successfully generated documents.

Additionally, you can control the gapless document sequencing by enforcing the Transaction Date Validation option. When enabled, this option checks for the transaction date of a particular document and assigns the sequence number accordingly, to chronologically maintain the documents. The sequence numbers and the transaction dates are chronologically correlated to prevent any mismatch of a new document sequence assigned to an older document or an older document sequence assigned to a new document.

Note: Use this type of sequencing only if necessary because it may affect the performance of the application and slow down transaction processing.

A document sequence category is a set of documents that share similar characteristics and that are formed into a logical group. Document sequence categories simplify the task of assigning number sequences to specific documents. Instead of assigning a number to each document, you assign a document sequence to one or more document sequence categories. The document sequence category automatically takes care of numbering the documents.

A document sequence category identifies the database table that stores documents resulting from transactions that your users enter. When you assign a sequence to a category, the sequence numbers the documents that are stored in a particular table. You must create document sequence categories to be able to manage the task of assigning document sequences.

Note: Once a document sequence category is created, you can't change the application, the category code, or the table name. Therefore, carefully consider these details and plan your document sequencing requirement before you begin working with the application.

Once you create a document sequence category, it is available for use in the Document Sequences: Assignments section on the Manage Document Sequences page. The Category field contains the name of the document sequence category. After you create a document sequence, you can assign it to a document sequence category.

Guidelines for Managing Document Sequences

Sequencing documents is an important business and legal requirement. Therefore, you must first decide the appropriate document sequence to use for a set of documents. Before you begin, here are a few prerequisites:

  • Determine beforehand the mode of document sequencing, because you can't switch to other types once a sequence is in use.

  • Note details such as the document sequence and document sequence category, for later reference.

  • Identify if there are any restrictions or configuration prerequisites.

Note: Products that implement document sequencing have specifications about its usage. Refer to the corresponding product documentation for specific details and also to determine if there are any restrictions or configuration prerequisites.

Creating and Editing Document Sequences

You can create document sequences that are automatic, manual, or gapless, depending on the business or legal requirement. By default, the current date is considered as the start date. The sequence definition never expires if you don't provide an end date. Among the several options used in creating and editing document sequences, the following options are functionally more important and therefore must be carefully determined:

  • Determinant Type: Select to limit the document sequencing activity to certain documents that belong to a specific business entity, such as Ledger, Tax Registration, and so on.

  • Initial Value: Enter a value for the first document in your sequence. This field applies only to sequences with automatic or gapless numbering types. Sequence numbers must not be greater than eight digits. If you leave this field blank, the first document is automatically assigned a value of 1. Once a document sequence is defined, you can't change this initial value.

Creating and Editing Document Sequence Categories

Document sequence categories are defined to make it easy to assign document sequence definitions to a group of documents instead of to individual documents. Each document sequence category is mapped to a specific table, where the documents belonging to that category are stored. When specifying the table, you must consider the following points:

  • When the sequential numbering feature checks for completeness or generates a report, it locates the category's documents in the table.

  • Select only those tables that belong to the application associated with the category.

  • Once a category is defined, you can't switch to another table.

Assigning Document Sequences

Identify the documents to be numbered before assigning them a document sequence. For each document sequence, there can be only one active assignment to a document sequence category, and a determinant value (if applicable). As part of the assignment, specify whether the document is created automatically (for example, due to a batch process, or manually through a form). If you don't specify an end date, the assignment continues to remain active throughout the process cycle. If a determinant type was specified for the document sequence, then enter a specific determinant value related to the determinant type.

At run time, when users create documents, the document sequence to be assigned is determined based on the following:

  • An active assignment that matches the correct combination of category

  • The numbering method

  • The date range containing the transaction date

Auditing Document Sequences

You can audit document sequences, if required, to provide an audit trail of the document sequences used in a specific product. However, before enabling the audit functionality for a document sequence, you must have created an audit table for the specific document sequence, using appropriate details. Enabling the audit functionality is permitted only for newly created document sequences. You can't audit document sequences that are already in use by a specific product.

For more information about defining a document sequence audit table, see the Oracle Fusion Applications Developer's Guide.

Trees

Trees are hierarchical data models that you can use to organize data, apply business rules, control data access, and improve performance while querying. For example, an application maintains data of an organization called Vision Corporation that has two departments: Marketing and Finance. The Finance department has two functional divisions: Receivables and Payables. You can define a tree for Vision Corporation to establish a hierarchy across its departments, and their respective functional divisions. You can use the hierarchy to manage data at various levels of the organization.

To work with trees, in the Setup and Maintenance work area, use any of the following tasks:

  • Manage Tree Structures: To create and update tree structures. You must first define a tree structure to create a tree.

  • Manage Trees and Tree Versions: To create and update trees and their versions.

  • Manage Tree Labels: To create and update tree labels.

Tree Structures

As the name suggests, tree structures provide you the framework to organize data such that you can establish a hierarchy for use by the tree. So, similar to a template, a tree structure guides the creation of a tree.

Tree

A tree is an instance of the tree structure. The root node is the highest nodal point of a tree. Child nodes branch off from the root node. Child nodes at the same level, branching off from a common parent node, are called siblings. Leaves are details branching off from a node but not extending further down the tree hierarchy. You can create trees for multiple data sources and share them across applications.

Tree Versions

A tree by default has only one version. If required, you can create and maintain more than one editable tree version. At any point, only one tree version must be active. If you edit an existing version, it changes from active to draft. To use it again, you must set it to active. Similar to any other version control system, versions of trees are maintained to track all the changes that a tree undergoes in its life cycle.

Tree Labels

Tree labels are short names given to trees and tree structures. You can label the tree versions for better accessibility and information retrieval. When nodes are created in a tree, the existing tree labels are automatically assigned to the new tree nodes. You can use any table to store the labels and register the label data source with the tree structure.

Tree Structures

A tree structure defines the hierarchy for creating trees and prescribes rules based on which trees are created, versioned, and accessed. You can associate multiple data sources with a tree structure. A tree is an instance of this hierarchy. Every tree structure can contain one or more trees.

You can create tree structures specific to an application but you can share tree structures across applications. If you apply version control to the tree structure, it is carried over to the trees that are based on the tree structure. Each tree version contains at least one root node. Occasionally, a tree version may have more than one root node.

An administrator controls the access to tree structures through a set of rules that are periodically audited for validity.

While creating a tree structure, you must specify important details on the Create Tree Structure: Specify Definition page. As the source of the tree structure, you may either select the predefined tree structures and proceed with the definition or create tree structures.

Tree Node Selection

The data in Tree Node table maps to the data in nodes of the tree structure. You must select the correct and most appropriate tree node table to define the tree structure, based on which you establish the tree hierarchy. This selection also affects the level of security that is set on a tree node and its child entities.

Tree Sharing Mode

Use the following options to determine the mode of sharing a tree structure across the applications.

  • Open: Indicates that the tree is associated with all reference data sets.

  • Set ID: Indicates that the tree is associated with a specific reference data set.

Modification

You can modify the predefined tree structures as well as those you create. However, modifying a predefined tree structure is restricted and permitted through additional privileges. Modification is limited to specific tree nodes and lower in the tree hierarchy.

Multiple Tree Versions

Although multiple tree versions can exist together, Oracle recommends only one version be active at any given time. However, if required, you can have more tree versions to be in the active state for the same date range. You can use this flexibility to select the tree version you want to implement.

You can create, edit, and delete tree structures. You can also change the status of a tree structure and audit the changes.

Creating and Editing Tree Structures

When you edit an active tree structure, the status of the tree structure and all associated trees and their versions changes to draft. To reuse a tree structure, create a copy of the tree without copying the associated trees and tree versions. After making changes, set the status again to active. If you delete a tree structure, all the associated trees and tree versions are automatically deleted.

For information about working with the offering-specific predefined tree structures, refer to the relevant product documentation.

Status

When you change the status of a tree structure, the status of the trees and tree versions associated with that tree structure also changes.

The following table lists the different statuses of a tree structure.

Status Meaning

Draft

In a modified state, or not yet in use.

Active

In use, indicating that one or more trees or tree versions are created from the tree structure.

Inactive

Not in use.

Use the tree structure audit results to verify the tree structure's correctness and data integrity. The audit results include the following details:

  • The name of the validator, which is a specific validation check

  • The result of the validation, including a detailed message

  • Corrective actions to take if there are any validation errors

Running an Audit

Setting the status of a tree structure to active automatically triggers an audit of that tree structure. To manually trigger an audit, select Audit from the Actions menu on the Manage Tree Structures page. The Tree Structure Audit Result table shows a list of validations that ran against the selected tree structure.

Audit Validators

The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.

Validator Page Description (what is validated) Possible Cause for Validation Failure Suggested Corrective Action

Restrict By Set ID

Manage Tree Structures: Specify Data Sources

If you select the Reference Data Set check box for the Restrict Tree Node List of Values Based on option, each of its data source view objects must have a reference data set attribute.

Even when the check box is selected, one or more data source view objects doesn't contain a reference data set attribute.

If reference data set restriction is required for this tree structure, include a reference data set attribute on all data sources. Otherwise, deselect the check box.

Available Label Data Sources

Manage Tree Structures: Specify Data Sources

If you select a list item from Labeling Scheme to specify a labeling scheme, the label data source view object specified for each data source must be accessible. Also, the primary keys must be valid. This restriction doesn't apply if you select None from the list.

  • Any of the specified label data source view objects doesn't exist.

  • Any of the specified label data source view objects doesn't have primary keys.

  • When a label data source view object is initially defined, the database registers the primary keys for the view object. If the view object is later modified such that its primary keys no longer match the primary keys that were registered earlier, this validation fails.

  • Correct the specified label data source view object.

  • Correct the primary keys of the specified label data source view object.

  • Do one of the following:

    • Correct the primary keys in the label data source view object to match the primary keys that were earlier registered in FND_TS_DATA_SOURCE.

    • Correct the primary keys registered in that table to match the new view object definition.

Row Flattened Table Name

Manage Tree Structures: Specify Performance Options

You must specify a valid row flattened table for the tree structure. It can either be the standard row flattened table FND_TREE_NODE_RF or another table.

  • The specified table doesn't exist in the database.

  • The specified table doesn't contain the same columns as the FND_TREE_NODE_RF table.

Correct the row flattened table definition.

Available Data Sources

Add Data Source

Each data source view object specified for the tree structure must be accessible, and all its primary key attributes must be valid.

  • Any of the specified data source view objects doesn't exist.

  • When you define a data source view object, keep the Use non-defined primary key columns check box deselected. The database automatically registers the primary keys for the view object. Select this check box if you want the database to register the primary keys you specify. However, if the registered primary keys contain any duplicates, this validation fails.

  • The Use non-defined primary key columns check box is selected in a data source, but the list of specified primary key columns doesn't match the primary keys defined in the corresponding data source view object.

  • Any common attribute that exists in both the data source view object and the tree node view object isn't of the same data type in both view objects.

  • Correct the specified data source view object.

  • Correct the duplicate column in the registered primary keys.

  • Correct the primary keys of the specified data source view object.

  • Correct any mismatch in data types.

Column Flattened Table Name

Manage Tree Structures: Specify Performance Options

You must specify a valid column flattened table for the tree structure. It can either be the standard row flattened table FND_TREE_NODE_CF or another table.

  • The specified table doesn't exist in the database.

  • The specified table doesn't contain the same columns as the FND_TREE_NODE_CF table.

Correct the column flattened table definition.

Restrict by Date

Manage Tree Structures: Specify Data Sources

If you select the Date Range check box for the Restrict Tree Node List of Values Based on option for a tree structure, each of its data source view objects must have effective start date and end date attributes. This validation doesn't take place when the check box isn't selected.

Even when the check box is selected, one or more of its data source view objects doesn't contain effective start date and end date attributes.

If the date restriction is required for this tree structure, include the effective start date and effective end date attributes on all data sources. Otherwise, deselect the check box.

Tree Node Table Name

Manage Tree Structures: Specify Definition

You must specify a valid tree node table for the tree structure. It can either be the standard row flattened table FND_TREE_NODE or another table.

  • No table is specified in the Tree Node Table field.

  • The specified table doesn't exist in the database.

  • The specified table doesn't contain the same columns as the FND_TREE_NODE table.

Correct the tree node table definition.

The data sources provide the items for establishing hierarchy in a tree structure. In the tree management infrastructure, these data sources are Oracle ADF business components view objects, which are defined by application development.

Labeling Schemes

Selecting a labeling scheme determines how the tree nodes are labeled. You may select a labeling scheme to assign at the data source level, at the parent node level, or keep it open for customers assignment. You may also choose not to have any labeling scheme. However, if you decide to use any of the labeling schemes, select the following additional options, to restrict the list of values that appear in the selected tree node.

  • Allow Ragged Nodes: To include nodes that have no child nodes, and are shorter than the remaining nodes in the entire hierarchy.

  • Allow Skip Level Nodes: To include nodes that are at the same level but have parent nodes at different levels.

Restriction of Tree Node Values

You can decide the depth of the tree structure by selecting an appropriate value from the list. Keeping the depth limit open renders an infinite list of values.

Using the following options, you can restrict the list of values that appear for selection in a specific tree node.

  • Date Range: Specifies whether a selection of nodes should be restricted to the same date range as the tree version.

  • Allow Multiple Root Nodes: Allows you to add multiple root nodes when creating a tree version.

  • Reference Data Set: Specifies whether a selection of nodes should be restricted to the same set as the tree.

Data Source Values and Parameters

Tree data sources have optional data source parameters with defined view criteria and associated bind variables. You can specify view criteria as a data source parameter when creating a tree structure, and edit the parameters when creating a tree. Multiple data sources can be associated with a tree structure and can have well-defined relationships among them.

Note: Parameter values modified at the tree level override the default values specified at the tree-structure level.

The data source parameters are applied to any tree version belonging to that data source, when performing node operations on the tree nodes. Data source parameters also provide an additional level of filtering for different tree structures. The tree structure definition supports three data source parameter types.

  • Bound Value: Captures any fixed value, which is used as part of the view criteria condition.

  • Variable: Captures and binds a dynamic value that is being used by the data source view object. This value is used by the WHERE condition of the data flow.

  • View Criteria: Captures the view criteria name, which is applied to the data source view object.

You can also specify which of the data source parameters are mandatory while creating or editing the tree structure.

View objects from the Oracle ADF business components are used as data sources. To associate the view object with the tree structure, you can pick the code from Oracle ADF business component view objects and provide the fully qualified name of the view object, for example, oracle.apps.fnd.applcore.trees.model.view.FndLabelVO.

Tree structures are heavily loaded with data. As a tree management guideline, use the following settings to improve performance of data rendering and retrieval.

  • Row Flattening

  • Column Flattening

  • Column Flattened Entity Objects

  • BI View Objects

Row Flattening

Row flattening optimizes parent-child information for run-time performance by storing additional rows in a table for instantly finding all descendants of a parent without initiating a CONNECT BY query. Row flattening eliminates recursive queries, which allows operations to perform across an entire subtree more efficiently.

To store row flattened data for the specific tree structure, users can either use the central FND_TREE_NODE_RF table or they can register their own row flattened table. For example, in a table, if Corporation is the parent of Sales Division (Corporation-Sales Division), and Sales Division is the parent of Region (Sales Division-Region), a row-flattened table contains an additional row with Corporation directly being the parent of Region (Corporation-Region).

Column Flattening

Column flattening optimizes parent-child information for runtime performance by storing an additional column in a table for all parents of a child.

To store column flattened data for the specific tree structure, users can either use the central FND_TREE_NODE_CF table or they can register their own column flattened table. For example, in a table, if Corporation is the parent of Sales Division (Corporation-Sales Division), and Sales Division is the parent of Region (Sales Division-Region), a flattened table in addition to these columns, contains three new columns: Region, Sales Division, and Corporation. Although positioned next to each other, the column Region functions at the lower level and Corporation at the higher level, retaining the data hierarchy.

Column Flattened Entity Object

In the absence of a column-flattened table, if you need to generate the business component view objects for your tree structure for the flattened table, use the tree management infrastructure to correctly provide the fully qualified name of the entity object for the column flattened table.

BI View Object

View objects from Business Intelligence can be used as data sources, eliminating the need to create new types of data sources. This field is to store the fully qualified name for the BI view object generated by the tree management for business intelligence reporting and usage The BI view object is a combination of the tree data source and column flattened entity. Using this option prevents data redundancy and promotes greater reuse of existing data, thereby improving the performance of the tree structure.

Search View Object

Specify the full name of the view object for the tree node to ensure that search operations performed on the tree node are efficient.

Tree Labels

Tree labels are tags that are stored on tree nodes. You can store labels in any table and register the label data source with the tree structure. When a labeling scheme is used for trees, the selected labels are stored in the tree label entity, and each tree node contains a reference to a tree label in the labeling scheme.

The following table lists the three ways in which tree labels are assigned to the tree nodes.

Labeling Scheme Description

Level

Labels that are automatically assigned based on the data source to which the tree node belongs. A level label points to a specific data source. For example, in a tree that reflects the organizational hierarchy of an enterprise, all division nodes appear on one level and all department nodes on another.

Group

Labels that you can arbitrarily assign to tree nodes.

Depth

Labels that are automatically assigned based on the depth of the tree node within the tree. No manual assignment is performed.

Note: In an unbalanced hierarchy, a level may not be equal to depth.

Trees and Tree Versions

You can create and edit trees and tree versions depending upon the requirement. A tree can have one or more tree versions. When changes are made to an existing tree, a new version is created and published.

Creating and Editing Trees

Trees are created based on the structure defined in the tree structure. You can create trees, modify existing trees, and delete trees. If you want to copy an existing tree, you can duplicate it. You can also select and copy the associated tree versions.

Creating a tree involves specifying the tree definition and specifying the labels that are used on its nodes. If the selected tree structure has data sources and parameters defined for it, they appear on the page allowing you to edit the parameter values at the tree node level.

Note: Parameter values modified at the tree level will override the default values specified at the tree-structure level.
Creating and Editing Tree Versions

Tree versions are created at the time of creating trees. Each tree must contain a version.

Editing an existing tree provides you with the option of updating the existing version. You can also edit the existing version that lies nested in the tree in the search results.

When you edit a tree version bearing Active status, the status changes to Draft until the modifications are saved or canceled. To edit a tree version while keeping the status active select the Update tree nodes while keeping the tree version active Check Box.

Use the tree version audit results to verify the tree version's correctness and data integrity. The audit results include the following details:

  • The name of the validator, which is a specific validation check

  • The result of the validation, including a detailed message

  • Corrective actions to take if there are any validation errors

Running an Audit

An audit automatically runs whenever a tree version is set to active. You can also manually trigger an audit on the Manage Trees and Tree Versions page, using Actions > Audit. If you run an audit on a tree version, which is in Draft status, and want to change the status to Active after the audit is complete then select the Set tree version status to active after audit is successfully complete Check Box.

The Tree Version Audit Result table shows a list of validations that ran against the selected tree version.

Validation Details

The following table lists the validators used in the audit process and describes what each validator checks for. It also lists possible causes for validation errors and suggests corrective actions.

Validator Description (what is checked) Possible Cause for Validation Failure Suggested Corrective Action

Effective Date

The effective start and end dates of the tree version must be valid.

The effective end date is set to a value that is not greater than the effective start date.

Modify the effective start and end dates such that the effective start date is earlier than the effective end date.

Root Node

On the Manage Tree Structures: Specify Data Sources page, if the Allow Multiple Root Nodes check box for the Restrict Tree Node List of Values Based on option is not selected, and if the tree structure is not empty, the tree version must contain exactly one root node. This validation does not take place if the check box is selected.

Even if the check box is deselected, the tree version has multiple root nodes.

Modify the tree version such that there is exactly one root node.

Data Source Maximum Depth

For each data source in the tree structure, on the Data Source dialog box, if the data source is depth-limited, the data in the tree version must adhere to the specified depth limit. This validation doesn't apply to data sources for which the Maximum Depth field is set to Unlimited.

The tree version has data at a depth greater than the specified depth limit on one or more data sources.

Modify the tree version such that all nodes are at a depth that complies with the data source depth limit.

Duplicate Node

On the Data Source dialog box, if the Allow Duplicates check box isn't selected, the tree version must not contain more than one node with the same primary key from the data source. If the check box is selected, duplicate nodes are permitted.

Even when the check box is deselected, the tree version contains duplicate nodes.

Remove any duplicate nodes from the tree version.

Available Node

All nodes in the tree version must be valid and available in the underlying data source.

  • A node in the tree version doesn't exist in the data source. Deleting data items from the data source without removing the corresponding nodes from the tree version can result in orphaned nodes in the tree version. For example, if you added node A into your tree version, and subsequently deleted node A from the data source without removing it from the tree version, the validation fails.

  • The tree version contains a tree reference node, which references another tree version that does not exist.

Remove any orphaned nodes from the tree version. Update tree reference nodes so that they reference existing tree versions.

Node Relationship

All nodes must adhere to the relationships mandated by the data sources registered in the tree structure.

The tree structure has data sources arranged in a parent-child relationship, but the nodes in the tree don't adhere to the same parent-child relationship. For example, if the tree structure has a Project data source with a Task data source as its child, Task nodes must always be within Project nodes in the tree version. This validation fails if there are instances where a Project node is added as the child of a Task node.

Modify the tree version such that the nodes adhere to the same parent-child relationships as the data sources.

SetID Restricted Node

On the Manage Tree Structures: Specify Data sources page, if the Set ID check box is selected to enable the Restrict Tree Node List of Values Based on option for each tree node, the underlying node in the data source must belong to the same reference data set as the tree itself. This restriction doesn't apply when the check box is not selected.

Even when the check box is selected, the tree version has nodes whose data source values belong to a different reference data set than the tree.

Modify the tree version such that all nodes in the tree have data sources with reference data set matching that of the tree.

Label Enabled Node

On the Manage Tree Structures: Specify Data Sources page, if a labeling scheme is specified for the tree structure by selecting a list item from the Labeling Scheme list, all nodes must have labels. This restriction doesn't apply when you select None from the Labeling Scheme list.

The tree structure has a labeling scheme but the tree version has nodes without labels.

Assign a label to any node that doesn't have a label.

Date Restricted Node

On the Manage Tree Structures: Specify Data Sources page, if the Date Range check box is selected to enable the Restrict Tree Node List of Values Based on option for a tree structure, each node in the underlying data source must have an effective date range same as the effective date range of the tree version. This restriction doesn't apply if the check box isn't selected.

Even when the check box is selected, there are data source nodes that have a date range beyond the tree version's effective date range. For example, if the tree version is effective from Jan-01-2012 to Dec-31-2012, all nodes in the tree version must be effective from Jan-01-2012 to Dec-31-2012 at a minimum. It is acceptable for the nodes to be effective for a date range that extends partly beyond the tree version's effective date range (for example, the node data source value is effective from Dec-01-2011 to Mar-31-2013). It isn't acceptable if the nodes are effective for none or only a part of the tree version's effective date range (for example, the node data source value are effective only from Jan-01-2012 to June-30-2012).

Ensure that all nodes in the tree version have effective date range for the effective date range for the tree version.

Multiple Active Tree Version

On the Manage Tree Structures: Specify Definition page, if the Allow Multiple Active Tree Versions check box isn't selected for the tree structure, there must not be more than one active tree version for a tree at any time. This restriction doesn't apply if the check box is selected.

Even when the check box isn't selected, there is more than one active tree version in the tree for the same date range.

Set no more than one tree version to Active within the same date range and set the others to inactive or draft status.

Range Based Node

On the Data Source dialog box, if the Allow Range Children check box isn't selected, range-based nodes are not permitted from that data source. This restriction doesn't apply if the check box is selected.

Even when the check box isn't selected, there are range-based nodes from a data source.

Ensure that any range nodes in your tree version are from a data source that allows range children.

Terminal Node

On the Data Source dialog box, if the Allow Use as Leaves check box isn't selected, values from that data source can't be added as leaves (terminal nodes) to the tree version. This restriction doesn't apply if the check box is selected.

Even when the check box isn't selected, values from a data source are added as leaf nodes (terminal nodes).

Modify the tree version such that all terminal nodes are from data sources for which this check box is selected.

Usage Limit

On the Data Source dialog box, if the Use All Values option is selected to set the Usage Limit for the data source, every value in the data source must appear as a node in the tree. This restriction doesn't apply if None option is selected.

Even if the Use All Values option is selected, there are values in the data source that aren't in the tree version.

For each data source value that isn't yet available, add nodes to the tree version.

Data sources are the foundation of tree management. Tree structures, trees, and tree versions establish direct and real-time connectivity with the data sources. Changes to the data sources immediately reflect on the Manage Trees and Tree Versions page and wherever the trees are being used.

Metadata and Data Storage

Tree structures contain the metadata of the actual data and the core business rules that manifest in trees and tree versions. You can select and enable a subset of trees to fulfill a specific purpose in that application.

Access Control

Source data is mapped to tree nodes at different levels in the database. Therefore, the changes you make to the tree nodes affect the source data. Access control set on trees prevents unwanted data modifications in the database. Access control can be applied to the tree nodes or anywhere in the tree hierarchy.

Tree nodes are points of data convergence where a tree branches into levels. Nodes are the building blocks of a tree structure and are attached to tree versions. Whenever you create or edit a tree version, you need to specify its tree node.

In the Setup and Maintenance work area, open the panel tab and click Search to search for the Manage Trees and Tree Versions task.

Managing Tree Nodes

You can create, modify, or delete tree nodes on the Tree Version: Specify Nodes page. To add a tree node, ensure that the tree structure with which the tree version is associated is mapped to a valid data source. You can also duplicate a tree node if the multiple root node feature is enabled.

Node Levels

Usually, the nodes at a particular level represent similar information. For example, in a tree that reflects the organizational hierarchy, all nodes representing divisions appear at one level and all the department nodes on another. Similarly, in a tree that organizes a user's product catalog, the nodes representing individual products might appear at one level and the nodes representing product lines on the immediate higher level.

The following node levels are in use:

  • Root node: The highest node in the tree structure

  • Parent node: The node that branches off into other nodes

  • Child node: The node that is connected to a node higher in hierarchy (parent node)

  • Sibling node: Nodes that are at the same level and belong to the same parent node

  • Leaf node: Entities branching off from a node but not extending further down the tree hierarchy

Node Types

A tree node has the following node types.

  • Single: Indicates that the node is a value by itself.

  • Range: Indicates that the node represents a range of values and possibly could have many children. For example, a tree node representing account numbers 10000 to 99999.

  • Referenced Tree: Indicates that the tree node is actually another version for the tree based on the same tree structure, which is not physically stored in the same tree. For example, a geographic hierarchy for the United States can be referenced in a World geographic hierarchy.

Profile Options

Profile options are a set of preferences that you use to centrally manage the user interface settings and application behavior.

You can use the profile options to manage, for example:

  • User preferences to specify language or currency.

  • Configuration choices to change the user interface skin or appearance of fonts.

  • Processing options to determine how much of an activity needs to be logged and at which level.

In the Setup and Maintenance work area, use any of the following tasks:

  • Manage Profile Options

  • Manage Profile Categories

  • Manage Administrator Profile Values

The following table contains a functional description of each task.

Task Name Function

Manage Profile Options

Create new profile options or modify existing profile options, except some which are predefined and restricted to prevent any modifications.

Manage Profile Categories

Group the profile options based on their functional similarities.

Manage Administrator Profile Values

Set the profile values for the enabled profile options to control application behavior.

The hierarchy in profile levels determines the context for making a profile option effective.

You can enable a profile option at the following levels:

  • Site level (lowest): The entire site of deployment

  • User level (highest): A specific user

After you create or edit a profile option on the Manage Profile Options page, you must enable it. You can enable it at multiple levels. The setting at the highest enabled level takes precedence over the lower levels. User level is the highest in the hierarchy and always takes precedence over the settings at the site level.

On the Manage Administrative Profile Values page, set the profile value at any of the enabled levels of the profile option.

Example of Profile Option Hierarchy

The following table shows an example of setting the currency profile option at different levels.

Profile Level Hierarchy Currency

Site

Lowest

Euro

User

Highest

US Dollar

For this example, there are two users, John and Lisa. For John, the user-level profile value currency is set to US Dollar. If the Currency profile option is enabled only at the site level, both John and Lisa would see Euro as the default currency. If the profile option is enabled at the user level, users having a different currency set as their currency profile value would see only that currency. In this case, John would see US Dollar as the default currency. If the Currency profile option is enabled at the user level and there is no user level currency defined, the site level setting takes effect. When both site and user levels are enabled, the value for the user level takes precedence over the site level value.

Set Profile Option Values

Each profile option contains specific values that determine how it affects the application. You can add or modify the values for each profile option. Select or enter the value for one or more of the available levels (site, product, and user) so that each setting takes effect at the intended level.

Setting the Profile Value

  1. In the Setup and Maintenance work area, go to the Manage Administrator Profile Values task.

  2. On the Manage Administrator Profile Values page, search for and select the profile option.

  3. In the Profile Values section, click Add. A new row is added for you to specify the following conditions:

    • Profile Level: Specify the level at which the profile value is to be set. If the profile value applies to the entire site, select Site.

    • Product Name: If you select Product as the profile level, select a product and specify the associated profile value.

    • User Name: If you select User as the profile level, select the user name and specify the associated profile value.

    • Profile Value: Select or enter the value corresponding to the selected profile level.

    Note: For an existing entry, you can modify only the profile value.
  4. Repeat step 3 to add more rows and set the profile values.

  5. Click Save and Close.

Note: Changes in the profile values take effect for a user on the next sign in.

Import Profile Values

Use the Import option on the Manage Administrator Profile Values page to import profile values in bulk and associate them with a profile option.

Prerequisite

The file containing the profile values is available in the document repository of Oracle WebCenter Content.

Importing Profile Values

To import profile values:

  1. In the Setup and Maintenance work area, go to the Manage Administrator Profile Values task.

  2. In the Profile Option: Profile Values section, from the Actions menu, select Import.

  3. On the Import User Profile Values dialog box, select the WebCenter Content account to which the file was uploaded.

  4. Enter the name of the file containing the profile values. The name here must match with the name of the file uploaded to the selected account.

  5. Click Upload. The profile values are imported.

    Note: If the import fails, click the link to the log file on the confirmation dialog box and examine the cause of failure.

File Format for Importing Profile Values

To import profile option values into the application, you create a text file with the values and upload the file to the Oracle WebCenter Content document repository. The file must follow a specific format, as described here. After the file is in the document repository, you can then import the profile values into the application following the instructions in the Importing Profile Option Values: Procedure topic.

To create a file containing the profile values, include the following headers:

  • ProfileOptionCode: The profile option code.

  • LevelName: Must contain the value (Site, Product, or User).

  • UserName: Must correspond to the registered user name in the application. Don't provide any other shortened or coded name of the user.

  • ProfileOptionValue: The profile value to be imported.

While creating the file, adhere to the following guidelines:

  • Use a vertical bar or pipe ( | ) as a delimiter between fields for both header and value rows.

  • Set the file encoding to UTF-8 without the Byte Order Mark (BOM), as per the Oracle WebCenter Content specification.

Here's a sample file that contains the header values at the beginning of the file, followed by line entries of the two profile values that are to be imported. For importing several profile values, add more line entries in a similar format.

ProfileOptionCode|LevelName|UserName|ProfileOptionValue
AFLOG_BUFFER_MODE|USER|APP_IMPL_CONSULTANT|TEST
AFLOG_LEVEL|USER|APPLICATION_DEVELOPER|FINEST

Create and Edit Profile Options

Use profile options to manage user preferences and control the general function of applications. For example, you can control user preferences involving language, date, time, currency, and other similar general settings.

You can create a profile option and also determine the level at which that profile option takes effect. You can also define the profile values for the profile option. The profile values appear on the Manage Administrator Profile Values page when you select the profile option.

Creating a Profile Option

  1. In the Setup and Maintenance work area, go to the Manage Profile Options task.

  2. On the page, click Actions > New.

  3. On the Create Profile Option page, fill all the fields with relevant details with specific attention to the following:

    • Use the SQL Validation field to provide an SQL statement that displays the permissible profile values to be used. Using an SQL statement, you can select the values from another table and display them as a list of values.

      For example, to display the values Yes and No from a lookup table, you can use the following SQL statement:

      select MEANING, LOOKUP_CODE from FND_LOOKUPS where LOOKUP_TYPE='YES_NO'

      As a result, on the Manage Administrator Profile Values page, the profile values Yes and No are available for selection for that profile option.

    • You can specify a date range to keep the profile option active during that period. Beyond the specified duration, the profile option automatically becomes inactive. If you no longer require the profile option, you must manually delete it from the Manage Profile Options page.

  4. Click Save and Close.

  5. On the Manage Profile Options page, search for the newly created profile option and from the results, select it.

  6. In the Profile Option Levels section, do the following:

    1. In Enabled, select the levels at which you want to enable the profile option.

      Note: You can enable a profile option at multiple levels, but a higher-level profile value overrides a lower-level value. Therefore, enable them only at the required levels.
    2. In Updatable, select the profile level at which you want implementors to have update privileges. Leave the check box deselected if you don't want the implementors to modify the profile values (they appear in read-only mode).

  7. Click Save and Close.

To edit a profile option that you created, search for it and edit the necessary details.

Note: While creating and editing profile options and profile categories, you can translate the details to the preferred languages without changing the language session of the application. To specify the translations in all the enabled language rows, use the Translation Editor option. Once the updates are made, users can view the translated text for the specific details.

You can create profile categories to group profile options based on their functional similarities and their use. In the Setup and Maintenance work area, use the Manage Profile Categories task.

Profile categories help administrators or implementors in retrieving profile options using a search criterion on the Manage Administrator Profile Values page.

Managing Profile Categories

Consider the following options while managing profile categories:

  • Create profile categories and add existing profile options to them

  • Add newly created profile options to existing user-defined profile categories

Note: While you can add a profile option to more than one category, some profile categories are predefined and restricted from any modifications. So, you can't edit them or add profile options to them.

Setting Display Sequence for the Profile Options

You must set the display sequence for each profile option that you add to a profile category. Display sequence determines the order in which the profile options appear in a search result, based on the profile category. You can set the sequence beginning with zero or one for the first profile option to display, and proceed sequentially to assign the values to the remaining profile options.

The following table demonstrates the effect of the display sequence on the profile options when they are retrieved as search results.

Profile Category Included Profile Option - Assigned Display Sequence Display Sequence of Profile Options in the Search Results

Attachments

  • Attachment File Directory - 2

  • Indicate Attachments - 1

  1. Indicate Attachments

  2. Attachment File Directory

How can I access predefined profile options?

Search for predefined profile options using the Manage Profile Options task.

  1. In the Setup and Maintenance work area, go to the Manage Profile Options task.

  2. On the page, enter any of the search parameters and click Search.

    Tip: If you don't know the profile option code or the display name, use the Application or Module fields to filter search results.
  3. Click a profile option to view its details.

Flexfields

A flexfield is a set of placeholder fields associated with business objects and placed on the application pages to contain additional data. You can use flexfields to modify the business objects and meet enterprise data management requirements without changing the data model or performing any database programming. Flexfields help you to capture different data on the same database table and provide a means to modify the applications features.

For example, an airline manufacturer may require specific attributes for its orders that aren't predefined. Using a flexfield for the order business object, you can create and configure the required attribute.

Types of Flexfields

Flexfields that you see on the application pages are predefined. However, you can configure the flexfields or modify their properties. Users see these flexfields as field or information attributes on the UI pages. To manage flexfields, use any of the following tasks in the Setup and Maintenance work area:

  • Manage Descriptive Flexfields: Expand the forms on the application page to accommodate additional information that is important and unique to your business. You can use a descriptive flexfield to collect invoice details on a page displaying invoices.

  • Manage Extensible Flexfields: Establish one-to-many data relationships and make application data context-sensitive. The flexfields appear only when the contextual data conditions are fulfilled. Thus, extensible flexfields provide more flexibility than the descriptive flexfields.

  • Manage Key Flexfields: Store information combining several values, such as a number combination. The key flexfields represent objects such as accounting codes and asset categories.

  • Manage Value Sets: Use a group of values to validate the data entered in the flexfields.

    Note: You can manage value sets within the Manage Descriptive Flexfields or Manage Extensible Flexfields tasks.

Flexfield Components

A flexfield is made up of several data entities that store and render information pertaining to flexfield configuration.

Flexfields are made up of the following components:

  • Segments

  • Value Sets

  • Contexts

  • Structures

Segments

A segment is a field within a flexfield and represents a single table column of your database. When configuring a flexfield, define the appearance and meaning of individual segments. Segments represent attributes of information. Segments can appear globally wherever the flexfield is implemented, or based on a structure or context. Each segment captures a single atomic value and represents an attribute of information.

The characteristics of a segment vary based on the type of flexfield in which it's used.

  • In key flexfields, a segment describes a characteristic of the entity. For example, a part number that contains details about the type, color, and size of an item.

  • In a descriptive or extensible flexfield, a segment represents an information attribute on the application page. For example, details about a device containing components, some of which are global while the remaining are contextually dependent on the category of the device.

Value Sets

Users enter values into segments while using an application. A value set is a named group of values that validate the content of a flexfield segment. You configure a flexfield segment with a value set to enforce entries of only valid values for that segment.

The configuration involves the following tasks:

  • Defining the values in a value set, including characteristics such as the length and format of the values.

  • Specifying formatting rules or values from an application table or predefined list.

Multiple segments within a flexfield, or multiple flexfields, can share a single value set.

Contexts

Context-sensitive flexfield segments are available to an application based on a context value. You define contexts as part of configuring a flexfield. Users see global segments as well as any context-sensitive segments that apply to the selected context value.

In descriptive flexfields and extensible flexfields, you can reuse the context-sensitive segments that are based on the database columns, in multiple contexts.

Structures

Key flexfields have structures. Each key flexfield structure is a specific configuration of segments. Adding or removing segments, or rearranging their order, produces a different structure. You can reuse the segments that are based on the database columns, in multiple structures.

Note: You can translate all these flexfield components to the preferred languages without changing the language session of the application. To specify the translations in all the enabled language rows, use the Translation Editor option on the respective edit pages. Once the updates are made, users can view the translated text for the specific flexfield components at runtime.

Overview of Flexfield Configuration

Configuring a flexfield involves identifying the need for enhancing a business object with user-defined attributes and then integrating the attributes into deployment. In the case of key flexfields, configuring the flexfield involves identifying value set assignments and determining segment structures.

Overall Process for Configuring User-Defined Attributes

Before using flexfields to create attributes, familiarize yourself with the context layers and the configuration life cycle of the application. You can add attributes to a business object using a flexfield, if developers have registered that object to a flexfield. For descriptive and extensible flexfields, the overall configuration process involves the following:

  1. Use the Highlight Flexfields feature from the Administration menu to find flexfields on pages associated with business objects.

  2. Plan the flexfield configuration.

  3. Plan flexfield validation.

  4. Define the attributes by configuring the flexfield segments.

    1. Use the Manage Extensible Flexfields or Manage Descriptive Flexfields tasks, or use the Configure Flexfield icon button directly on the page where the flexfield is highlighted. For simple configurations, use the Add Segment, Add Context Value, and Edit Segment icon buttons directly on the page where the flexfield is highlighted.

    2. Optionally, validate the flexfield configuration.

    3. Optionally, deploy the flexfield to a sandbox for initial testing.

  5. Deploy the flexfield to the mainline metadata to display the attributes on the application pages and to make them available for integration with other tools such as Oracle Business Intelligence.

  6. Perform the necessary steps to integrate the attributes into the technology stack.

A simple configuration is limited to such actions as adding a format-only field or adding a field with a basic list of values.

Overall Process for Configuring User-Defined Keys

Using key flexfields, you can configure intelligent key codes containing meaningful parts according to your business practices. You configure the key flexfield to have one segment for each part that makes up your key code.

For key flexfields, the overall configuration process involves the following:

  1. Use the Highlight Flexfields feature from the Administration menu to find flexfields on pages associated with business objects.

  2. Plan the flexfield configuration.

  3. Plan the flexfield validation.

  4. Define the value sets before configuring the key flexfield segments by going to the Manage Value Sets task.

  5. Define the key flexfield structures and their segments, and define structure instances for each structure.

    1. Use the Manage Key Flexfields task or the Configure Flexfield icon button directly on the page where the flexfield is highlighted.

    2. Optionally, validate the flexfield configuration.

    3. Optionally, deploy the flexfield to a sandbox for initial testing.

  6. Deploy the flexfield to the mainline metadata to display it on the application pages and to make it available for integration with other tools such as Oracle Business Intelligence.

  7. Perform the necessary steps to integrate the flexfield into the technology stack.

Flexfields at Runtime

Business objects have an associated descriptive or extensible flexfield. Using these, you can create attributes for the business object at run time. Some business objects have an associated key flexfield for configuring flexible multiple part keys.

Finding Flexfields on a Page

At run time, the attributes you define as flexfield segments appear in the application page just like any other attribute. However, each type of flexfield appears in a different way.

The following characteristics help you determine the type of flexfield on the application page:

  • Descriptive flexfield segments appear as label and field pairs or as a table of fields that correspond to the column headers. The fields represent the flexfield segments and accept values that derive from the segment's assigned value set.

  • Extensible flexfield segments appear grouped within labeled regions, where each grouping is a context and the region labels are the context names.

  • Key flexfields appear in the application page as a field with a key flexfield icon, where the field's value is a collection of segments.

To locate flexfields on a page, in the global header, select your user name and in the Settings and Actions menu, select Highlight Flexfields. The page renders in a special mode, displaying the location of flexfields, if any, on the page. Do the following:

  • Hover over the Information icon to view flexfield details.

  • Click the Configure Flexfield icon to manage the flexfield using the Manage Flexfields task.

  • Click the Add Context Value, Add Segment, or Edit Segment icons to add a context value or edit a global or context-sensitive flexfield segment. This applies to both descriptive and extensible flexfields.

Note: You can't create attributes on all flexfields. For example, some flexfields are protected, and you either can't edit their configurations at all, or can do only limited changes to them. Consult the product-specific documentation to verify whether there are any restrictions on using the flexfield.

All segments of a single flexfield are grouped together by default. The layout and positions of the flexfield segments depend on where the application developer places the flexfield on the page. Flexfields may also be presented in a separate section of the page, in a table, or on their own page or a dialog box. You can use Oracle Composer to edit the layout, position, or other display features of the flexfield segments.

When you no longer want to view the flexfields on a page, select Unhighlight Flexfields from the Administration menu.

Flexfield Modification Using Page Composer

You can use Page Composer to modify flexfields specific to a page.

Extensible Flexfield Modification

In Page Composer, open the page with the flexfield you want to modify. Switch to Source view, and look for a region that is bound to an EffContextsPageContainer task flow. This is the container for the extensible flexfield attributes and contexts. To view the flexfield code and identifying information, open the properties panel for the region. To modify any component within the region, select the desired tag and click Edit.

Descriptive Flexfield Modification

In Page Composer, open the page with the flexfield you want to modify. Switch to Source view, and look for the <descriptiveFlexfield> element of that flexfield. Open the properties panel for this element to view the flexfield code and identifying information. Within the properties panel, you may modify properties for the global and context-sensitive segments or re-order the segments on the page.

Note: Flexfield segments can't be edited using their individual component elements. They can only be edited from the properties panel of the <descriptiveFlexfield> element they belong to. To find these components, open the properties panel of the descriptive flexfield, switch to the relevant tab, and search using the unique identifying information. For instance, if you need to find a context sensitive segment, open the properties panel for the flexfield, go to the Flexfield Context Segments tab, and search for the segment using its Context Value and Segment Code.

How Flexfields Work with Oracle Application Cloud Architecture

To capture additional data, administrators or implementors configure flexfield segments that represent attributes of business objects. Business objects are enabled for both descriptive flexfields and extensible flexfields.

The following figure shows the layers involved in configuring a flexfield:

  • The business entity table and metadata in the database.

  • The ADF business component objects. These are derived from the metadata and stored in Oracle Metadata Services (MDS) repository.

  • The user interface where fields defined by the flexfield segments are rendered.

The following figure illustrates that the flexfield definition consists of all the metadata defined during configuration and stored in the database.

The figure displays the workflow of defining flexfield
and adding capacity in the database to enable flexfield segments through
applications development. After a flexfield is created and registered,
administrators configure it so that the definition is stored in the
database. The associated business components are deployed to the Metadata
Services repository. As a result, the attributes representing the
flexfields are available in the user interface, making those business
components accessible.

Application developers create a flexfield and register it so that it's available for configuration. Administrators and implementation consultants configure segments and other properties of the available flexfields. This information is stored as additional flexfield metadata in the database. Deploying the flexfield generates ADF business components based on the flexfield metadata in the database.

The following aspects are important in understanding how flexfields and Oracle Applications Cloud architecture work together:

  • Integration

  • Deployment

  • Import and export

  • Run time

  • Patching

Integration

The attributes that you add by configuring flexfields are available throughout the Oracle Fusion Middleware technology stack. You can use the flexfield segment's Application Programming Interface (API) to identify segments and integrate the flexfields in the following:

  • User interface pages

  • Service-oriented Architecture (SOA) infrastructure

  • Oracle Business Intelligence

  • Extended Spread Sheet Database (ESSbase)

Flexfield configurations are preserved across application updates.

Deployment

The metadata for the flexfield is stored in the application database as soon as you save your configuration changes. Deploying the flexfield generates the ADF business components so that the run time user interface reflects the latest flexfield definition in the metadata.

Importing and Exporting

Using the Setup and Maintenance work area, you can import and export flexfields across the implementation site. The deployment status must be either Deployed or Deployed to sandbox. Therefore, before you attempt migration, verify and ensure that a flexfield is successfully deployed.

Run Time

The latest definitions of a flexfield reflect on the user interface at run time only if the flexfield is deployed. When the user interface accesses a business object, the deployed flexfield definition identifies the attributes associated with the captured values. On a page, if you add display configurations for a flexfield using Oracle Composer, the same flexfield segments can appear differently on different pages.

Patching

Flexfield configurations are preserved during patching and upgrading.

Flexfield Management

Managing flexfields involves registering, planning, and configuring flexfields.

You plan and configure the registered flexfields provided in your applications by applications developers. How you configure flexfield segments determines how the flexfield segments appear to users. Optionally, you can modify the UI page to change how the flexfield segments appear to users on that page.

The following figure shows the processes involved in making flexfields available to users. The tasks in the Define Flexfields activity let administrators configure and deploy flexfields. After you configure and deploy a flexfield to a sandbox, deploy it again to the mainline metadata so that it's available to the users.

The figure shows the workflow from planning to
making the flexfield available to users. Configuration and deploying
falls within the tasks of the Define Flexfield activity

Consider the following aspects of managing flexfields:

  • Registering flexfields

  • Planning flexfields

  • Configuring flexfields

  • Enabling a flexfields segment for business intelligence

  • Deploying flexfields

  • Optionally changing a flexfield segment's appearance in a user interface page

  • Identifying flexfields on a run time page and troubleshooting

Registering Flexfields

A flexfield must be registered before it can be configured. Therefore, application development registers flexfields so that they are available to administrators and implementation consultants for configuration. The registration involves reserving columns of entity tables for use in flexfields. For more information about registering flexfields, see Oracle Fusion Applications Developer's Guide.

Planning Flexfields

Before you begin planning flexfields, determine what type is appropriate to your needs, and which business objects are available for modifying flexfields. All flexfields consist of segments which represent attributes of an entity. The value a user enters for an attribute is stored in a column of the entity table. Carefully plan flexfields before configuring them. Before configuring new segments for your flexfields, be sure to plan their implementation carefully.

If you have determined that a business object supports flexfields, and those flexfields have been registered, you can begin planning their configuration. Note the code name of the flexfield you intend to configure so that you can find it easily in the Define Flexfield activity. In some cases you can determine and configure how the flexfield appears on the page. See Oracle Applications Cloud Help for specific products to determine any restrictions on using product-specific flexfields.

Configuring Flexfields

Administrators or implementors configure flexfields so they meet the needs of the enterprise. Some flexfields require configuration to make an application operate correctly. You can configure flexfields using the following methods:

  • Go to the manage flexfield tasks in the Setup and Maintenance work area.

  • Use the Highlight Flexfields command in the Administration menu while viewing a run time page.

    • Use the Configure Flexfield icon button to manage all aspects of a flexfield, such as change a segment's sequence number or configure a flexfield segment's business intelligence label.

    • Use the Add Segment and Edit Segment icon buttons to add and edit descriptive or extensible flexfield segments with simple configurations.

    • Use the Add Context icon button to add descriptive or extensible flexfield context values.

Configuring a flexfield includes the following:

  • Defining value sets against which the values entered by users are validated

  • Defining the structure or context of the segments in the flexfield

  • Specifying the identifying information for each segment

  • Specifying the display properties such as prompt, length and data type of each flexfield segment

  • Specifying valid values for each segment, and the meaning of each value within the application

Tip: You can create value sets while creating descriptive and extensible flexfield segments. However, define value sets before configuring key flexfield segments that use them, because you assign existing value sets while configuring key flexfield segments.

When creating table-validated, independent, dependent, or subset value sets while creating descriptive and extensible flexfield segments, you can optionally specify to display the description of the selected value next to the segment at run time. You can assign sequence order numbers to global segments and to context-sensitive segments in each context. Segment display is always in a fixed order based on the segments' sequence numbers. You cannot enter a number for one segment that is already in use for a different segment. Therefore, you may consider numbering the segments in multiples, such as 4, 5, or 10, to make it easy to insert new attributes.

A flexfield column is assigned to a new segment automatically, but you can change the assignment before saving the segment. If you must set a specific column assignment for a segment, create that segment first to ensure that the intended column isn't automatically assigned to a different segment.

Enabling a Flexfield Segment for Business Intelligence

You can enable flexfield segments for business intelligence if the flexfield is registered in the database as an Oracle Business Intelligence-enabled flexfield. For more information about enabling segments for business intelligence, see points to consider when enabling descriptive, extensible, and key flexfield segments for business intelligence. For extensible flexfield segments, you can't assign labels to equalize segments across contexts that are semantically equivalent.

Deploying Flexfields

Once you have configured a flexfield, you must deploy it to make the latest definition available to run time users. In the Define Flexfields tasks, you can deploy a flexfield using either of the following commands:

  • The Deploy Flexfield command deploys a flexfield to the mainline metadata. This command is for general use in a test or production environment.

  • The Deploy to Sandbox command deploys a flexfield to sandbox. This command is for confirming that the flexfield is correctly configured before deploying it to the mainline metadata.

In Highlight Flexfields mode, when using the:

  • Add Context, Add Segment, and Edit Segment tools for extensible flexfields, use the Save command to save your changes. Then use the Deploy command to deploy the flexfield to the mainline metadata

  • Add Segment and Edit Segment tools for descriptive flexfields, use the Save and Deploy command to save your changes. Then deploy the flexfield to the mainline metadata

Once deployed, the deployment status indicates the state of the currently configured flexfield relative to the last deployed definition.

Optionally Changing a Flexfield Segment Appearance

The flexfield attributes that you define integrate with the user interface pages where users access the attributes' business object. Application development determines the UI pages where business objects appear and the display patterns used by default to render flexfield segments.

After a flexfield has been deployed to the mainline MDS repository so that it appears on application pages, you can modify it on a per-page basis using Page Composer. For example, you can hide a segment, change its prompt or other properties, or reorder the user-defined global attributes so that they are interspersed with the core attributes in the same parent layout. You can modify the appearance of descriptive and extensible flexfield segments in the UI page using Page Composer, once the flexfield is deployed to the mainline metadata.

If the applications are running in different locales, you can provide different translations for translatable text, such as prompts and descriptions. Enter translations using the locale that requires the translated text. In the global header, click your user name and from the Settings and Actions menu, select Set Preferences. Then change the text to the translated text for that locale.

Identifying Flexfields on a Run Time Page

The Highlight Flexfields command in the Administration menu of the Setup and Maintenance work area identifies the location of flexfields on the run time page by displaying an Information icon button for accessing details about each flexfield.

Even if a descriptive or extensible flexfield isn't yet deployed and no segments appear on the run time page in normal view, the flexfield appears in the Highlight Flexfield view for that page. For descriptive flexfields, the segments as of the last deployment appear. For extensible flexfields, any segments and contexts that have been saved but not yet deployed also appear as disabled.

Highlight Flexfields accesses the current flexfield metadata definition. Use the highlighted flexfield's Configure Flexfield icon button to manage flexfields directly. Alternatively, note a highlighted flexfield's name to search for it in the tasks for managing flexfields.

For more information about creating flexfields and adding them to a UI page, see the Oracle Fusion Applications Developer's Guide. For more information about modifying flexfield segment appearance with Page Composer, see guidance on modifying existing pages in the Oracle Applications Cloud Configuring and Extending Applications guide.

Flexfield Segment Properties

Independent of the value set assigned to a segment, segments may have properties that affect how they are displayed and how they function.

The following aspects are important in understanding

  • Display properties

  • Properties related to segment values

  • Properties related to search

  • Range validation segments

  • Rule validation of segment values

  • Naming conventions

Display Properties

The following table summarizes display properties.

Property Description

Enabled

Whether the segment can be used.

Sequence

The order the segment appears in relation to the other configured segments.

Prompt

The string to be used for the segment's label in the user interface.

Display type

The type of field in which to display the segment.

Selected and deselected values

If the display type is check box, the actual values to save. For example, Y and N or 0 and 1.

Display size

The character width of the field.

Display height

The height of the field as measured in visible number of lines when the display type is a text area.

Read only

Whether the field should display as read-only, not editable text.

Description help text

The field-level description help text to display for the field. Use description help text to display a field-level description that expands on or clarifies the prompt provided for the field.

If description help text is specified, a Help icon button is displayed next to the field in the run time application. The description help text is displayed when the user hovers over the Help icon button.

Instruction help text

The field-level instruction help text to display for the field.

Use instruction help text to provide directions on using the field. If instruction help text is specified, it's appears in an in-field help note window when users move the cursor over the field.

Properties Related to Search

Extensible flexfield segments can be marked as selectively required in search using the indexed property. The indexed property requires users to enter a value before conducting a search on the attribute represented by the indexed segment. A database administrator must create an index on the segment column representing the indexed attribute.

Range Validation of Segments

Range validation enables you to enforce an arithmetic inequality between two segments of a flexfield. For example, a product must be ordered before it can be shipped. Therefore, the order date must be on or before the ship date. Also, the order date segment value must be less than or equal to the ship date segment value. You can use range validation to ensure this relationship.

The conditions for range validation are as follows:

  • Segments must be configured for range validation in pairs, one with the low value and one with the high value.

  • Both segments must be of the same data type.

  • Both segments must be parts of the same structure in a key flexfield or parts of the same context in a descriptive flexfield or extensible flexfield.

  • The low value segment must have a sequence number that is lesser than that of the high value segment.

  • Non-range validated segments can exist between a range validated pair, but range validated pairs cannot overlap or be nested.

You can configure as many range validated pairs as you want within the same flexfield. Your application automatically detects and applies range validation to the segment pairs that you define, in sequence order. It must detect a low value segment first, and the next range validated segment that it detects must be a high value segment. These two segments are assumed to be a matching pair. The low value and the high value can be equal.

Rule Validation of Segment Values

Validation rules on descriptive and extensible flexfield segments determine how an attribute is validated. The value entered for an attribute on a business object may must match a specified format or be restricted to a list of values. Use a value set to specify the validation rules.

Value set validation is required for global segments and context-sensitive segments, and optional for context segments. In the case of context segments, the application may validate a value instead of the value set validating the value against the context segment. However the application entered values must match exactly the valid context segment values. If the context segment values are a superset or subset of the input values, you must assign a table-validated value set or independent value set to validate context values.

When you configure a descriptive flexfield segment, you can specify a constant to use for setting the initial value. The initial value can be an available parameter. For every planned segment, list the constant value or parameter, if any, to use for the initial value.

Naming Conventions

Enter a unique code, name, and description for the segment. These properties are for internal use and not displayed to end users. You can't change the code after the segment is created.

The Application Programming Interface (API) name is a name for the segment that isn't exposed to users. The API name is used to identify the segment in various integration points including web services, rules, and business intelligence. Use alphanumeric characters only with a leading character. For example, enter a code consisting of the characters A-Z, a-z, 0-9 with a non-numeric leading character. The use of spaces, underscores, multi-byte characters, and leading numeric characters isn't permitted. You can't change the API name after the segment has been created.

Application Programming Interface (API) name is a name for your flexfield component, which isn't exposed to users. These names are used to identify flexfield components in various integration points, including web services, rules, and business intelligence.

How to Frame API Names

You must use only alphanumeric characters for API names. For example, enter a name with the characters A-Z, a-z, or 0-9, with a non-numeric leading character. Don't use spaces, underscores, multi-byte characters, or leading numeric characters in your API names.

Caution: Do not change API names after they are created. Doing so could break integration points.
Words You Can't Use for API Names

You can't use certain words for API names when configuring flexfields because they are reserved words in ADF, SQL, PL/SQL, Java, Groovy, and so on.

This table lists some of the reserved words that can't be used as API names. This list is not exhaustive.

Letter Reserved Words

A

ABORT, ABSTRACT, ACCEPT, ACCESS, ACTIONENABLED, ADD, ALL, ALLROWSINRANGE, ALTER, AND, ANY, ARRAY, ARRAYLEN, AS, ASC, ASSERT, ASSIGN, AT, ATTRIBUTEDEF, ATTRIBUTEDEFS, ATTRIBUTEVALUE, ATTRIBUTEVALUES, AUDIT, AUTHORIZATION, AVG

B

BEGIN, BETWEEN, BINDINGS, BODY, BOOLEAN, BREAK, BY, BYTE, BYVALUE

C

CASCADE, CASE, CAST, CATCH, CATEGORY, CHAR, CHECK, CHILDREN, CLASS, CLONE, CLOSE, CLUSTER, CLUSTERS, COALESCE, COLAUTH, COLUMN, COLUMNS, COMMENT, COMMIT, COMPRESS, CONNECT, CONST, CONSTANT, CONSTRIANT, CONTAINS, CONTINUE, COUNT, CRASH, CREATE, CURRENT, CURRENTROW, CURRVAL, CURSOR

D

DATABASE, DATACONTROL, DATE, DBA, DEBUGOFF, DEBUGON, DECIMAL, DECLARE, DEFAULT, DEFINITION, DELAY, DELETE, DELTA, DESC, DESCRIPTION, DIGITS, DISPLAY, DISPLAYDATA, DISPLAYHINT, DISPLAYHINTS, DISPOSE, DISTINCT, DIV, DO, DOUBLE, DROP

E

ELSE, ELSIF, EMPTY, ENABLED, ENABLEDSTRING, END, ENTRY, EQ, EQUALS, ERROR, ESTIMATEDROWCOUNT, EXCEPTION, EXCLUSIVE, EXISTS, EXIT, EXTENDS

F

FALSE, FETCH, FILE, FINAL, FINALIZE, FINALLY, FINDMODE, FLOAT, FOR, FORM, FROM, FULLNAME, FUNCTION, FUTURE

G

GE, GENERIC, GETCLASS, GOTO, GRANT, GROUP, GROUPBY, GT

H

HASHCODE, HAVING, HINTS

I

IDENTIFIED, IF, IMMEDIATE, IMPLEMENTS, IMPORT, IN, INCREMENT, INDEX, INDEXES, INDICATOR, INITIAL, INNER, INPUTVALUE, INSERT, INSTANCEOF, INT, INTEGER, INTERFACE, INTERSECT, INTO, IS, ITERATORBINDING

J

JAVA

K

KEY

L

LABEL, LABELS, LABELSET, LE, LEVEL, LIKE, LIMITED, LOCK, LONG, LOOP, LT

M

MANDATORY, MAX, MAXEXTENTS, MIN, MINUS, MLSLABEL, MOD, MODE, MODIFY

N

NAME, NATIVE, NATURAL, NE, NEW, NEXTVAL, NOAUDIT, NOCOMPRESS, NOT, NOTFOUND, NOTIFY, NOTIFYALL, NOWAIT, NULL, NULLIF, NUMBER

O

OF, OFFLINE, ON, ONLINE, OPEN, OPERATIONENABLED, OPERATOR, OPTION, OR, ORDER, ORDERBY, OTHERS, OUT, OUTER, OVERLAPS

P

PACKAGE, PARTITION, PCTFREE, POSITIVE, PRAGMA, PRIMARY, PRIOR, PRIVATE, PRIVILEGES, PROCEDURE, PROTECTED, PUBLIC

R

RAISE, RANGE, RANGESET, RANGESIZE, RANGESTART, RAW, REAL, RECORD, REFERENCES, RELEASE, REMR, RENAME, RESOURCE, REST, RESULT, RETURN, REVERSE, REVOKE, ROLLBACK, ROOTNODEBINDING, ROW, ROWID, ROWLABEL, ROWNUM, ROWS, ROWTYPE, RUN

S

SAVEPOINT, SCHEMA, SELECT, SELECTEDVALUE, SEPARATE, SESSION, SET, SHARE, SHORT, SIZE, SMALLINT, SPACE, SQL, SQLBUF, SQLCODE, SQLERRM, START, STATEMENT, STATIC, STDDEV, SUBTYPE, SUCCESSFUL, SUM, SUPER, SWITCH, SYNCHRONIZED, SYNONYM, SYSDATE

T

TABAUTH, TABLE, TABLES, TASK, TERMINATE, THEN, THIS, THROW, THROWS, TO, TOOLTIP, TOSTRING, TRANSIENT, TRIGGER, TRUE, TRY, TYPE

U

UID, UNION, UNIQUE, UPDATE, UPDATEABLE, USE, USER

V

VALIDATE, VALUES, VAR, VARCHAR, VARCHAR2, VARIANCE, VIEW, VIEWS, VOID, VOLATILE

W

WAIT, WHEN, WHENEVER, WHERE, WHILE, WITH, WORK

X

XOR

How Flexfields Segments are Rendered

Flexfield segments appear on pages as attributes of business objects.

Settings That Affect Flexfield Segment Display

When you configure flexfield segments, the value you enter for the segment's display type determines how the segment appears at run time.

How Display Type Values Appear

The following series of figures (A to K) represent how the display types render on the UI at run time. Each display type screenshot is assigned an alphabet that maps to the display type and its description in the table.

The following figure contains the representation of a check box, a drop-down list, a list of values, and a search enabled list of values.

The figure comprises four display types namely:
A. Check box, B. Drop-down List, C. List of Values, D. Search Enabled
List of Values

The following figure contains the representation of a radio button group, text area, text box, date and time, and rich text editor.

The figure comprises five display types namely:
E. Radio Button Group, F. Text Area, G. Text Box, H. Date and Time,
I. Rich Text Editor

This figure contains the representation of a color palette and a static URL field.

The figure comprises two display types namely:
J. Color, K. Static URL

The following table describes each display type.

Figure Reference Display Type Description

A

Check Box

The field appears as a check box. If the user selects the check box, the checked value is used. Otherwise, the deselected value is used.

B

Drop-down List

The field appears as a list of values available to the user for selection.

C

List of Values

The field appears as a list of values available to the user for selection. The user can also click Search to find more values.

D

Search Enabled List of Values

The field appears as a text field with a Search icon button. The users can type a value in the text field or they can click the Search icon button to open another window for searching.

E

Radio Button Group

The field appears as a set of radio buttons. The user can select one button. Selecting a button deselects any previously selected button in the set.

F

Text Area

The field appears as a text area in which the user can type multiple lines of text. The display width and height specify the visible width and number of lines in the text area, respectively.

G

Text Box

The field appears as a text field in which the user can type a single line of text. The display width controls the width of the text box.

H

Date Time

The field enables the user to enter a date if the data type is Date, or a date and time if the data type is Date Time. The user can select the date in a calendar. If the data type is Date Time, the field also displays fields for specifying the hour, minutes, seconds, AM or PM, and time zone.

I

Rich Text Editor

The field appears as a text area in which the user can enter and edit multiple lines of formatted text. The display width and height specify the visible width and number of lines in the rich text editor, respectively.

Note: This display type is available for extensible flexfields only.

J

Color

The field displays a color palette for the user to select a color at run time and assign it to the segment. During setup, this display type appears in the list for selection only if:

  • You are working on an extensible flexfield segment.

  • The value set for the segment is set to ORA_FND_COLOR_#RRGGBB.

K

Static URL

The field appears as a text field in which users can enter a fixed URL that opens the web page when clicked.

Note: The length of the URL must not exceed 255 characters.

No figure reference available

Hidden

The field isn't displayed.

Value sets are specific to your enterprise. When gathering information using flexfields, your enterprise's value sets validate the values that your users enter based on how you defined the value set.

You can assign a value set to any number of flexfield segments in the same or different flexfields. Value set usage information indicates which flexfields use the value set.

The following aspects are important in understanding how flexfields and value sets work together:

  • Defining value sets

  • Shared value sets

  • Deployment

Defining Value Sets

As a key flexfield guideline, define value sets before configuring the flexfield, because you assign value sets to each segment as you configure a flexfield. With descriptive and extensible flexfields, you can define value sets when adding or editing a segment.

Note: Ensure that changes to a shared value set are compatible with all flexfield segments that use the value set.
Shared Value Sets

When you change a value in a shared value set, the change affects the value set for all flexfields that use that value set. The advantage of a shared value set is that a single change propagates to all usages. The drawback is that the change shared across usages may not be appropriate in every case.

Value Set Values

To configure user-defined attributes to be captured on the value set values screen in the Manage Value Sets task, configure the Value Set Values descriptive flexfield. The object's code is FND_VS_VALUES_B.This flexfield expects the context code to correspond to the value set code. For each value set, you can define a context whose code is the value set code, and whose context-sensitive segments are shown for the values of that value set. By default, the context segment is hidden since it maps to the value set code and is not expected to be changed.

You can also define global segments that are shown for all value sets. However, this would be quite unusual since it would mean that you want to capture that attribute for all values for all value sets.

Deployment

When you deploy a flexfield, the value sets assigned to the segments of the flexfield provide users with the valid values for the attributes represented by the segments.

Default Segment Values

To populate a flexfield segment with a default value when a row is created, specify a default type of constant or parameter, and a default value.

To synchronize a segment's value with another field's value whenever it changes, specify the derivation value to be the flexfield parameter from which to derive the attribute's value. Whenever the parameter value changes, the attribute's value is changed to match. If you derive an attribute from a parameter, consider making the attribute read-only, as values entered by users are lost whenever the parameter value changes. When setting a default value or deriving a default value from a parameter, only those attributes designated by development as parameters are available for selection. Different combinations of making the segments read only or editable in combination with the default or derivation value or both, have different effects.

The following table maps these different combinations. Initial runtime action corresponds to the row for the attribute value being created in the entity table. If the default value is read only, it can't subsequently be changed through the user interface. If the default value isn't read only, users can modify it. However, if the segment value is a derived value, a user-modified segment value is overwritten when the derivation value changes.

Default Type Default value specified? Derivation value specified? Initial runtime action Runtime action after parameter changes

None

No

Yes

No initial segment value

The changed parameter derivation value updates segment value

Constant

Yes

No

Default segment value

N/A

Constant

Yes

Yes

Default segment value

The changed parameter derivation value updates segment value

Parameter

Yes

No

The default segment value is the parameter's default value

N/A

Parameter

Yes

Yes, and same as default value

The default segment value is the parameter's default and derivation value

The changed parameter derivation value updates segment value

Parameter

Yes

Yes, and different from default value

The default segment value is the parameter's default value

The changed parameter default value doesn't update segment value. Only the changed derivation value updates the segment value.

Flexfield Usages

The flexfield usage specifies the table with which the flexfield and its segments are associated. A flexfield can have multiple usages. However, the first table registered for a flexfield indicates the master usage. Segments are based on the master usage. Other usages of the same table for the same flexfield use the same segment setup, though the column names may have a differentiating prefix.

On the Manage Descriptive Flexfields and Manage Extensible Flexfields pages, click the Show Entity Usages icon for a specific flexfield to view its entity usage. On the Manage Value Sets page, you can view the flexfield usages for a selected value set.

Extensible Flexfields

For extensible flexfield contexts, you can configure a different usage. The use of an extensible flexfield context determines the scenarios or user interfaces in which the segments of a context appear to users. For example, the Supplier page displays an extensible flexfield's supplier usage and the Buyer page for the same flexfield displays the buyer usage. Then, a context that is associated only with the supplier usage appears only on the Supplier page and not on the Buyer page.

Value Sets

The use of value sets specifies the flexfields having segments where the identified value set is assigned.

FAQs for Flexfield Management

How can I access predefined flexfields?

Search for predefined flexfields using the manage flexfields tasks.

  1. In the Setup and Maintenance work area, go to any of the following tasks:

    • Manage Descriptive Flexfields

    • Manage Extensible Flexfields

    • Manage Key Flexfields

  2. On the page for the type of flexfield you're looking for, enter any of the search parameters and click Search.

    Tip: If you don't know the flexfield name or the code, use the Module field to filter search results.
  3. Click a flexfield to view its details.

For configuration that's not available through the manage flexfields tasks and the UI, contact My Oracle Support at https://support.oracle.com.

Why can't I edit my flexfield or value set configuration?

Your flexfield or value set configuration may be protected. Application developers mark some configurations as protected, indicating that you can't edit them.

Some examples of configurations that may be protected are:

  • Descriptive flexfields

  • Extensible flexfield contexts

  • Extensible flexfield pages

  • Value sets

Why did my page not display any flexfield?

For a flexfield to be available on the page, it must be registered by developers and also deployed. The segments appear on the page only after you have successfully deployed the flexfield.

A flexfield's deployment status indicates whether the flexfield segments are available to users. The flexfield segments that users see at run time correspond to the flexfield definition last deployed successfully.

For information about registering flexfields, see the Oracle Fusion Applications Developer's Guide. Some business objects aren't designed to support flexfields. For information about how to enable business objects with flexfield capability, see Getting Started with Flexfields in the Oracle Fusion Applications Developer's Guide.

Note: Oracle Engagement Cloud doesn't support flexfields.

To add attributes to these applications, you may use Application Composer. For more information, see the product-specific documentation.

Why did my flexfield changes not appear in the runtime UI?

The ADF business components or artifacts of a flexfield, which are generated into an Oracle Metadata Services (MDS) Repository when the flexfield is deployed, are cached within a user session. You must sign out and sign back in again to view flexfield definition changes reflected in the runtime application user interface page.

How can I enable flexfield segments for Oracle Social Network Cloud Service?

When you manage Oracle Social Network Objects during setup and maintenance, search for the business object that includes descriptive flexfields. Select the attributes that are defined as flexfield segments and enable them.

Flexfield Deployment

Deployment generates or refreshes the Application Development Framework (ADF) business component objects that render the flexfield in a user interface. The deployment process adds user-defined attributes to the Web Services Description Language (WSDL) schemas exposed by Oracle ADF services and used by SOA composites. Flexfields are deployed for the first time during the application provisioning process. After you configure or change a flexfield, you must deploy it to make the latest definition available to users.

If a descriptive flexfield is enabled for business intelligence, the deployment process redeploys the flexfield's business intelligence artifacts.

You can deploy a flexfield to a sandbox for testing or to the mainline metadata for use in a test or production run time environment. You can deploy extensible flexfields as a background process.

After deployment, the user-defined attributes are available for incorporating into the SOA infrastructure, such as business process and business rule integration. For example, you can now write business rules that depend on the user-defined attributes. You must sign out and sign back in to Oracle Applications Cloud to see the changes you deployed at run time.

The following aspects are important in understanding flexfield deployment:

  • Deployment Status

  • Initial Deployment Status

  • Metadata Validations

  • Metadata Synchronization

  • Deployment as a Background Process

  • Export of Artifacts from Flexfield MDS

Deployment Status

Every flexfield has a deployment status. Check the deployment status of your flexfield after patching. The following table lists the different deployment statuses a flexfield can have.

Deployment Status Meaning

Edited

The flexfield metadata definition hasn't been deployed yet. Updates of the metadata definition aren't applied in the run time environment yet.

Patched

The flexfield metadata definition has been modified through a patch or a data migration action, but the flexfield hasn't yet been deployed. So, the updated definition isn't reflected in the run time environment.

Deployed to Sandbox

The current metadata for the flexfield is deployed in ADF artifacts and available as a flexfield-enabled sandbox. The status of the sandbox is managed by the Manage Sandboxes dialog box available in the Settings and Actions menu.

Deployed

The current metadata for the flexfield is deployed in ADF artifacts and available to users. No changes have been made to the flexfield after being deployed to the mainline metadata.

Error

The deployment attempt in the mainline metadata failed.

Note: Whenever a value set definition changes, the deployment status of a flexfield that uses that value set changes to edited. If the change results from a patch, the deployment status of the flexfield changes to patched.
Initial Deployment Status of Flexfields

The Oracle Applications Cloud implementation loads flexfield metadata into the database. This initial load sets the flexfield status to Edited. During installation, the application provisioning process deploys the flexfields of the provisioned applications, setting their status to Deployed if no errors occur.

In a provisioned application, deployed flexfields are ready to use. In some cases, flexfield availability at run time requires setup, such as defining key flexfields.

Metadata Validation

Use the Validate Metadata command to view possible metadata errors before attempting to deploy the flexfield. Metadata validation is the initial phase of all flexfield deployment commands. By successfully validating metadata before running the deployment commands, you can avoid failures in the metadata validation phase of a deployment attempt. The deployment process ends if an error occurs during the metadata validation phase. Metadata validation results don't affect the deployment status of a flexfield.

Metadata Synchronization

When an extensible or descriptive flexfield is deployed, the deployment process regenerates the XML schema definition (XSD). As a result, the user-defined attributes are available to web services and the SOA infrastructure.

After deploying a flexfield configuration, you must synchronize the updated XML schema definition (XSD) files in the MDS repositories for each SOA application.

Note: To synchronize the updated XSD files in the MDS repositories in Oracle Cloud implementations, log a service request using My Oracle Support at http://support.com/
Deployment as a Background Process

You can deploy extensible flexfields offline as a background process and continue working in the session without having to wait for the deployment to complete. You can queue up several extensible flexfields and deploy as a background process. The flexfields are deployed, one at a time, in the order that you deploy them to the queue. You must deploy extensible flexfields with more than 30 categories as a background process.

You can remove an extensible flexfield from the deployment queue with the Cancel Background Deployment command. When an extensible flexfield is deployed in a background process, its offline status indicates that the flexfield is in a background deployment process. A flexfield's offline status is cleared and its deployment status updated when the background deployment process has completed.

Export of Artifacts from Flexfield MDS

You can export business components from MDS for descriptive, extensible, or key flexfields, mainly for use in troubleshooting issues with flexfields. Use Download Flexfield Archive on the Manage Flexfields page to export MDS artifacts of the selected flexfield, and import them to an archive on your local computer. You can use these archived business components of flexfields for troubleshooting purposes.

Alternatively, export the deployed artifacts using exportMetadata WLST.

How Flexfield Deployment Status is Calculated

Flexfield deployment status indicates how the flexfield metadata definition in the Oracle Applications Cloud database relates to the Application Development Framework (ADF) business components residing in an Oracle Metadata Services (MDS) Repository.

The following aspects are important in understanding how flexfield deployment status is calculated:

  • Settings that affect flexfield deployment status

  • How deployment status is calculated

Settings That Affect Flexfield Deployment Status

If you have made a change to a flexfield and expect a changed deployment status, ensure that you have saved your changes. No settings affect flexfield deployment status.

How Deployment Status Is Calculated

If the flexfield definition has been edited through the Define Flexfields activity task flows, the status is Edited. The latest flexfield metadata definition diverges from the latest deployed flexfield definition. Any change, including if a value set used in a flexfield changes, changes the deployment status to Edited. If a flexfield has never been deployed, its status is Edited.

Note: When an application is provisioned, the provisioning framework attempts to deploy all flexfields in that application.

If you deploy the flexfield to a sandbox successfully, the status is Deployed to Sandbox. The latest flexfield metadata definition in the application matches with the metadata definition that generated ADF business components in a sandbox MDS Repository. Whether the sandbox is active or not doesn't affect the deployment status. If the flexfield was deployed to a sandbox and hasn't been edited or redeployed to the mainline metadata since then, the status remains Deployed to Sandbox independent of whether the sandbox is active, or who is viewing the status.

If you deploy the flexfield successfully to the mainline metadata, the status is Deployed. The latest flexfield metadata definition in the application matches the metadata definition that generated ADF business components in a mainline MDS Repository. Change notifications are sent when a flexfield is deployed successfully to the mainline metadata. If either type of deployment fails and that the current flexfield definition isn't deployed, the status is Error. The deployment error message gives details about the error. The latest flexfield metadata definition in the application likely diverges from the latest successfully deployed flexfield definition.

If the flexfield definition has been modified by a patch, the status is Patched. The latest flexfield metadata definition in the application diverges from the latest deployed flexfield definition. If the flexfield definition was Deployed before the patch and then a patch was applied, the status changes to Patched. If the flexfield definition was Edited before the patch and then a patch was applied, the status remains at Edited to reflect that there are still changes (outside of the patch) that aren't yet in effect.

When a deployment attempt fails, you can access the Deployment Error Message for details.

How Deploying a Flexfield-Enabled Sandbox Works with Mainline Metadata

The flexfield definition in a sandbox corresponds to the flexfield metadata definition in the Oracle Applications Cloud database at the time the flexfield was deployed to the sandbox. When the flexfield is ready for end users, the flexfield must be deployed to the mainline metadata.

A flexfield-enabled sandbox uses the following components.

  • Flexfield metadata in the Oracle Applications Cloud database

  • Flexfield business components in a sandbox Oracle Metadata Services (MDS) repository

  • User interface modifications for the flexfield in the mainline MDS repository

The following figure shows the two types of deployment available in the Manage Flexfield tasks of the Define Flexfields activity. Deploying a flexfield to a sandbox creates a sandbox MDS Repository for the sole purpose of testing flexfield behavior. The sandbox is only accessible to the administrator who activates and accesses it, not to users generally. Deploying a flexfield to the mainline metadata applies the flexfield definition to the mainline MDS Repository where it is available to end users. After deploying the flexfield to the mainline metadata, modify the page where the flexfield segments appear. Modifications done to the page in the sandbox MDS Repository cannot be published to the mainline MDS Repository.

The figure shows a flow in the Define Flexfields
activity that includes testing the flexfield in a sandbox and possibly
also making modifications to the MDS data in Oracle Composer after
deploying the flexfield to the mainline metadata for access to users.
Sandbox Metadata Services Repository Data

Deploying the flexfield to a sandbox generates the Application Development Framework (ADF) business components of a flexfield in a sandbox MDS Repository for testing in isolation.

Caution: Don't modify flexfield segment display properties using Page Composer in a flexfield-enabled sandbox as these changes will be lost when deploying the flexfield to the mainline metadata.
Mainline Metadata Services Repository Data

The Oracle Fusion Applications database stores the single source of truth about a flexfield. When the flexfield is deployed, the ADF business component objects that implement the flexfield in the run time user interface are generated in the mainline MDS Repository from this source.

Deploying a flexfield to a sandbox creates a flexfield-enabled sandbox. Each flexfield-enabled sandbox contains only one flexfield.

You can test the run time behavior of a flexfield in the flexfield-enabled sandbox. If changes are needed, you return to the Define Flexfield tasks to change the flexfield definition.

When you deploy a flexfield to sandbox, the process reads the metadata about the segments from the database, generates flexfield Application Development Framework (ADF) business component artifacts based on that definition, and stores in the sandbox only the generated artifacts derived from the definition.

When you deploy a flexfield sandbox, the process generates the name of the flexfield sandbox, and that flexfield sandbox is set as your current active sandbox. When you next sign in to the application, you can see the updated flexfield configurations. The Oracle Applications Cloud global header displays your current session sandbox.

Note: Unlike a standalone sandbox created using the Manage Sandboxes dialog box, the sandbox deployed for a flexfield contains only the single flexfield. You can manage flexfield sandboxes, such as setting an existing flexfield sandbox as active or deleting it, using the Manage Sandboxes dialog box.

When you deploy a flexfield to the mainline metadata after having deployed it to the sandbox, the sandbox-enabled flexfield is automatically deleted.

Sandbox MDS Repository Data

The sandbox data lets you test the flexfield in isolation without first deploying it in the mainline metadata where it could be accessed by users.

Caution: Don't modify flexfield segment display properties using Page Composer in a flexfield-enabled sandbox as these changes will be lost when deploying the flexfield to the mainline metadata.
Managing a Flexfield-Enabled Sandbox

When you deploy a flexfield as a sandbox, that flexfield-enabled sandbox automatically gets activated in your user session. When you sign back in to see the changes, the sandbox is active in your session.

You can only deploy a flexfield to a sandbox using the Define Flexfields task flow pages.

You also can use the Manage Sandboxes dialog box in the Administrator menu of the Setup and Maintenance work area to activate and access a flexfield-enabled sandbox.

Note: Whether you use the Define Flexfields or Manage Sandboxes task flows to access a flexfield-enabled sandbox, you must sign out and sign back in before you can see the changes you deployed in the run time.

You cannot publish the flexfield from the sandbox to the mainline metadata. You must use the Define Flexfields task flow pages to deploy the flexfield for access by users of the mainline metadata because the flexfield configuration in the mainline metadata is the single source of truth.

Value Sets

A value set is a group of valid values that you assign to a flexfield segment to control the values that are stored for business object attributes.

A user enters a value for an attribute of a business object while using the application. The flexfield validates the value against the set of valid values that you configured as a value set and assigned to the segment.

For example, you can define a required format, such as a five-digit number, or a list of valid values, such as green, red, and blue.

Flexfield segments are usually validated, and typically each segment in a given flexfield uses a different value set. You can assign a single value set to more than one segment, and you can share value sets among different flexfields.

Note: Ensure that changes to a shared value set are compatible with all flexfields segments using the value set.

The following aspects are important in understanding value sets:

  • Managing value sets

  • Validation

  • Security

  • Precision and scale

  • Usage and deployment

  • Protected value set data

Managing Value Sets

To open the Manage Value Sets page, use the Manage Value Sets task. You can also use the Manage Descriptive Flexfields and Manage Extensible Flexfields tasks for configuring a segment, including its value set. To open the Manage Values page, select the value set from the Manage Value Sets page, and click Manage Values. Alternatively, click Manage Values from the Edit Value Set page.

Validation

The following types of validation are available for value sets:

  • Format only, where users enter data instead of selecting values from a list

  • Independent, a list of values consisting of valid values you specify

  • Dependent, a list of values where a valid value derives from the independent value of another segment

  • Subset, where the list of values is a subset of the values in an existing independent value set

  • Table, where the values derive from a column in an application table and the list of values is limited by a WHERE clause

A segment that uses a format only value set doesn't present a list of valid values to users. If required, you may add table validated value sets to the list of available value sets available for configuration.

Note: For the Accounting Key Flexfield value sets, you must use independent validation only. If you use other validations, you can't use the full chart of accounts functionality, such as data security, reporting, and account hierarchy integration.
Security

Value set security only works in conjunction with usage within flexfield segments. You can specify that data security be applied to the values in flexfield segments that use a value set. Based on the roles provisioned to users, data security policies determine which values of the flexfield segment users can view or modify.

The application of value set security has the following conditions:

  • At the value set level: The value set is the resource secured by data security policies. If a value set is secured, every usage of it in any flexfield is secured. Disabling security for individual usages of the same value set isn't possible.

  • Applies to independent, dependent, or table-validated value sets.

  • Applies mainly when data is being created or updated, and to key flexfield combinations tables for query purposes. Value set security doesn't determine which descriptive flexfield data is shown upon querying.

  • Security conditions defined on value sets always use table aliases. When filters are used, table aliases are always used by default. When predicates are defined for data security conditions, make sure that the predicates also use table aliases.

For key flexfields, the attributes in the view object corresponding to the account combination ID, structure instance number (SIN), and data set number (DSN) can't be transient. They must exist in the database table. For key flexfields, the SIN segment is the discriminator attribute, and the account combination segment is the common attribute.

Precision and Scale

If the data type of a value set is Number, you can specify the precision (maximum number of digits user can enter) or scale (maximum number of digits following the decimal point).

Usage and Deployment

The usage of a value set is the flexfields where that value set is used. The deployment status of flexfields in which the value set is used indicates the deployment status of the value set instance.

The following figure shows a value set used by a segment in a key flexfield and the context segment of a descriptive flexfield.

The figure shows a value set shared by both a key
flexfield and a descriptive flexfield.

For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to that segment.

Global and context-sensitive segment require a value set. You can assign a value set to a descriptive flexfield context segment. If you specify only context values, not value sets for contexts, the set of valid values is equal to the set of context values.

Protected Value Set Data

Application developers may mark some value sets as protected, indicating that you can't edit them.

You can edit only value sets that are not marked as protected. You can't edit or delete protected value sets. If the value set type supports values (such as independent, dependent or subset value sets), then you can't add, edit, or delete values.

Note: References to protected value sets aren't restricted. Value sets, protected or not, may be assigned to any flexfield segment. Likewise, other value sets may reference protected value sets; for example, an unprotected dependent value set may reference a protected independent value set.

Validation and usage of value sets determine where and how users access valid values for attributes represented by flexfield segments.

Tip: As a flexfield guideline, define value sets before configuring the flexfield, because you can assign value sets to each segment as you configure a flexfield. With descriptive and extensible flexfield segments, you can create value sets when adding or editing a segment on the run time page where the flexfield appears.

The following aspects are important in defining value sets:

  • Value sets for context segments

  • Format-only validation

  • Interdependent value sets

  • Table validation

  • Range

  • Security

  • Testing and maintenance

Value Sets for Context Segments

When assigning a value set to a context segment, you can only use table-validated or independent value sets.

You can use only table and independent value sets to validate context values. The data type must be character and the maximum length of the values being stored must not be larger than the context's column length. If you use a table value set, the value set cannot reference flexfield segments in the value set's WHERE clause other than the flexfield segment to which the value set is assigned.

Format Only Validation

The format only validation type enables users to enter any value, as long as it meets your specified formatting rules. 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 permits only numeric characters, users can enter the value 456 (for a value set with maximum length of three or more), but can't enter the value ABC. A format only value set doesn't otherwise restrict the range of different values that users can enter. For numeric values, you can also specify if a numeric value should be zero filled or how may digits should follow the radix separator.

Interdependent Value Sets

Use an independent value set to validate data against a list that isn't stored in an application table, and not dependent on a subset of another independent value set. You cannot specify a dependent value set for a given segment without having first defined an independent value set that you apply to another segment in the same flexfield. Use a dependent value set to limit the list of values for a given segment based on the value that the user has defined for a related independent segment. The available values in a dependent list and the meaning of a given value depend on which value was selected for the independently validated segment.

For example, you could define an independent value set of the states in the USA with values such as CA, NY, and so on. Then you define a dependent value set of cities in the USA with values such as San Francisco and Los Angeles that are valid for the independent value CA. Similarly, New York City and Albany are valid for the independent value NY. In the UI, only the valid cities can be selected for a given state.

Because you define a subset value set from an existing independent value set, you must define the independent value set first. Users don't have to select a value for another segment first to have access to the subset value set.

Independent, dependent, and subset value sets require a user-defined list of valid values. Use the Manage Values page to create and manage a value set's valid values and the order in which they appear.

Tip: You can configure the Manage Value Sets page to capture additional attributes for each valid value by adding context-sensitive segments in a new context for FND_VS_VALUES_B descriptive field.
Table Validation

Typically, you use a table-validated set when the values you want to use are already maintained in an application table, such as a table of supplier names. Specify the table column that contains the valid value. You can optionally specify the description and ID columns, a WHERE clause to limit the values to use for your set, and an ORDER BY clause.

If you specify an ID column, then the flexfield saves the ID value, instead of the value from the value column, in the associated flexfield segment. If the underlying table supports translations, you can enable the display of translated text by basing the value set's value column on a translated attribute of the underlying table. You should also define an ID column that is based on an attribute that isn't language-dependent so that the value's invariant ID (an ID that doesn't change) is saved in the transaction table. The run time displays the corresponding translated text from the value column for the run time session's locale.

Table validation lets you enable a segment to depend upon multiple prior segments in the same context structure. You cannot reference other flexfield segments in the table-validated value set's WHERE clause. That is, the WHERE clause cannot reference SEGMENT.segment_code or VALUESET.value_set_code.

Table-validated value sets have unique values across the table, irrespective of bind variables. The WHERE clause fragment of the value set is considered if it doesn't have bind variables. If it has bind variables, the assumption is that the values are unique in the value set. If you use table validated value sets for key flexfields, then you can't use all integration options supported for key flexfields, such as:

  • Data security

  • Oracle Transactional Business Intelligence (OTBI)

  • Extended Spread Sheet Database (ESSbase)

  • Tree or hierarchy integration

To use these integration options for key flexfields, you must use independent value sets only.

Range

In the case of format, independent, or dependent value sets, you can specify a range to limit which values are valid. You can specify a range of values that are valid within a value set. You can also specify a range validated pair of segments where one segment represents the low end of the range and another segment represents the high end of the range.

For example, you might specify a range for a format-only value set with format type Number where the user can enter only values between 0 and 100.

Security

In the case of independent and dependent values, you can specify that data security be applied to the values in segments that use a value set. Based on the roles provisioned to users, data security policies determine which values of the flexfield segment users can view or modify.

To enable security on a value set, specify a database resource, typically the code value for the value set. Using the Manage Database Security Policies task, specify conditions, such as filters or SQL predicates, and policies that associate roles with conditions. You can use a filter for simple conditions. For more complex conditions, use a SQL predicate.

Value set data security policies and conditions differ from data security conditions and policies for business objects in the following ways:

  • You can grant only read access to users. You cannot specify any other action.

  • When defining a condition that is based on a SQL predicate, use VALUE, VALUE_NUMBER, VALUE_DATE, VALUE_TIMESTAMP, or VALUE_ID to reference the value from a dependent, independent, or subset value set. For table value sets, use a table alias to define the table, such as &TABLE_ALIAS category=70.

When you enable security on table-validated value sets, the security rule that is defined is absolute and not contingent upon the bind variables (if any) that may be used by the WHERE clause of the value set. For example, suppose a table-validated value set has a bind variable to further filter the value list to x, y and z from a list of x, y, z, xx, yy, zz. The data security rule or filter written against the value set must not assume anything about the bind variables. Instead the whole list of values must be available and you write the rule, for example, to permit x, or to permit y and z. By default in data security, all values are denied and show only rows to which access has been provided.

Testing and Maintenance

You don't have to define or maintain values for a table-validated value set, as the values are managed as part of the referenced table or independent value set, respectively.

You cannot manage value sets in a sandbox.

When you change an existing value set, the deployment status for all affected flexfields changes to Edited. You must redeploy all flexfields that use that value set to make the flexfields reflect the changes. In the UI pages for managing value sets, the value set's usages show which flexfields are affected by the value set changes.

If your application has more than one language installed, or there is any possibility that you might install one or more additional languages for your application in the future, select Translatable. This doesn't require you to provide translated values now, but you cannot change this option if you decide to provide them later.

Considerations for Planning Value Sets

The value sets you create and configure depend on the valid values on the business object attributes that will use the value set. When creating value sets, you first give the value set a name and description, and then define the valid values of the set.

The following aspects are important in planning value sets:

  • List of values

  • Plain text

  • Value ranges

  • Value format specification

  • Security

List of Values

You can use one of the following types of lists to specify the valid values for a segment:

  • Table column

  • User-defined list. Also include a sub list.

  • Dependent user-defined list

If the valid values exist in a table column, use a table value set to specify the list of values. To limit the valid values to a subset of the values in the table, use a SQL WHERE clause. Table value sets also provide some advanced features, such as enabling validation depending on other segments in the same structure.

Use an independent value set to specify a user-defined set of valid values. For example, you can use an independent value set of Mon, Tue, Wed, and so forth to validate the day of the week. You can also specify a subset of an existing independent value set as the valid values for a segment. For example, if you have an independent value set for the days of the week, then a weekend subset can comprise entries for Saturday and Sunday.

Use a dependent value set when the available values in the list and the meaning of a given value depend on which independent value was selected for a previously selected segment value. For example, the valid holidays depend on which country you are in. A dependent value set is a collection of value subsets, with one subset for each value in a corresponding independent value set.

For lists of values type value sets, you can additionally limit the valid values that an end user can select or enter by specifying format, minimum value, and maximum value. For list of values type value sets, you can optionally implement value set data security. If the applications are running in different locales, you might need to provide different translations for the values and descriptions.

Plain Text

Use a format-only value set when you want to allow users to enter any value, as long as that value conforms to formatting rules. For example, if you specify a maximum length of 3 and numeric-only, then end users can enter 456, but not 4567 or 45A. You can also specify the minimum and maximum values, whether to align the text to either side, and whether to zero-fill. With a format-only value set, no other types of validation are applied.

Value Ranges

You can use either a format-only, independent, or dependent value set to specify a range of values. For example, you might create a format-only value set with Number as the format type where the end user can enter only the values between 0 and 100. Or, you might create a format-only value set with Date as the format type where the end user can enter only dates for a specific year, such as a range of 01-JAN-93 to 31-DEC-93. Because the minimum and maximum values enforce these limits, you need not define a value set that contains each of these individual numbers or dates.

Value Format

Flexfield segments commonly require some kind of format specification, regardless of validation type. Before creating a value set, consider how you will specify the required format.

The following table shows options for validation type and value data type.

Option Description

Value data type

Character, Number, Date, Date Time.

Value subtype

Text, Translated text, Numeric digits only, Time (20:08), Time (20:08:08).

An additional data type specification for the Character data type for the Dependent, Independent, and Format validation types.

Maximum length

Maximum number of characters or digits for Character data type.

Precision

Maximum number of digits the user can enter.

Scale

Maximum number of digits that can follow the decimal point.

Uppercase only

Lowercase characters automatically changed to uppercase.

Zero fill

Automatic text alignment and zero-filling of entered numbers (affects values that include only the digits 0-9).

Note: You cannot change the text value data type to a translated text value subtype after creating a value set. If there is any chance you may need to translate displayed values into other languages, choose Translated text. Selecting the Translated text subtype doesn't require you to provide translated values.
Value Sets for Context Segments

You can use only table and independent value sets to validate context values. The data type must be character and the maximum length of the values being stored must not be larger than the context's column length. If you use a table value set, the value set cannot reference flexfield segments in the value set's WHERE clause other than the flexfield segment to which the value set is assigned.

Security

When enabling security on a value set, the data security resource name is an existing value set or one that you want to create. The name typically matches the code value for the value set. You cannot edit the data security resource name after you save your changes.

Considerations for Bind Variables in Table-Validated Value Sets

After you assign a value set to a flexfield, you can use bind variables in the WHERE clause.

The following bind variables refer to flexfield elements:

  • :{SEGMENT.<segment_code>}

  • :{CONTEXT.<context_code>;SEGMENT.<segment_code>}

  • :{VALUESET.<value_set_code>}

  • :{FLEXFIELD.<internal_code>}

  • :{PARAMETER.<parameter_code>}

Segment Code

:{SEGMENT.<segment_code>}

This bind variable refers to the ID or value of a segment where <segment_code> identifies the segment. Where referring to the ID, the value set is ID-validated. Where referring to the value, the value set isn't ID-validated. The data type of the bind value is the same as the data type of the segment's column.

For both descriptive and extensible flexfields, the segment must be in the same context as the source segment. The source segment contains the WHERE clause. For descriptive flexfields, if the segment is global, then the source segment must be global.

The segment must have a sequence number that is less than the sequence number of the target segment with this bind variable. A matching segment must exist in the current flexfield context.

This bind variable is useful when the set of valid values depends on the value in another segment. For example, the values to select from a CITIES table might depend upon the selected country. If SEGMENT1 contains the country value, then the WHERE clause for the CITIES table might be <country_code> = :{SEGMENT.SEGMENT1}.

Context Code

:{CONTEXT.<context_code>;SEGMENT.<segment_code>}

This bind variable, which is valid only for extensible flexfields, refers to the ID (if the value set is ID-validated) or value (if not ID-validated) of a segment that is in a different context than the target segment (the segment with the WHERE clause).

  • The <context_code> identifies the context and must be in the same category or in an ancestor category. It cannot be a multiple-row context.

  • The <segment_code> identifies the segment. The data type of the bind value is the same as the data type of the segment's column.

Note: The target segment should appear in the UI after the source segment to ensure the source segment has a value. If the target segment's context is a single-row context, the source and target segments must be on separate pages and the target page must follow the source page.

The framework of extensible flexfields doesn't perform any additional validation related to mismatched values for segments defined with cross context bind parameters. Administrators must populate the correct pair of segment values.

This bind variable is useful when the set of valid values depends on the value of a segment in another context. For example, the values to select from a CERTIFICATION table for a segment in the Compliance and Certification context might depend on the value of the country segment in the Manufacturing context.

Value Set Code

:{VALUESET.<value_set_code>}

This bind variable refers to the ID (if the value set is ID-validated) or value (if not ID-validated) of the segment that is assigned to the value set that is identified by the value_set_code. The data type of the bind value is the same as the data type of the segment's column.

The segment must have a sequence number that is less than the sequence number of the segment with this bind variable. If more than one segment is assigned to the value set, the closest prior matching segment will be used to resolve the bind expression. A matching segment must exist in the current flexfield context.

This bind variable is useful when the set of valid values depends on the value in another segment and that segment code can vary, such as when the value set is used for more than one context or flexfield. For example, the values to select from a CITIES table might depend upon the selected country. If the value set for the segment that contains the country value is COUNTRIES, then the WHERE clause for the CITIES table might be <country_code> = :{VALUESET.COUNTRIES}.

Flexfield Internal Code

:{FLEXFIELD.<internal_code>}

This bind variable refers to an internal code of the flexfield in which the value set is used, or to a validation date. The internal_code must be one of the following:

  • APPLICATION_ID - the application ID of the flexfield in which this value set is used. The data type of APPLICATION_ID and its resulting bind value is NUMBER.

  • DESCRIPTIVE_FLEXFIELD_CODE - the identifying code of the flexfield in which this value set is used. The data type of DESCRIPTIVE_FLEXFIELD_CODE and its resulting bind value is VARCHAR2. Note that you use this string for both descriptive and extensible flexfields.

  • CONTEXT_CODE - the context code of the flexfield context in which this value set is used. The data type of CONTEXT_CODE and its resulting bind value is VARCHAR2.

  • SEGMENT_CODE - the identifying code of the flexfield segment in which this value set is used. The data type of SEGMENT_CODE and its resulting bind value is VARCHAR2.

  • VALIDATION_DATE - the current database date. The data type of VALIDATION_DATE and its resulting bind value is DATE.

Flexfield Parameters

:{PARAMETER.<parameter_code>}

This bind variable refers to the value of a flexfield parameter where parameter_code identifies the parameter. The data type of the resulting bind value is the same as the parameter's data type.

Note: You cannot assign a table value set to a context segment if the WHERE clause uses VALUESET.value_set_code or SEGMENT.segment_code bind variables.

Create Table-Validated Value Sets Based on Lookups

In an application user interface, you want to display a list of values that customers use to enter satisfaction scores. The value column name is 1, 2, 3, 4, 5 and the value column description is Extremely Satisfied, Satisfied, and so on. Users can select the appropriate value or description which stores the corresponding name so the name value can be used in a calculation expression.

In this case, you can use the FND_LOOKUPS table as the basis for a table-validated value set. The lookup meaning corresponds to the Value Column Name and the lookup description corresponds to the Description Column Name. The following table lists the properties of the value set.

Property Value

FROM clause

FND_LOOKUPS

WHERE clause

lookup_type = 'CN_XX_CUST_SATISFACT_SCORE'

ID column

lookup_code

Value column

meaning

Description column

description

Enable column

enabled_flag

Start Date column

start_date_active

End Date column

end_date_active

Order by

display_sequence

After completing this task, you should have created your customer satisfaction value set for the Incentive Compensation page of your implementation project.

Creating a Value Set Based on a Lookup
  1. From the Setup and Maintenance work area, find the Manage Value Sets task and click the Go to Task icon button.

  2. On the Manage Value Sets page, click the Create icon button.

  3. On the Create Value Set page, enter the following values:

    1. In the Value Set Code field, enter CN_XX_CUSTOMER_SATISFACTION_SCORES

    2. In the Description field, enter Customer satisfaction score.

    3. In the Module field, select Search

    4. In the Search and Select: Module subwindow, enter Incent in the User Module Name field

    5. Select Incentive Compensation.

    6. Click OK.

  4. On the Create Value Set page, enter the following values:

    1. In the Validation Type field, select Table.

    2. In the Value Data Type field, select Character.

    3. In the Definition section FROM Clause field, enter FND_LOOKUPS.

    4. In the Value Column Name field, enter DESCRIPTION.

    5. In the Description Column Name field, enter MEANING.

    6. In the ID Column Name field, enter LOOKUP_CODE.

    7. In the Enabled Column Name field, enter 'Y'.

    8. In the Start Date Column Name field, enter START_DATE_ACTIVE.

    9. In the End Date Column Name field, enter END_DATE_ACTIVE.

    10. In the WHERE Clause field, enter LOOKUP_TYPE = 'CN_XX_CUST_SATISFACT_SCORE'.

  5. Click Save and Close.

  6. In the Manage Value Sets page, click Done.

You can add attributes to independent, dependent, and subset value sets. The attributes appear on the Manage Value Sets page where you can store additional information about each valid value. To display attributes on an application page, you must programmatically modify the application.

To add attributes and subsequently view them on the Manage Value Sets page, perform the following steps:

  1. Using the Manage Descriptive Flexfields task, find the FND_VS_VALUES_B flexfield and open it for editing.

  2. Click Manage Contexts.

  3. Create a new context and use the value set code for the context code.

  4. Add new attributes as context-sensitive segments and save the changes.

  5. Deploy FND_VS_VALUES_B to run time.

  6. Sign out and sign back in.

  7. Open the Manage Value Sets page to view the new attributes.

Import Value Set Values

You can import a file containing values that you want to edit or add to a given independent or dependent value set.

For example, uploading a hundred values may be more efficient than creating them individually using the Manage Value Sets task. However, for just a few values, it may be quicker to perform the relevant tasks.

Importing Value Set Values

To import value set values:

  1. Create a flat file containing the values in the value set that you want to add or update.

    Note:
    • When creating the file, you must specify an existing value set code to which you want to add values or edit existing values. If the value set does not exist, add the value set using the appropriate Manage Value Sets setup task in the Setup and Maintenance work area.

    • The file that you create must adhere to the formatting and content requirements for creating flat files containing value set values.

  2. Upload the flat file to the content repository using the File Import and Export page.

  3. Import the file using the appropriate Manage Value Sets setup task in the Setup and Maintenance work area. To import the file:

    1. Click Actions > Import in the Manage Value Sets page.

    2. In the File Name field, enter the name of the flat file you uploaded using the File Import and Export page.

    3. In the Account field, select the user account containing the flat file.

    4. Click Upload.

    Note: Alternatively, you can import the file using either of the following methods:
    • Run the Upload Value Set Values scheduled process.

    • Use the Applications Core Metadata Import web service. For more information on the Applications Core Metadata Import web service, see the SOAP Web Services guide for your cloud services.

Import Value Set Values Using Web Services

As an alternative to using the import option on the Manage Value Sets page, you can use the FndManageImportExportFilesService web service to import value set values into an application. The web service uses the valueSetValuesDataLoader method.

Prerequisite

Ensure that the web service FndManageImportExportFilesService is added to the Manage Application Flexfield Value Set entitlement. Use the Security Console to perform this configuration on Oracle Entitlements Server. While configuring the web service, provide the following details:

  • Resource type: WebserviceResourceType

  • Display name: ImportExport

  • Name: http://xmlns.oracle.com/oracle/apps/fnd/applcore/webservices/FndManageImportExportFilesService#*

  • Entitlement (In Default Policy Domain): Manage Application Flexfield Value Set

  • Security policy: oracle/wss11_saml_or_username_token_with_message_protection_service_policy

Importing Value Set Values

To import value set values:

  1. Perform the following substeps to generate keystore for the security policy "oracle/wss11_saml_or_username_token_with_message_protection_service_policy":

    1. Generate keystore using the command keytool -genkeypair -keyalg RSA -alias mycompkey -keypass <password> -keystore mycompclient-keystore.jks -storepass <password> -validity 3600.

    2. Access the WSDL using the URL http://<host>:<port>/fndAppCoreServices/FndManageImportExportFilesService?wsdl through a web browser, and get the public key <wsdl:service>/<wsdl:port>/<wsa:EndpointReference>/<wsid:Identity>/<dsig:keyInfo>/<dsig:X509Data>/<dsig:X509Certificate>. Then, enclose it with ---- BEGIN CERTIFICATE ---- and ---- END CERTIFICATE ---- and save it to a file by name cdrmpk.cer.

    3. Store the key information in the truststore using the command keytool -importcert -alias cdrmkey -file cdrmpk.cer -keystore mycompclient-keystore.jks -storepass <password>.

  2. Access the WSDL page using the browser of your choice.

  3. Export and save the associated security certificates Verisign Class 3 Public Primary Certification Authority - G5 and Verisign Secure Server CA - G3.

  4. Use the following command to import the saved certificates into the trust store of the client computer.

    keytool -importcert -keystore <truststore> -storepass <truststorepassword> -file <file location where the mentioned certificate is stored> -alias <alias for certificate>
  5. Run the following command to generate the JAX-WS proxy for the FndManageImportExportFilesService web service.

    C:\Program Files\Java\jdk1.7.0_04\bin>wsimport
               -s "d:\wsimport\FndManageImportExport"
               -d "d:\wsimport\FndManageImportExport" http://<host>:<port>/fndAppCoreServices/FndManageImportExportFilesService?wsdl
    
       parsing WSDL... 
    
       Generating code... 
    
       Compiling code...
  6. Save the generated code as a JAR file and name it FndManageImportExportProxy.jar.

  7. Use the following code to create another JAR file to initiate the web service:

    package com.oracle.xmlns.oracle.apps.fnd.applcore.webservices;
     
    import com.sun.xml.ws.developer.WSBindingProvider;
     
    import java.io.File;
    import java.io.IOException;
     
    import java.util.List;
     
    import java.util.Map;
     
    import javax.xml.ws.BindingProvider;
    import javax.xml.ws.WebServiceRef;
     
    import javax.xml.ws.handler.Handler;
     
    import oracle.webservices.ClientConstants;
     
    import weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature;
    // !THE CHANGES MADE TO THIS FILE WILL BE DESTROYED IF REGENERATED!
    // This source file is generated by Oracle tools
    // Contents may be subject to change
    // For reporting problems, use the following
    // Version = Oracle WebServices (11.1.1.0.0, build 130224.1947.04102)
     
    public class FndManageImportExportFilesServiceSoapHttpPortClient
    {
      @WebServiceRef
      private static FndManageImportExportFilesService_Service fndManageImportExportFilesService_Service;
     
      public static void main(String [] args)
      {
           System.setProperty("javax.net.ssl.trustStore","<location of truststore which is used in II) to import the certificates>");
           System.setProperty("javax.net.ssl.trustStorePassword", "<truststore password>");
     
        fndManageImportExportFilesService_Service = new FndManageImportExportFilesService_Service();
            SecurityPoliciesFeature securityFeatures =
                new SecurityPoliciesFeature(new String[] { "oracle/wss11_username_token_with_message_protection_client_policy",
                                                           });
            FndManageImportExportFilesService
     fndManageImportExportFilesService =  
    fndManageImportExportFilesService_Service.getFndManageImportExportFilesServiceSoapHttpPort
     (securityFeatures);
            // Add your code to call the desired methods.
     
     
            WSBindingProvider wsbp = (WSBindingProvider) fndManageImportExportFilesService;
               Map<String, Object> requestContext = wsbp.getRequestContext();
     
     
            requestContext.put(ClientConstants.WSSEC_KEYSTORE_TYPE,"jks");
            // Provide location of 'mycompclient-keystore.jks' which was created during Step I)
            requestContext.put(ClientConstants.WSSEC_KEYSTORE_LOCATION,"/home/user1/mycompclient-keystore.jks");
            requestContext.put(ClientConstants.WSSEC_KEYSTORE_PASSWORD,"<password>");
            requestContext.put(ClientConstants.WSSEC_RECIPIENT_KEY_ALIAS,"cdrmkey");
     
            //Provide user who is having permission to initiate the service
            requestContext.put(WSBindingProvider.USERNAME_PROPERTY,"<username>");
            requestContext.put(WSBindingProvider.PASSWORD_PROPERTY, "<password>");
     
     
            String id =          invokeUploadFiletoUCMMethod(fndManageImportExportFilesService);
     
            if (id != null) {
                invokevalueSetValuesDataLoader(fndManageImportExportFilesService,  new Long(id));
     
            }
      }
     
        static String invokeUploadFiletoUCMMethod(FndManageImportExportFilesService fndManageImportExportFilesService) {
     
            String response = null;
            DocumentDetails document = new DocumentDetails();
            ObjectFactory objfactory = new ObjectFactory();
            document.setFileName(objfactory.createDocumentDetailsFileName("import_data.txt"));
            // Provide UCM repository - if repository is fin/tax/import then suffix each value with $ as mentioned here
            document.setDocumentAccount(objfactory.createDocumentDetailsDocumentAccount("fin$/tax$/import$"));
            document.setDocumentTitle(objfactory.createDocumentDetailsDocumentTitle("VS"));
            document.setContentType(objfactory.createDocumentDetailsContentType("plain/text"));
     
            try {
     
                // Provide location of 'VS.txt' which contains ValueSet values data in prescribed format
                byte[] content =
                org.apache.commons.io.FileUtils.readFileToByteArray(new File("/home/user1/VS.txt"));
     
                //System.out.println("File content:" + new String(content, "UTF-8"));
                document.setContent(objfactory.createDocumentDetailsContent(content));
     
            } catch (IOException e) {
                System.out.println(e.getMessage());
            }
            catch(Exception e) {
                System.out.println("Exception: "+e.getMessage());
            }
     
            try {
                response = fndManageImportExportFilesService.uploadFiletoUCM(document);
                System.out.println("Response: " + response);
     
            } catch (ServiceException e) {
                System.out.println(e.getMessage());
            }
     
            return response;
        }
     
        static void invokevalueSetValuesDataLoader(FndManageImportExportFilesService fndManageImportExportFilesService,
                                                   Long id) {
            String response;
            try {
                response = fndManageImportExportFilesService.valueSetValuesDataLoader(id);
                System.out.println("Response: " + response);
            } catch (ServiceException e) {
                System.out.println(e.getMessage());
            }
        }
    }
    
  8. Save the generated output as a JAVA file and name it FndManageImportExportFilesServiceSoapHttpPortClient.java.

  9. Use the JAVA file to build a JAR file, and name it FndManageImportExportClient.jar.

  10. Use the following command to run the web service:

    java -cp ./FndManageImportExportProxy.jar:./ws.api_1.1.0.0.jar:./FndManageImportExportClient.jar FndManageImportExportFilesServiceSoapHttpPortClient

Requirements for Flat Files to Upload Value Set Values

You can import large volumes of value set value data from the content repository. To upload value set values to the content repository, create a flat file containing the values in the value set that you want to add or update. You upload these flat files to the content repository using the File Import and Export page.

General Requirements

The first line of the flat file must contain the column names for the value set value data, including all mandatory columns, and separated by the '|' (pipe) character. Each subsequent line should contain a row of data specified in the same order as the column names, also separated by the '|' character.

The requirements for creating flat files vary with the type of value sets:

  • Independent value sets

  • Dependent value sets

Independent Value Set

A flat file for uploading values for independent value sets must contain the mandatory columns. The following table lists the three mandatory columns and their data types.

Column Name Data Type

ValueSetCode

VARCHAR2(60)

Value

VARCHAR2(150)

Enabled Flag

VARCHAR2(1), Y or N

Note: You can also specify optional columns.

Examples:

  • To upload values to a COLORS independent value set with the minimum columns, you can use the following flat file:

    ValueSetCode | Value | EnabledFlag
    COLORS | Red | Y
    COLORS | Orange | Y
    COLORS | Yellow | Y
  • To upload values to a STATES independent value set with more (optional) columns, you can use the following flat file:

    ValueSetCode | Value | Description | EnabledFlag
    STATES | AK | Alaska | Y
    STATES | CA | California | Y
    STATES | WA | Washington | Y
Dependent Value Sets

A flat file for uploading values for dependent value sets must contain the mandatory columns. The following table lists the four mandatory columns and their data types.

Column Name Data Type

Value Set Code

VARCHAR2(60)

Independent Value

VARCHAR2(150)

Value

VARCHAR2(150)

Enabled Flag

VARCHAR2(1), Y or N

Note: You can also specify optional columns.

Example:

To upload values to a CITIES dependent value set (dependent on the STATES independent value set), you can use the following flat file:

ValueSetCode | IndependentValue | Value | EnabledFlag
CITIES | AK | Juneau | Y
CITIES | AK | Anchorage | Y
CITIES | CA | San Francisco | Y
CITIES | CA | Sacramento | Y
CITIES | CA | Los Angeles | Y
CITIES | CA | Oakland | Y
Additional Optional Columns

In addition to the mandatory columns, you can add optional columns. The following table lists the optional columns for both dependent and independent value sets.

Column Name Type

Translated Value

VARCHAR2(150), for use in value sets that are translatable

Description

VARCHAR2(240)

Start Date Active

DATE, formatted as YYYY-MM-DD

End Date Active

DATE, formatted as YYYY-MM-DD

Sort Order

NUMBER(18)

Summary Flag

VARCHAR2(30)

Flex Value Attribute1 ... Flex Value Attribute20

VARCHAR2(30)

User-defined Value Attribute1 ... User-defined Value Attribute10

VARCHAR2(30)

Upload Value Set Values Process

This process uploads a flat file containing value set values for flexfields. You can use the scheduled process to upload a file containing values you want to edit or add to an existing independent or dependent value set. This process is useful for adding or updating large volumes of value set value data in an automated or recurring fashion. For example, you can upload a hundred values on a recurring basis when scheduled as a recurring process. This method could be more efficient than using the Import action in the Manage Value Sets tasks in the Setup and Maintenance work area. However, for a task of uploading a hundred values, it may be quicker to use the Import action in the relevant tasks.

Run this process from the Scheduled Processes Overview page. You can run it on a recurring basis whenever the flat file in the content repository account is updated.

You must create the flat file containing the values data, and upload the flat file to the content repository using the File Import and Export page.

Parameters
Flat File Name

Enter the name of the flat file you uploaded using the File Import and Export page.

Account

Select the user account containing the flat file in the content repository to upload.

Translation of Flexfield and Value Set Configurations

When you first configure a flexfield or segment, the translatable text that you enter, such as prompts and descriptions, is stored as the text for all installed locales. You may then provide a translation for a particular locale. If you don't provide a translation for a given locale, then the value that was first entered is used for that locale.

To translate the text for a particular locale, sign in with that locale, or in the global header, select Settings and Actions > Personalization > Set Preferences and specify the locale. Then, update the translatable text in the flexfield using the Manage Descriptive Flexfields task, Manage Key Flexfields task, or Manage Extensible Flexfields task. Your modifications change the translated values only for the current session's locale.

After you complete the translations, deploy the flexfield.

You can define translations for a dependent value set or an independent value set, if the value set is of type Character with a subtype Translated text. You define the translations by setting the current session to the locale for which you want to define the translation. Then use the Manage Value Sets task to enter the translated values and descriptions for that locale.

You can define translated values for a table value set for which multiple languages are supported and that the value set's value column is based on a translated attribute of the underlying table. For more information about using multilanguage support features, see the Oracle Fusion Applications Developer's Guide.

FAQs for Value Sets

Value set security is a feature that enables you to secure access to value set values based on the role of the user in the application.

As an example, suppose you have a value set of US state names. When this value set is used to validate a flexfield segment, and users can select a value for the segment, you can use value set security to restrict them to selecting only a certain state or subset of states based on their assigned roles in the application.

For example, Western-region employees may choose only California, Nevada, Oregon, and so on as valid values. They cannot select non-Western-region states. Eastern-region employees may choose only New York, New Jersey, Virginia, and so on as valid values, but cannot select non-Eastern-region states. Value set security is implemented using Oracle Applications Cloud data security.

When you define or edit a flexfield segment, you pick a value from the assigned value set and set it as default.

You can set the default value for a descriptive flexfield segment to be a parameter. The mapped entity object attribute provides the initial default value for the segment.

You can set the default value to be a constant, if appropriate to the data type of the value set assigned to the segment.

In addition to an initial default value, you can set a derivation value for updating the attribute's value every time the parameter value changes. The parameter you select identifies the entity object source attribute. Any changes in the value of the source attribute during run time are reflected in the value of the segment.

If the display type of the segment is a check box, you can set whether the default value of the segment is checked or unchecked.

Descriptive Flexfields

Use descriptive flexfields to add attributes to business object entities, and define validation for them.

All the business object entities that you can use in the application are enabled for descriptive flexfields. However, configuring descriptive flexfields is an optional task.

Context

A descriptive flexfield can have only one context segment to provide context sensitivity. The same underlying database column can be used by different segments in different contexts.

For example, you can define a Dimensions context that uses the following attributes:

  • ATTRIBUTE1 column for height

  • ATTRIBUTE2 column for width

  • ATTRIBUTE3 column for depth

You can also define a Measurements context that uses the same columns for other attributes:

  • ATTRIBUTE1 column for weight

  • ATTRIBUTE2 column for volume

  • ATTRIBUTE3 column for density

Segments and Contexts

The following table lists the different types of descriptive flexfield segments.

Segment Type Run Time Appearance

Global segment

Always available

Context segment

Determines which context-sensitive segments are displayed

Context-sensitive segment

Displayed depending on the value of the context segment

The following figure displays a descriptive flexfield having one context segment called Category for which there are three values: Resistor, Battery, and Capacitor. Additionally, the descriptive flexfield comprises two global segments that appear in each context, and three context-sensitive segments that only appear in the specific context.

The figure contains an example of how context segment
serves as a category for the attributes, whether resistor, battery,
or capacitor. Global segments are always available. However, context-sensitive
segments are available depending on the context.

Application development determines the number of segments available for configuring. During implementation, configure the flexfield by determining the following:

  • Attributes to add using the available segments

  • Context values

  • The combination of attributes in each context

Value Sets

For each global and context-sensitive segment, you configure the values permitted for the segment. Based on it, the values that end users enter are validated, including interdependent validation among the segments.

Protected Descriptive Flexfield Data

Application developers may mark some data configurations in a descriptive flexfield as protected, indicating that you can't edit them.

Considerations for Planning Descriptive Flexfields

Once you have identified a flexfield to configure, plan the configuration in advance. Compile a list of the UI pages and other artifacts in your deployment that are affected by the configuration. Verify that you are provisioned with the roles needed to view and configure the flexfield. View the flexfield using the Highlight Flexfields command in the Administration menu while viewing the run time page where the flexfield appears. Plan how you will deploy the flexfield for test and production users. Review the tools and tasks available for managing flexfields for adding and editing flexfield segments.

Planning a descriptive flexfield can involve the following tasks:

  1. Identify existing parameters.

  2. Identify existing context values and whether the context value is derived.

  3. Identify user-defined attributes and plan the descriptive flexfield segments, segment properties, and structure.

  4. Plan validation rules.

  5. Plan initial values.

  6. Plan attribute mapping to Oracle Business Intelligence objects.

Identify Existing Descriptive Flexfield Parameters

Some descriptive flexfields provide parameters that can be used to specify the initial value of a descriptive flexfield segment. The parameter is external reference data, such as a column value or a session variable. For example, if a flexfield has a user email parameter, you can configure the initial value for a customer email attribute to be derived from that parameter.

Review the list of available parameters in the Derivation Value field in the Create Segment page for a descriptive flexfield. If you decide to use one of the parameters to set an initial value, select that parameter from the Derivation Value drop-down list when you add the descriptive flexfield segment.

Evaluate Whether the Context Value Is Derived

The context value for a descriptive flexfield might have been preconfigured to be derived from an external reference. For example, if the context is Marriage Status, then the value might be derived from an attribute in the employee business object. When the context value is derived, you might need to take the derived values and their source into consideration in your plan.

To determine whether the context value is derived, access the Edit Descriptive Flexfield task to view the list of configured context values for the flexfield. The Derivation Value field in the Context Segment region displays a list of available parameters. If context values have been preconfigured, see Oracle Applications Cloud Help for product-specific information about the use of those values.

Plan the Segments, Segment Properties, and Structure

Identify the user-defined attributes you need for a business object to determine the segments of the descriptive flexfield. Determine the segment properties such as the prompt, display type, or initial value.

The structure of the descriptive flexfield is determined by its global, context, and context-sensitive segments. Plan a global segment that captures an attribute for every instance of the business object. Plan a context for segments that depend on a condition of situation applying to a particular instance of the business object. Plan context-sensitive segments to capture attributes that are relevant in the context.

There is only one context segment available for descriptive flexfields. If you have more than one group of user-defined attributes where you could use the context segment, you will have to pick one group over the others, based on your company's needs and priorities, and add the other user-defined attributes as global segments.

Plan Validation Rules

Define each segment's validation rules and check if value sets exist for those rules or you must create new ones. If you must create a value set, you can create it either before configuring the flexfield or while creating or editing a segment.

When determining a segment's validation rules, consider the following questions:

  • What is the data type - character, date, date and time, or number?

  • Does the segment require any validation beyond data type and maximum length?

  • Should a character type value be restricted to digits, or are alphabetic characters allowed?

  • Should alphabetic characters automatically be changed to uppercase?

  • Should numeric values be zero-filled?

  • How many digits can follow the radix separator of a numeric value? In base ten numeric systems, the radix separator is decimal point.

  • Does the value need to fall within a range?

  • Should the value be selected from a list of valid values? If so, consider the following questions:

    • Can you use an existing application table from which to obtain the list of valid values, or do you need to create a list?

    • If you are using an existing table, do you need to limit the list of values using a WHERE clause?

    • Does the list of valid values depend on the value in another flexfield segment?

    • Is the list of valid values a subset of another flexfield segment's list of values?

Plan Initial Values

For every segment, list the constant value or SQL statement, if any, to use for the initial value of the user-defined attribute.

Plan How Segments Map to Oracle Business Intelligence Objects

You can extend descriptive flexfields into Oracle Transactional Business Intelligence (OTBI) for ad hoc reporting purposes. Determine the descriptive flexfield segments to be made available for reporting, and select the BI Enabled check box accordingly on the Manage Descriptive Flexfields page. You must run a process to extend the BI enabled segments into OTBI. For more information about extending the BI enabled segments into OTBI, see the Flexfields chapter in the Oracle Applications Cloud Creating and Administering Analytics and Reports guide.

Depending on the reporting needs, you may map similar context-sensitive attributes from different contexts to the same attribute in OTBI. For example, there may be a segment tracking the Product Color attribute in different contexts of a context sensitive descriptive flexfield. You can use segment labels to map these context-sensitive attributes together by defining a segment label and updating the BI Label list accordingly.

Configuring descriptive flexfields involves managing the available flexfields registered with your Oracle Applications Cloud database and configuring their flexfield-level properties, defining and managing descriptive flexfield contexts, and configuring global and context-sensitive segments.

Every descriptive flexfield is registered to include a context segment, which you may choose to use or not.

In general, configuring descriptive flexfields involves:

  1. Creating segment labels for business intelligence enabled flexfields.

  2. Configuring global segments by providing identity information, the initial default value, and the display properties.

  3. Configuring the context segment by specifying the prompt, whether the context segment should be displayed, and whether a value is required.

  4. Configuring contexts by specifying a context code, description, and name for each context value, and adding its context-sensitive segments, each of which is configured to include identifying information, the column assignment, the initial default value, and the display properties.

The following aspects are important in understanding descriptive flexfield management:

  • Segments

  • Adding segments to highlighted descriptive flexfields

  • Usages

  • Parameters

  • Delimiters

  • Initial Values

  • Business Intelligence

Segments

You can assign sequence order numbers to global segments and to context-sensitive segments in each context. Segment display is always in a fixed order. You cannot enter a number for one segment that is already in use for a different segment.

Value sets are optional for context segments and follow specific guidelines:

  • The value set that you specify for a context segment consists of a set of context codes.

  • Each context code corresponds to a context that is appropriate for the descriptive flexfield.

  • The value set must be independent or table-validated.

  • If table-validated, the WHERE clause must not use the VALUESET.value_set_code or SEGMENT.segment_code bind variables.

  • The value set must be of data type Character with the maximum length of values being stored no larger than the context's column length.

  • If you don't specify a value set for a context segment, the valid values for that context segment are derived from the context codes. The definition of each context segment specifies the set of context-sensitive segments that can be presented when that context code is selected by the end user.

  • For reasons of data integrity, you cannot delete an existing context. Instead, you can disable the associated context value in its own value set by setting its end date to a date in the past.

  • You can configure the individual global segments and context-sensitive segments in a descriptive flexfield. These segment types are differentiated by their usage, but they are configured on application pages that use most of the same properties.

Adding Segments to Highlighted Descriptive Flexfields

When you highlight flexfields on a run time page and use an Add Segment icon button to create a segment, the segment code, name, description, table column, and sequence number are set automatically. If you use an Add Segment icon button to configure descriptive flexfield segments, you cannot use an existing value set. Value sets are created automatically when you add the segments. You can enter the valid values, their descriptions, and the default value or specify the formatting constraints for the value set, such as minimum and maximum values.

Depending on display type, the value set you create using the Add Segment icon button is either an independent value set or a format-only value set. The following table shows which type of value set is created depending on the segment display component you select.

Display Component Value Set Created Using Add Segment

Check Box

Independent

Drop-down List

Independent

List of Values

Independent

Radio Button Group

Independent

Text Field With Search

Independent

Text box

Format Only

Text area

Format Only

Date/Time

Format Only

Tip: After you add a context value, refresh the page to see the new value.
Usages

Descriptive flexfield usages allow for the same definition to be applied to multiple entities or application tables, such as a USER table and a USER_HISTORY table. Descriptive flexfield tables define the placeholder entity where the flexfield segment values are stored once you have configured the descriptive flexfield. When you configure a flexfield, the configuration applies to all its usages.

Parameters

Some descriptive flexfields provide parameters, which are attributes of the same or related entity objects. Parameters are public arguments to a descriptive flexfield. Parameters provide outside values in descriptive flexfield validation. You use parameters to set the initial value or derivation value of an attribute from external reference data, such as a column value or a session variable, rather than from user input. Parameters can be referenced by the logic that derives the default segment value, and by table-validated value set WHERE clauses.

Delimiters

A segment delimiter or separator visually separates segment values when the flexfield is displayed as a string of concatenated segments.

Initial Values

The SQL statement defining an initial value must be a valid statement that returns only one row and a value of the correct type.

You can use two types of SQL statements:

  • SQL statement with no binding. For example, select MIN(SALARY) from EMPLOYEES.

  • SQL statement with bind variables. You can use the following bind variables in the WHERE clause of the SQL statement.

    • :{SEGMENT.<segment_code>}: Identifies a segment in the same context.

    • :{CONTEXT.<context_code>;SEGMENT.<segment_code>}: Identifies a segment in a different context. The context must be in the same category or in an ancestor category, and it cannot be a multiple-row context.

    • :{VALUESET.<value_set_code>}: Identifies the closest prior segment in the same context that is assigned to the specified value set.

    • :{FLEXFIELD.<internal_code>}: Identifies a flexfield.

For more information about using bind variables, see the help for value sets.

Business Intelligence

Selecting a global, context, or context-sensitive segment's BI Enabled check box specifies that the segment is available for use in Oracle Business Intelligence.

When the flexfield is imported into Oracle Business Intelligence, the label you selected from the BI Label drop-down list equalizes the segment with segments in other contexts, and maps the segment to the logical object represented by the label.

A descriptive flexfield that is registered in the database as enabled for Oracle Business Intelligence (BI) includes a BI Enabled setting for each of its segments. When a global, context, or context-sensitive segment is BI-enabled, it is available for use in Oracle Business Intelligence.

The following aspects are important in understanding BI-enabled flexfield segments:

  • Flattening business components to use BI-enabled segments in Oracle BI

  • Equalizing segments to prevent duplication and complexity in the flattened component

  • Mapping attributes of flattened business components to logical objects in Oracle BI

  • Managing the labels that map segments to logical objects in Oracle BI

After you deploy a business intelligence-enabled flexfield, use the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process to import the flexfield changes into the Oracle Business Intelligence repository. Users can make use of the newly-generated attributes in business intelligence applications. For example, a user can generate a report that includes attributes added by the descriptive flexfield. For additional information about logical objects and import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Flattening

When you deploy a business intelligence-enabled descriptive flexfield, the deployment process generates an additional set of flattened Application Development Framework (ADF) business components in addition to the usual ADF business components and ADF faces run time artifacts that are generated during deployment. The flattened business components include attributes for business intelligence-enabled segments only. Flattening means each user-defined column in each context shows up as an attribute in an Oracle Business Intelligence folder.

Flattened components include one attribute for the BI-enabled context-segment, and one attribute for each business intelligence-enabled global segment. For BI-enabled context-sensitive segments, consider the following:

  • If you assigned a label to the segment, the flattened components include an additional single attribute representing segments with that label.

  • If you didn't assign a label, the flattened components include a discrete attribute for each BI-enabled context-sensitive segment in each context.

Mapping to Logical Objects in Business Intelligence

You can simplify reporting by representing similar segments as a single logical object in Business Intelligence.

If you assign a label to any set of context-sensitive segments that serve the same purpose in different contexts, you can consolidate or equalize the segments into a single attribute. This prevents duplication and the extra workload and complexity that result from the flattening process. For example, a United States context might have a Passport segment and a Canada context might have Visa segment. If you assign the NationalID segment label to both the Passport and Visa segments, they are equalized into the same NationalID attribute in the flattened business component.

Non-labeled context-sensitive segments aren't equalized across context values, so the flattened components include a separate attribute for each context-sensitive segment for each context value. It may not be possible to equalize similarly labeled segments if they have incompatible data types or value set types.

Assign a label to a global segment, context segment, or context-sensitive segment to map the corresponding attribute in the flattened components to a logical object in Oracle Business Intelligence. Using labels to map segments to BI logical objects minimizes the steps for importing the flexfield into Oracle Business Intelligence.

Note: Assigning a label to a context-sensitive segment serves to equalize the attribute across contexts, as well as map the equalized attribute to business intelligence.
Managing Labels

You may assign a predefined label (if available) to segments or create new labels for assignment, as needed. Specify a code, name, and description to identify each label. In the BI Object Name field, enter the name of the logical object in Oracle Business Intelligence to which the segment label should map during import. Specifying the BI logical object minimizes the steps for importing the flexfield into Oracle Business Intelligence and helps to equalize context-sensitive segments across contexts.

If no labels are assigned to a BI-enabled segment, or the BI Object Name on the assigned label doesn't exist in business intelligence, you must manually map the segment to the desired logical object when importing into Oracle Business Intelligence.

In addition, context-sensitive segments without labels cannot be equalized across context values. The flattened components include a separate attribute for each non-labeled context-sensitive segment in each context.

Importing to Oracle Business Intelligence Repository

After you deploy a business intelligence-enabled flexfield, import the flexfield changes into the Oracle Business Intelligence repository to make use of the newly flattened business components in business intelligence and then propagate the flexfield object changes. When you import the metadata into the Oracle Business Intelligence repository, you must do so as the FUSION_APPS_BI_APPID user.

To import flexfield changes into the Oracle Business Intelligence repository in Oracle Cloud implementations, run the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process. For additional information about import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Note: When you import a flexfield into the Oracle Business Intelligence repository, you see both <name>_ and <name>_c attributes for each segment, along with some other optional attributes. The <name> attribute contains the value. The <name>_c attribute contains the code of the value set that the value comes from, and is used for linking to the value dimension. You must import both attributes.

Extensible Flexfields

Extensible flexfields are like descriptive flexfields, with some additional features.

  • You can add as many context-sensitive segments to the flexfield as you need. You aren't restricted by the number of columns predefined and registered for the flexfield.

  • You can configure a one-to-many relationship between the entity and its extended attribute rows.

    • A row of data can have multiple contexts associated with it.

    • A row of data can have multiple occurrences of the same context.

  • You can configure attributes in groups to form a context so that the attributes in the context always appear together in the user interface.

  • You can use existing hierarchical categories so that entities inherit the contexts that are configured for their parents. Contexts are reusable throughout categories.

  • Application development has registered some extensible flexfields to support view and edit privileges. For such flexfields, you can specify view and edit privileges at the context level to control who sees the attributes and who can change the attributes' values.

When you configure a context for multiple rows per entity, the segments are displayed as a table.

Unlike descriptive flexfields, the extension columns corresponding to extensible flexfields segments are part of extension tables, separate from the base application table. Unlike descriptive flexfield contexts, the set of attributes in an extensible flexfield context remains constant and doesn't differ by context value. An extensible flexfield describes an application entity, with the run time ability to expand the database that implementation consultants can use to define the data structure that appears in the application. Extensible flexfields support one-to-many relationships between the entity and the extended attribute rows. To get a list of predefined extensible flexfields, use the Manage Extensible Flexfields task in the Setup and Maintenance work area.

The following aspects are important in understanding extensible flexfields:

  • Usages

  • Categories

  • Pages

  • Security

  • Protected Extensible Flexfield Data

Usages

Similar to the descriptive flexfields, you can define multiple usages for an extensible flexfield, which enables several application tables to share the same flexfield.

For example, a flexfield for shipping options can be used by both a Supplier table and a Buyer table. In addition, you can associate a context with one, some, or all of the flexfield's usages. Thus, with the shipping information example, you can associate a warehouse context with the Supplier usage, a delivery location context with the Buyer usage, and a ship-via context with all usages.

Usages include security information for applying no security to user access or enforcing view and edit privileges. Some product-specific extensible flexfields have specialized usage fields beyond those for security.

Categories

You can configure multiple extensible flexfield contexts and group the contexts into categories. All extensible flexfields have at least one category. For some extensible flexfields, you can configure a hierarchy of categories. A child category in the hierarchy can inherit contexts from its parent category.

You can define categories for extensible flexfields, and you can associate any combination of contexts with a given category.

For example, the Electronics and Computers category hierarchy might include a Home Entertainment category, which in turn might include an Audio category and a TV category, and so on. The Home Entertainment product might have contexts that specify voltage, dimensions, inputs and outputs. Contexts are reusable within a given extensible flexfield. For example, the dimensions context could be assigned to any category that needs to include dimensional information.

Pages

Extensible flexfields let you combine contexts into groups known as pages, which serve to connect the contexts so they will always be presented together in the application user interface.

Each application page corresponds to one extensible flexfield category, with a separate region of the page for each associated context.

Security

When you configure a flexfield, you set the privileges for a context at the usage level by selecting actions for the view and edit privileges of a context usage.

When an end user performs a search, the user interface displays only the attribute values of the contexts for which the user has view privileges. The user can perform a search using all attributes for all contexts, regardless of view privileges.

If end users access a context through a web service, an exception is thrown if they perform an action for which they don't have privileges.

All extensible flexfields have a base data security resource. Some data security resources for extensible flexfields are preconfigured with actions that you can use to specify access privileges. If no action is preconfigured, a security administrator can create actions and policies to support access control on the extensible flexfield attributes.

Some extensible flexfields have a translatable option; these flexfields also have a translation data security resource.

Protected Extensible Flexfield Data

Application developers may mark some data configurations in an extensible flexfield as protected, indicating that you can't edit them.

If an extensible flexfield is partially protected, then you can't edit the protected portions of the flexfield's configuration. For example:

  • If an extensible flexfield context is protected, you can't edit its:

    • Context details

    • Context segments

    • Context usages

  • If an extensible flexfield page is protected, you can't:

    • Edit the page details or delete the page

    • Edit the contexts associated with the page

Note:
  • There is no restriction on page references to protected contexts. The pages you create may contain any context, whether protected or not.

  • There is a restriction on category references to protected contexts. If a context is protected, you can't add it to or delete it from any category.

Considerations for Planning Extensible Flexfields

Once you have identified a flexfield, plan its configuration in advance. Compile a list of the UI pages and other artifacts in your deployment that are affected by the configuration. Verify that you are provisioned with the roles required to view and configure the flexfield. View the flexfield using the Highlight Flexfields option in the Administration menu while viewing the run time page where the flexfield appears. Plan how to deploy the flexfield for test and production users. Review the tools and tasks available for managing flexfields for adding and editing flexfield segments.

Planning an extensible flexfield involves:

  1. Identifying the following:

    • A hierarchical structure of categories

    • Existing context values

    • User-defined attributes, the relevant extensible flexfield segments, segment properties, and the structure

  2. Planning the following:

    • Validation rules

    • Initial values

    • Security

    • Attribute mapping to Oracle Business Intelligence objects.

Category Hierarchy Structure

Existing category hierarchy structures provide the framework for planning what segments to add to an extensible flexfield as user-defined attributes of an entity. Some applications provide user interfaces to create and manage an extensible flexfield's category hierarchy.

Contexts and Existing Context Values

If related attributes can be grouped together, plan adding the attributes as a context of segments, and plan the order in which the attributes should appear. Some extensible flexfields have preconfigured context values. Region headers displayed in the user interface page or pages that contain the flexfield segments identify existing contexts. Using the Manage Extensible Flexfields task, find and open the flexfield for editing to view the list of configured context values.

See product-specific information for guidance in using preconfigured context values.

Plan the Segments and Segment Properties

List all the user-defined attributes that you want to add as extensible flexfield segments. For each segment, define properties, including the indexed property.

Plan Validation Rules

Define each segment's validation rules and check if value sets exist for those rules or you must create. If you must create a value set, you can create it either before you configure the flexfield or at the same time that you create or edit a segment.

When determining a segment's validation rules, consider the following questions:

  • What is the data type: character, date, date and time, or number?

  • Does the segment require any validation beyond data type and maximum length?

  • Should a character type value be restricted to digits, or are alphabetic characters permitted?

  • Should alphabetic characters automatically be changed to uppercase?

  • Should numeric values be zero-filled?

  • How many digits can follow the radix separator of a numeric value? In base ten numeric systems, the radix separator is a decimal point.

  • Should the value be within a range?

  • Should the value be selected from a list of valid values? If yes, consider the following questions:

    • Can you use an existing application table from which to obtain the list of valid values, or do you have to create a list?

    • If you are using an existing table, do you have to limit the list of values using a WHERE clause?

    • Does the list of valid values depend on the value in another flexfield segment?

    • Is the list of valid values a subset of another flexfield segment's list of values?

Plan Initial Values

For every segment, list the constant value or SQL statement, if any, to use for the initial value of the user-defined attribute.

Plan Security

Determine what privileges to set for view and edit access to context attributes, such as providing all users with view access but only managers with edit access.

If your security restrictions apply to several contexts, you can create generic actions. At a minimum, create the generic actions for the base data security resource. If the flexfield has a translatable option and you plan to use translatable contexts, then also create the generic actions for the translation data security resource. For example, the Item flexfield supports the translatable option and has a data security resource ITEM_EFF_VL in addition to the base data security resource ITEM_EFF_B. Then, create actions for both data security resources, such as EDIT_NONTRANS_ATTRS for ITEM_EFF_B and EDIT_TRANS_ATTRS for ITEM_EFF_VL.

If your security restrictions are more fine-grained, such as having to secure each context with a different privilege, then you can create more fine-grained actions.

Plan Which Segments Map to Oracle Business Intelligence Objects

If an extensible flexfield has been enabled for Oracle Business Intelligence, you can make the attributes available for use in Oracle Business Intelligence Applications.

Configuring extensible flexfields involves managing the available flexfields registered with your application database.

The following sequence describes how to configure extensible flexfields:

  1. Configuring contexts by creating each context segment and the context-sensitive segments for each context segment, and providing the following for each segments:

    1. Identifying information

    2. Column assignment

    3. Initial default value

    4. Display properties

  2. Configuring context usages and usage security by selecting actions to which users should have access:

    • View

    • Edit

    • None, if no special privileges should be enforced.

  3. Configuring categories and category details.

  4. Associating contexts with a category.

  5. Creating logical pages for a category.

The following aspects are important in understanding extensible flexfield management:

  • Contexts and pages

  • Categories

  • Initial values

  • Adding segments to highlighted extensible flexfields

  • Indexed segments

  • Security

  • Deployment

Contexts and Pages

Each context is displayed to end users as a region containing its context-sensitive segments. You can specify instruction help text to display instructions that explain how to use the region and its attributes to end users. Instruction help text is displayed at the beginning of the context region. A context can be defined as single row or multi-row. Single row contexts are the same as descriptive flexfields contexts. A single row context has only one set of context-sensitive segments. A multi-row context enables you to associate multiple sets of values with the same object instance.

For example, for a BOOK table, you could create a multi-row context named chapters that contains a segment for chapter and a segment for number of pages. Multiple chapters can then be associated with each book in the BOOK table.

For contexts that store multiple rows, you can uniquely identify each row by having the values in each row form a unique key.

If flexfield has a category hierarchy, then you can leverage the hierarchy to reuse contexts for similar entities, such as similar items in a product catalog.

Set the context to translatable so that free-form text entered by end users is stored in the language of the user's locale, and different translations of that text can be stored in other languages. Segments in the translated contexts should use format-only value sets for storing free-form, user-entered text.

Set the context security to give an end user view or edit access to a context. The context's task flow and region appear in the user interface only for users with view access. With edit access, an end user can edit the context's attribute values. With no action specified for a usage, no special privileges are enforced through the context's configuration.

Define logical pages to group contexts together in the user interface. For a given category, you may create one or more logical pages. You may add one or more of the category's associated contexts to each of the category's logical pages.

You can specify:

  • The sequence of the contexts within each page.

  • The sequence in which the logical pages appear.

  • Instruction help text to display instructions that explain how to use the page to end users. Instruction help text is displayed at the beginning of the logical page, preceding all of its context regions.

Categories

A category is a grouping of related data items that can be considered to belong together. You can associate any combination of contexts with a given category. Extensible flexfields with more than 30 categories must be deployed as a background process.

A category hierarchy logically organizes a set of categories. For example, the Electronics and Computers category hierarchy might include a Computer category and a Home Entertainment category, which in turn might include an Audio category and a TV category, and so on.

A category can be a child or sibling of an existing category. The hierarchy can be as simple or as complex as desired, with any combination of zero or more sibling categories and zero or more child categories. If no category is defined, the data items are grouped in a single predefined default category.

Each category has associated contexts that store relevant information about a data item in that category. For example, a Home Entertainment product has contexts that specify Voltage, Dimensions, Inputs and Outputs. Contexts are reusable within a given extensible flexfield. Then, the Dimensions context could be assigned to any category that needs to include dimensional information.

If a hierarchy includes child categories, each child category inherits the contexts from its parent category; for example, the Home Entertainment category inherits Voltage and Dimensions from the Electronics and Computers category.

Each extensible flexfield is associated with a particular category hierarchy. Consider category hierarchies to be defining framework for extensible flexfields and their contexts. A category hierarchy specifies which contexts are valid for each category.

An extensible flexfield can include multiple contexts which you define to support a given category. These contexts can be suitable for various purposes, but within a particular category, some contexts might be considered to be related to, or dependent on, each other. You can combine these contexts into groups known as logical pages, and determine the sequence in which the pages appear. This serves to connect the contexts so they will always be presented together and in a particular order in the application user interface.

For example, the Home Entertainment category might have an Electrical Specifications page that contains the Voltage, Inputs and Outputs contexts, and a Physical Specifications page that contains the Dimensions and Form Factor contexts.

Initial Values

The SQL statement defining an initial value must be a valid statement that returns only one row and a value of the correct type.

You can use two types of SQL statements:

  • SQL statement with no binding. For example, select MIN(SALARY) from EMPLOYEES.

  • SQL statement with bind variables. You can use the following bind variables in the WHERE clause of the SQL statement.

    • :{SEGMENT.<segment_code>}: Identifies a segment in the same context.

    • :{CONTEXT.<context_code>;SEGMENT.<segment_code>}: Identifies a segment in a different context. The context must be in the same category or in an ancestor category, and it cannot be a multiple-row context.

    • :{VALUESET.<value_set_code>}: Identifies the closest prior segment in the same context that is assigned to the specified value set.

    • :{FLEXFIELD.<internal_code>}: Identifies a flexfield.

For more information about using bind variables, see the help for value sets.

Adding Segments to Highlighted Extensible Flexfields

When you highlight flexfields on a run time page and use an Add Segment icon button to create a segment, the segment code, name, description, table column, and sequence number are set automatically. If you use an Add Segment icon button to configure extensible flexfield segments, you can't use an existing value set. Value sets are created automatically when you add segments. You can enter the valid values, their descriptions, and the default value or specify the formatting constraints for the value set, such as minimum and maximum values.

Depending on display type, the value set you create with the Add Segment icon button is either an independent value set or a format-only value set. The following table shows which type of value set is created depending on the segment display component you select.

Display Component Value Set Created Using Add Segment

Check Box

Independent

Drop-down List

Independent

List of Values

Independent

Radio Button Group

Independent

Text Field With Search

Independent

Text box

Format Only

Text area

Format Only

Rich Text Editor

Format Only

Date/Time

Format Only

Tip: After you add a context value, refresh the page to see the new value.
Indexed Segments

You can designate an extensible flexfield segment as indexed so that it's one of the selectively required attributes a user can use in an attribute search. If you indicate in the Manage Extensible Flexfield UI page that a segment should be indexed, the column representing the segment must be added to the database index. Commonly, a database administrator (DBA) adds columns to the database index.

When an extensible flexfield with indexed segments is deployed, search task flows are generated along with the other flexfield artifacts and specify the indexed attributes as selectively required. In the deployed extensible flexfield's search task flow, an end user must specify at least one of the indexed attributes in the search criteria. This prevents non-selective searches, which could cause performance issues.

For example, if you index the memory and processor attributes and ensure that the corresponding columns in the database are indexed, a user can search an item catalog for computers by entering processor or memory or both as a search criteria. No search is performed if an end user enters an attribute that isn't indexed as a search criterion.

Security

An extensible flexfield's base data security resource typically has a name with an _B suffix. The translation data security resource is a view of a translation table that typically has a name with an _VL suffix.

If a flexfield supports the translatable option and has a translation data security resource, make sure that you create the action for the appropriate data security resource.

  • If you create a context-specific action for a nontranslatable context, add it to the base data security resource.

  • If you create a context-specific action for a translatable context, add it to the translation data security resource.

Deployment

You can only deploy extensible flexfields using the Manage Extensible Flexfields task. You can deploy extensible flexfields offline as a background process and continue working in the session without having to wait for the deployment to complete. You can queue up several extensible flexfields and deploy as a background process. The flexfields are deployed, one at a time, in the order that you deploy them to the queue. You must deploy extensible flexfields with more than 30 categories as a background process.

You can remove an extensible flexfield from the deployment queue with the Cancel Background Deployment command. When an extensible flexfield is deployed in a background process, its offline status indicates that the flexfield is in a background deployment process. A flexfield's offline status is cleared and it's deployment status updated when the background deployment process has completed.

Note: The Offline Status column refreshes when you perform a new search in the Manage Extensible Flexfields task.

Considerations for Enabling Extensible Flexfield Segments for Business Intelligence

An extensible flexfield that is registered in the database as enabled for Oracle Business Intelligence (BI) includes a BI Enabled setting for each of its segment instances. When a segment instance is BI-enabled, it's available for use in Oracle Business Intelligence.

The following aspects are important in understanding BI-enabled extensible flexfield segments.

  • Flattening business components to use BI-enabled segments in Oracle BI

  • Mapping attributes of flattened business components to logical objects in Oracle BI

After you deploy a business intelligence-enabled flexfield, use the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process to import the flexfield changes into the Oracle Business Intelligence repository. Users can make use of the newly-generated attributes in business intelligence applications. For additional information about logical objects and import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Flattening

When you deploy a business intelligence-enabled extensible flexfield, the deployment process generates an additional set of flattened business components for use in business intelligence. The flattened business components include attributes for business intelligence-enabled segment instances only.

If you assigned a label to a segment, the flattened components include a single attribute representing all segment instances with that label. If you didn't assign a label, the flattened components include a discrete attribute for each BI-enabled segment instance in each structure.

Importing to Oracle Business Intelligence Repository

After you deploy a business intelligence-enabled flexfield, import the flexfield changes into the Oracle Business Intelligence repository to make use of the newly flattened business components in business intelligence and then propagate the flexfield object changes. When you import the metadata into the Oracle Business Intelligence repository, you must do so as the FUSION_APPS_BI_APPID user. To import flexfield changes into the Oracle Business Intelligence repository in Oracle Cloud implementations, run the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process. For additional information about import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Tip: When you import a flexfield into the Oracle Business Intelligence repository, you see both <name>_ and <name>_c attributes for each segment, along with some other optional attributes. The <name>_ attribute contains the value. The <name>_c attribute contains the code of the value set that the value comes from, and is used for linking to the value dimension. You must import both attributes.

Considerations for Managing Extensible Flexfield Categories

Categories are a way of extending the number of context-sensitive segments for a flexfield beyond the columns reserved for flexfield segments.

For example, an Items extensible flexfield has a category for each item and each category can have one or more contexts. The laptop item belongs to the Computers category. Since extensible flexfields are mapped to separate extension tables, not just to columns as with descriptive flexfields, the thirty reserved columns on the extensible flexfield table let you define up to thirty context-sensitive segments for each context.

If you add a Dimensions context to the Computers category, thirty segments are available. But if you need to add more than thirty attributes, create another context and associate it to the same category. You could now add an Electronics Attributes context to the same Computers category in which you create another thirty segments. You can continue creating more contexts and adding them to the Computers category. In this way your laptop computer item can be extended with as many attributes as you need, because it is mapped to a category and you can keep adding contexts to that category.

A descriptive flexfield on an items table with thirty columns reserved for segments can only have a single context. Once you configure the columns for that one context, you cannot create any more segments.

Predefined and Preconfigured Categories

How you structure the flexfield configuration depends on how categories are defined for the flexfield. If the extensible flexfield is preconfigured with one category, associate all your contexts and pages with that category. If a product-specific extensible flexfield is preconfigured with several categories, associate your contexts and pages with those categories. If the extensible flexfields provide user interfaces for configuring multiple categories, associate a context with more than one category using inheritance.

Some products provide an activity or task for creating and maintaining categories for an extensible flexfield. See product-specific information to determine if you can create categories for the flexfield.

You can view a flexfield's category hierarchies by using either the Highlight Flexfields feature or the Manage Extensible Flexfields task to find and open the flexfield for editing.

Disabling Categories

While configuring an extensible flexfield, you can disable a category. The Enabled column in the Category table of the Edit Extensible Flexfield page, indicates which categories are enabled.

Note: When you deploy an extensible flexfield that has a disabled category, that category and its descendant categories aren't deployed. Contexts and their segments are deployed only if they belong to at least one enabled category.
Contexts

Group similar attributes into contexts. The group is displayed together in a region. The region's header is the context value.

If a category hierarchy exists for the flexfield, then you can leverage the hierarchy to reuse contexts for similar entities, such as similar items in a product catalog.

The following figure shows the Item Extended Attributes flexfield, which uses the category hierarchy feature to reuse contexts. The flexfield's Electronics and Computers category contains contexts for compliance and certification, voltage, and materials and substances. The TV and Video subcategory and the Computer Products subcategory inherit the Electronics and Computer contexts in addition to having their own contexts. The Materials and Substances context belongs to both the Electronics and Computer Products category and the Tools, Auto, and Industrial Products category.

The figure shows how a context is reused in multiple
categories

The following table shows an example of category hierarchy for an extensible flexfield. To store voltage information for all electronic and computer items, associate a Voltage context with the Electronics and Computers category. Both the TV and Video subcategory and the Computers subcategory then inherit the Voltage context from the parent Electronics and Computers category.

Display Name Code Description

Electronics and Computers

PROD_ELECTRONICS

Electronics and Computers

  • TV and Video

PROD_TV_VIDEO

Television and Video

  • Computers

PROD_COMPUTERS

Computers

Office Products and Supplies

PROD_OFFICE_PRODUCTS_SUPPLIES

Office Products and Supplies

Tools, Auto, and Industrial

PROD_TOOLS_AUTO_INDUSTRIAL

Tools, Automotive, and Industrial

Sports and Outdoors

PROD_SPORTS_OUTDOORS

Sports and Outdoors

Example of Configuring an Item Extended Attributes Flexfield

The Item Extended Attributes flexfield provides segments for extending the Item business object. In the Manage Extensible Flexfields task, configure your product business object to include a technical specifications logical page on the user interface for the Electronics and Computers category of items.

In this example, your configuration of this flexfield groups attributes into the following contexts:

  • Materials and Substances

  • Compliance and Certification

  • Voltage

Scenario

The following list shows an example plan for computer attributes for the Item Extended Attributes flexfield. In this example, the Electronics Information page is inherited from the parent Electronics and Computers category.

  • Page: Electronics Information

    • Context: Compliance and Certification, single row

      • ISO 14001 (International Organization for Standardization for an Environmental Management System)

      • ENERGY STAR (energy efficiency guidelines)

      • ROHS (Restriction of the use of certain hazardous substances in electrical and electronic equipment)

    • Context: Voltage, single row

      • Minimum voltage

      • Maximum voltage

      • Current type

    • Context: Materials and Substances, multiple rows

      • Material

      • Contain recyclate

      • Percent unit mass

  • Page: Computer Information

    • Context: Processor Specifications, single row

      • Manufacturer

      • CPU type

      • Processor interface

      • Processor class

      • Processor speed

      • Cores

The following table summarizes key decisions for this scenario.

Decisions to Consider In This Example

Which extensible flexfield is available for configuring a hierarchy of categories?

Item Extended Attributes flexfield

Collecting Technical Specifications

Your product inventory pages for electronics and computers require a technical specifications page. Your product inventory pages for furniture require a furniture specifications page and an assembly instructions page. Items in both the electronics and computer category, and in the furniture category, share attributes for specifying materials and substances.

The following figure shows a technical specifications logical page in the user interface for the Electronics and Computers category. It contains attributes in the context of Recovery and Recycling, Compliance and Certification, Operating Conditions, and Materials and Substances. The Materials and Substances context is configured for multiple rows. Your users can select all the materials and substances required to make a single product.

The figure displays technical specifications logical
page in the user interface for the Electronics and Computers category,
with attributes in the context of Recovery and Recycling, Compliance
and Certification, Operating Conditions, and Materials and Substances
Analysis

Use logical pages to determine how the contexts appear on the user interface. Use a context to store all the materials and substances required to make a single product. You can configure a context to store multiple rows per entity. The multiple rows are displayed in a table, like the Materials and Substances context.

The Technical Specifications logical page contains the attributes for the four contexts.

  • Recovery and Recycling

  • Compliance and Certification

  • Operating Conditions

  • Materials and Substances

The following figure is an example, where the Furniture category is configured to include a Furniture Specifications logical page and an Assembly Instructions logical page. The two categories (Electronics and Computers and Furniture) share the Materials and Substances context.

The figure is a chart showing the Furniture category
configured to include a Furniture Specifications logical page and
an Assembly Instructions logical page. The two categories (Electronics
and Computers, and Furniture) share the Materials and Substances context.
Configure Security for the Item Flexfield Configuration

The following table shows an example of data security policies for the Item flexfield.

Data Security Resource Policy Role Action Condition

ITEM_EFF_B

A

VOLTAGE_SPEC

edit_nontrans_voltage_ctx

All values

ITEM_EFF_VL

B

COMPLIANCE_SPEC

edit_trans_compliance_ctx

All values

ITEM_EFF_VL

C

COMPUTER_SPEC

edit_trans_attrs

ComputerCategoryFilter

ITEM_EFF_VL

D

TELEVISION_SPEC

edit_trans_attrs

TVCategoryFilter

The following table shows the privileges for the three flexfield contexts.

Context Edit Privilege View Privilege

Voltage

edit_nontrans_voltage_ctx

NONE

Compliance and Certification

edit_trans_compliance_ctx

NONE

Materials and Substances

edit_trans_attrs

NONE

In this example, anyone can view the contexts' attributes, but the edit privileges are restricted as follows:

  • Voltage: Only voltage specialists can edit this value.

  • Compliance and Certification: Only compliance specialists can edit this value.

  • Materials and Substances: Only computer specialists can edit these attributes for items in the computer category. Only television specialists can edit these attributes for items in the TV category.

To sum up, in this entire example, the Materials and Substances context is secured by a generic action with a condition applied to restrict access by category. Voltage and Compliance and Certification are secured by actions specific to each context.

File Format for Importing Extensible Flexfields

To import extensible flexfields into an application, you create separate text files for the value sets, contexts, and context segments. Then, you upload them to the Oracle WebCenter Content document repository. Each file must follow a specific format, as described here. After the files are placed in the document repository, you can import the values sets, contexts, and context segments into the application.

While creating the file, adhere to the following guidelines:

  • Use a vertical bar or pipe ( | ) as a delimiter between fields for both header and value rows.

  • Set the file encoding to UTF-8 without the Byte Order Mark (BOM) as per the Oracle WebCenter Content specification.

The following sections contain specific details about each file format.

Prerequisite

You must have worked with flexfields in Oracle Cloud applications.

Value Sets

To create a file containing value sets, include the headers listed in the following table:

Header Data Type Data Size Description Required or Optional

ValueSetCode

String

60

This value identifies your value set across components.

Required

ModuleType

String

60

This value determines the module type of your value set.

Required

ModuleKey

String

60

This value determines the specific module of your value set.

Required

ValidationType

String

30

This value determines your value set type. The values you can use are DEP, INDEP, FORMAT, SUBSET, and RELATED.

Required

ValueDataType

String

30

This value determines the data type that your value set uses. Supported data types are VARCHAR2, NUMBER, DATE, and TIMESTAMP.

Required

ValueSubType

String

30

This value determines the data subtype your value set uses. Supported data subtypes are TEXT, TIME_HM, NUMERIC, TIME_HMS, and TRANSLATED

Required for ValueDataTypeVARCHAR2

MaximumLength

Integer

-

This value determines the maximum length of values in your value set.

Required for ValueDataTypeVARCHAR2

Description

String

240

This value gives your value set a description.

Optional

Precision

Integer

-

This value determines the number of digits in the number data you add in your value set.

Optional

Use this header only for ValueDataTypeNUMBER

Scale

Integer

-

This value determines the number of digits to the right of the decimal point in the number data you add in your value set.

Optional

Use this header only for ValueDataTypeNUMBER

UppercaseOnlyFlag

String

1

If this value is set to Y, then your value set will accept only uppercase characters. If it is N, then both uppercase and lowercase characters are supported.

Optional

Use this header only for ValueDataTypeVARCHAR2

ZeroFillFlag

String

1

If this value is set to Y, then zeroes are added to the left of the text you add in your value set, till the text length matches your MaximumLength. If the value is N, no zeroes are added.

Optional

Use this header only for ValueDataTypeVARCHAR2

SecurityEnabledFlag

String

1

If this value is set to Y, you can add a data security resource to your value set. If the value is N, no data security resource is added.

Optional

DataSecurityObjectName

String

60

This value selects the data security resource you want to add to your value set. This value must match a data security resource in the application.

Required if SecurityEnabledFlag is set to Y.

MinimumValue

String

150

This value specifies the minimum value for the values in your value set.

Optional

MaximumValue

String

150

This value specifies the maximum value for the values in your value set.

Optional

IndependentValueSetCode

String

60

This value determines the independent value set your dependent or subset value set is linked to.

Required for ValidationTypeDEP and SUBSET

Don't use this header for validation types other than DEP and SUBSET.

Here's a sample file that contains the header values at the beginning of the file, followed by line entries of the three value sets that are to be imported. For importing several value sets, add more line entries in a similar format.

ValueSetCode|ModuleType|ModuleKey|ValidationType|ValueDataType|ValueSubtype|MaximumLength|Description
VS_TEST_91|APPLICATION|FND|INDEP|VARCHAR2|TEXT|2|desc1
VS_TEST_92|APPLICATION|FND|INDEP|VARCHAR2|TEXT|3|
VS_TEST_93|APPLICATION|FND|INDEP|VARCHAR2|TEXT|3|desc3
Context

To create a file containing the contexts, include the headers in the following table:

Header Data Type Data Size Description Required or Optional

ApplicationId

Long

-

This value determines the Application to which your flexfield and context belongs to.

Required

EFFCode

String

40

This value is the code of the extensible flexfield to which you are adding your context. This value should match the code of an extensible flexfield that is already in the application.

Required

ContextCode

String

80

This value is the code for your context.

Required

Name

String

80

This value determines the display name of your context.

Required

MultirowFlag

String

1

If this value is set to Y, then your context will support multi-row behavior. If the value is N, only single row behavior is supported.

Required

EnabledFlag

String

1

If this value is set to Y, then your context is enabled. If the value is N, then your context is disabled.

Required

Description

String

240

This value gives your context a description.

Optional

TranslatableFlag

String

1

If this value is set to Y, then the segments in your context are translatable. If the value is N, they are not.

Optional

ContextIdentifier

String

30

This value determines the API name for your context. There are a set of conventions to be followed when naming APIs.

Optional

InstructionHelpText

String

400

This text gives the user instructions about how to use the context region.

Optional

FlexfieldUsageCode

String

30

This value determines the usage code for your context. The value should match a usage code in the application.

Required

ViewPrivilegeName

String

400

This value determines which privileges can view this context usage. The value should match a privilege in the application.

Optional

EditPrivilegeName

String

400

This value determines which privileges can edit this context usage. The value should match a privilege in the application.

Optional

CExtAttribute1

String

150

This header adds a user defined attribute to a context usage.

You can use up to 5 headers of this type, CExtAttribute1 to CExtAttribute5 to add your user defined attributes.

Optional

CONTEXT_CExtAttribute1

String

150

This header adds a user defined attribute to a context.

You can use up to 5 headers of this type, CONTEXT_CExtAttribute1 to CONTEXT_CExtAttribute5 to add your user defined attributes.

Optional

Here's a sample file that contains the header values at the beginning and lists three contexts to be imported. For importing several contexts, add more entries in the same format.

ApplicationId|EFFCode|ContextCode|Name|EnabledFlag|MultirowFlag|Description|FlexfieldUsageCode|ViewPrivilegeName|CExtAttribute1|CExtAttribute2|CExtAttribute3|CExtAttribute4|CExtAttribute5
0|FLEX_SN_EFF1|OBJ_TEST_4|Object test 44|Y|N|desc 44 3363|FLEX_SN_EFF1_USAGE2|flex_sn_sitems_view|||||
0|FLEX_SN_EFF1|OBJ_TEST_3|Object test 33|Y|N||FLEX_SN_EFF1_USAGE1|flex_sn_view|||||NEW_TEST11
0|FLEX_SN_EFF1|OBJ_TEST_3|Object test 33|Y|N|new desc aug 14|FLEX_SN_EFF1_USAGE2|flex_sn_sitems_edit|CE1_TESTupd_aug15||||
Context Segment

To create a file containing context segments, include the headers in the following table:

Header Data Type Data Size Description Required or Optional

ApplicationId

Long

-

This value determines the Application to which your flexfield, context, and segment belongs to.

Required

EFFCode

String

40

This value is the code of the extensible flexfield to which you are adding your segment. This value should match the code of an extensible flexfield that's already in the application.

Required

ContextCode

String

80

This value is the code for the context to which you are adding your segment. This value should match a context code that's in the application.

Required

SegmentCode

String

30

This value is the code for your segment.

Required

Name

String

60

This is the back end name for your segment.

Required

ColumnName

String

30

This value determines the table column your segment uses to save data. This value must match a column that's in the application.

Required

ValueSetCode

String

60

This value is the code for the value set you want to use in your segment. This value must match a value set code in the application.

Required

DisplayType

String

30

This value determines the display type of the segment.

Valid values for this attribute are TEXT_BOX, TEXT_AREA, RICH_TEXT_EDITOR, HIDDEN,LOV, POP_UP_LIST, DROP_DOWN_LIST, RADIO_BUTTON_GROUP, STATIC_URL, CHECKBOX, COLOR, DATE_TIME

Required

Prompt

String

80

This value determines the display name of the segment.

Required

ShortPrompt

String

80

This value determines the shortened display name of the segment.

Required

EnabledFlag

String

1

If this value is set to Y, then your segment is enabled. If the value is N, then it's disabled.

Required

RequiredFlag

String

1

If this value is set to Y, user input for this segment is mandatory during run time. If the value is N, user input is optional.

Required

ReadOnlyFlag

String

1

If this value is set to Y, then your segment is read-only. If the value is N, it's not.

Required

Description

String

240

This value gives your segment a description.

Optional

UOMclass

String

20

This value determines the unit for the data you add in your segment.

Optional

TerminologyHelpText

String

80

This text provides a description for the segment.

Optional

InFieldHelpText

String

160

This text provides instructions on how to use the segment.

Optional

SequenceNumber

Integer

-

This value determines the order in which your segments are displayed in your context.

Optional

DefaultType

String

30

This value determines the type of default value your segment takes if the user does not enter any data in your segment. The types are CONSTANT, SQL, and GROOVY_EXPRESSION

Optional

DefaultValue

String

4000

This value determines the default value your segment takes if the user doesn't enter any data.

Optional

DisplayWidth

Integer

-

This value determines the display width of your segment, in terms of maximum number of characters displayed in a line.

Optional

DisplayHeight

Integer

-

This value determines the display height of your segment, in terms of maximum number of lines displayed in the segment.

Optional

CheckboxCheckedValue

String

30

This value determines the value of a checked check box in your segment.

Required for display type CHECKBOX.

CheckboxUncheckedValue

String

30

This value determines the value of an unchecked check box in your segment.

Required for display type CHECKBOX.

RangeType

String

30

This value sets two fields as two ends of a range of values. Set value as LOW or HIGH for your low end and high end fields respectively.

Optional

BIEnabledFlag

String

1

This value determines whether your segment is BI enabled. Y means it is, N means it's not.

Optional

MultirowUniqueKeyFlag

String

1

If this value is set to Y, the segment is marked as the unique key for a multirow context. Default value for this header is N. At least 1 segment in a multirow context must be marked as the unique key.

Required for multi-row contexts

ShowValueDescription

String

1

If this value is set to Y, the value set description for the value set associated to the segment is displayed. If the value is N, it's not displayed.

Optional

SegmentIdentifier

String

30

This value determines the API name for your segment. There are a set of conventions to be followed when naming APIs.

Optional

Here's a sample file that contains the header values at the beginning and lists a context segment to be imported. For importing several context segments, add more entries in the same format.

ApplicationId|EFFCode|ContextCode|SegmentCode|Name|ColumnName|ValueSetCode|DisplayType|Prompt|ShortPrompt|EnabledFlag|RequiredFlag|ReadOnlyFlag|Description|UomClass
0|FLEX_SN_EFF1|ColdSourceTargetContext|Cold_TEST_SEG1|cold seg 1|ATTRIBUTE_CHAR3|EFF_BASIC_FMT_CHR|TEXT_BOX|Prompt|Short Prompt|Y|Y|N|TEST desc aug 14_3PM|

FAQs for Extensible Flexfields

Why did the extensible flexfield context not appear at run time?

If a deployed extensible flexfield context doesn't appear in the user interface, verify that the context is associated with one of the category's pages defined for the extensible flexfield.

Key Flexfields

Key flexfields provide a means to capture a key such as a part number, a job code, or an account code. A key flexfield consists of one or more segments, where each segment can have a meaning.

For example, a part number 10-PEN-BLA-450 might correspond to a black pen from supplier #450 sold by division #10 (office supplies). Behind the scenes, the application uses a unique number, 13452, for this part, but the user always sees the 10-PEN-BLA-450 part number.

The following aspects are important to understanding key flexfields:

  • Architecture

  • Segments and segment labels

  • Structures

  • Segment and structure instances

  • Combinations

  • Dynamic combination creation

  • Security

Key flexfields aren't optional. You must configure key flexfields to ensure that your applications operate correctly. You configure and maintain key flexfield definitions with the Manage Key Flexfields task. To get a list of predefined key flexfields, use the Manage Key Flexfields task in the Setup and Maintenance work area. For information about specific key flexfields, see the help for the product where the associated business component is implemented.

Architecture

Flexfield metadata is stored in the flexfield metadata tables. When you configure a key flexfield, you define metadata about the key flexfield covering aspects such as:

  • Segments are in a structure

  • Structures in the flexfield

  • Value sets in each segment

Based on the flexfield metadata, actual part numbers are captured at run time as a combination of segment values and stored in a combinations table. A combinations table contains all the segment columns for a flexfield, a unique ID column, and a structure instance number column. The structure instance number column differentiates multiple arrangements of the segment columns. For example, a part number containing multiple segments can be represented by a key flexfield. A part number key flexfield has a corresponding combinations table. In that table, the flexfield stores a list of the complete codes, with each segment of the code in a column, with the corresponding unique ID and structure instance number for the code. When users define a new part number or maintain existing part numbers in the parts catalog, they directly maintain rows in the combinations table.

The foreign key table contains a different business entity than the combinations table. For example, the business entity in the foreign key table is order lines or invoice lines that contain foreign key references to parts for ordering. Any number of foreign key tables can reference a particular entity represented by a key flexfield.

Segments and Segment Labels

A key flexfield contains segments and a segment label identifies a particular segment within a key flexfield. Segment labels are defined and made available by the product development. A segment contains the following details:

  • A prompt

  • A short prompt

  • Display width

  • The sequential position of the segment within the key flexfield structure

  • The range type

  • Column name of the attribute being stored by the segment

  • A default value set

  • A label for the segment

Applications identify a particular segment for some purpose such as security or computations. Segment name or segment order cannot reliably identify a segment because key flexfield segments can be configured to appear in any order with any prompts. A segment label functions as a tag for a segment.

For example, the requirement is to identify which segment in the accounting flexfield contains balancing information and which segment contains natural account information. A segment label determines which segment you are using for natural account information. When you define your accounting flexfield, you must specify which segment labels apply to which segments. Some labels must be unique, and cannot be applied to more than one segment in each structure. Other labels are required, and must be applied to at least one segment in each structure.

A segment label helps a user searching for segments, such as the Cost Center label for all segments across key flexfields that store a value for the cost center.

Structures

A key flexfield structure definition includes the number of segments and their order.

In some applications, different users like to see different segment structures for the same flexfield. A key flexfield can have multiple structures if registered to support more than one structure.

The flexfield can display different fields for different users based on a data condition in your application data, such as the value of another field entered by the user or the user's role. For example, the correctly formatted local postal address for customer service inquiries differs based on locale. A postal address key flexfield could display different segments and prompts for different users based on a location condition in your application data, such as the user's role or a value entered by the user.

Each structure can have one or more segments. Thus a segment is a child of a structure. To store a particular segment, such as Cost Center, in two different structures, you must define the segment separately in each structure. Each structure may have one or more structure instances. Each instance of a structure shares the same number and order of segments, but differs in the values or value sets used in validating the segments.

Structure and Segment Instances

You can define multiple configurations of a key flexfield structure. These structure instances have the same segment structure, in the same sequence order. They differ primarily in how each segment is validated. You define a structure instance for each key flexfield and each key flexfield structure instance.

The segments in a key flexfield structure instance are segment instances. A segment instance is a segment with a specific value set assigned to it. If a key flexfield is registered with a tree structure, you can specify a tree code for a segment instance.

Combinations

A combination is a complete code, or combination of segment values that makes up the code, that uniquely identifies an object.

For example, each part number is a single combination, such as PAD-YEL-11x14 or 01-COM-876-7BG-LTN. In these combinations, the hyphen is the segment separator. If you have ten parts, define ten combinations. A valid combination is an existing or new combination that can be used because it's currently active and doesn't violate cross-validation or security rules. A combination has different segments depending on the flexfield structure being used for that combination. Any combination is associated with only one particular flexfield structure.

Many applications refer to a key flexfield combination by using the name of the entity or the key flexfield itself. For example, Assets uses the asset key flexfield and refers to one of its combinations as an asset key or asset key flexfield. In another example, Oracle Fusion General Ledger refers to combinations of the accounting flexfield as account or GL account.

Each key flexfield has one corresponding table, known as the combinations table, where the flexfield stores a list of the complete codes, with one column for each segment of the code, together with the corresponding unique ID number (an account combination ID) for that code. Then, other tables in the application have a column that stores just the unique ID for the code. For example, you may have a part number code, such as PAD-YEL-11x14. The Parts combinations table stores that code along with its ID, 57494. If your application lets you take orders for parts, you might then have an Orders table that stores orders for parts. That Orders table would contain a single column that contains the part ID, 57494, instead of several columns for the complete code PAD-YEL-11x14. Typically, one combinations page maintains the key flexfield, where the key flexfield is the representation of an entity in your application. Maintain individual combinations, such as part numbers in the combinations page.

Dynamic Combination Creation

Dynamic combination creation is the insertion of a new valid combination into a combinations table from a page other than the combinations page. The following table lists the levels at which dynamic combination creation may be enabled.

Level Of Dynamic Combination Creation Controlled By:

Flexfield

Application development

Each usage or reference to the key flexfield

Application development

Structure instance

Administrators and implementation consultants

Other

Administrators and implementation consultants

If your key flexfield or certain usages or references of the key flexfield don't permit dynamic combination creation, you may control whether dynamic combination creation is enabled for each structure instance. If enabled, a user can enter a new combination of segment values using the flexfield window from a foreign key page. For example, when entering a transaction, a GL user can enter a new expense account combination for an account that doesn't yet exist. Your application creates the new account by inserting the new combination into the combinations table behind the scenes. Assuming that the new combination satisfies any existing cross-validation rules, the flexfield inserts the new combination into the combinations table, even though the combinations table isn't the underlying table for the foreign key page.

Considerations for Planning Key Flexfields

Your first step in planning your key flexfields is to determine which key flexfields your application requires. Your plan should include:

  • The purpose of the key flexfield

  • The number and length of its available segment columns

  • Whether your key flexfield permits more than one structure

  • Whether more than one structure must be defined

  • The number, order and length of your segments for each structure

Before You Begin

Once you have identified a flexfield, plan its configuration in advance. Compile a list of the UI pages and other artifacts in your deployment that are affected by the configuration. Verify that you are provisioned with the roles required to view and configure the flexfield. Use the Highlight Flexfields command in the Administration menu to view the run time page where the flexfield appears. Plan how you deploy the flexfield for test and production users and review the tools and tasks available for managing flexfields.

If you plan to use value sets, create them before configuring the key flexfield. You cannot create value sets for key flexfields at the time that you add and configure key flexfield segments.

Access to Flexfield-Related Tasks

To configure flexfields and value sets, you must have access to the tasks for managing flexfields. Contact your security administrator for details. For information about product-specific flexfield tasks, such as Manage Fixed Assets Key Flexfields, refer to the product-specific documentation.

Restrictions

If you plan to use value sets, create them before configuring the flexfield. Plan your key flexfield configuration to scale to your enterprise needs. For example, if you expect to disable old cost centers and enable new ones frequently, plan a larger maximum size for your cost center value set so that you can have more available values. A 3-character value set with one thousand available values provides more room for changes than a 2-character value set with 100 available values.

Note the code name of the flexfield you intend to configure so that you find it easily in the tasks for managing key flexfields. In some cases you can configure how the flexfield appears on the page. See product-specific documentation to determine any restrictions on using product-specific key flexfields.

Reporting

To report on your data by certain criteria or sub-entities, such as account number or project or region, consider making that sub-entity a distinct segment, rather than combining it with another sub-entity. You can categorize and report on smaller discrete units of information.

Considerations for Managing Key Flexfields

Consider the plans for a key flexfield, security, and resulting run time pages when configuring key flexfields.

Planning

Plan structures carefully and enable them for future needs. Don't change the number, order, and maximum length of segments once you have acquired flexfield data.

Structure Delimiters

A delimiter separates the segments when they appear to users. The delimiter value of a structure specifies the character used to visually separate segment values when the key flexfield is displayed as a string of concatenated segments in the UI.

Identify the delimiter value of your key flexfield carefully so that it doesn't conflict with the flexfield data. For example, if your data frequently contains periods, such as in monetary or numeric values, don't use a period as your segment separator. Any character you expect to appear frequently in your segment values or descriptions isn't a good choice for the delimiter. If you change the configuration of a key flexfield, such as the delimiter, the change affects the previously stored key flexfields with that structure.

Security

Oracle Fusion data security enforces value set security.

Within key flexfields, value set security applies to the selection of the individual segment values in the segment list of values. When selecting a key flexfield segment value from the combinations table, data security permits display of only the combinations whose segment values you have access to. Applications development controls whether or not value set security rules propagate to the foreign key table. By default they do.

Run Time Pages

Application development determines the user interface (UI) pages used to render flexfields. The types of key flexfield UI pages are as follows:

  • Combinations pages where the underlying entity objects use the combinations table itself

  • Foreign key pages where the underlying entity objects contain a foreign key reference to the combinations table

  • Partial usage pages where some or all of the key flexfield's segment columns are in a product table

The same key flexfield can be used in different ways on different pages.

A page with a foreign key reference has a base table or view that contains a foreign key reference to a combinations table with the actual flexfield segment columns. This lets you manipulate rows containing account combination IDs (account combination).

A page with partial usage of a key flexfield presents segments that are defined on a product's transactional table in addition to being defined on a combinations table. In the case of a partial usage page, only a part of the configuration is likely to be visible. This enables the key flexfield to act more like a descriptive flexfield.

An account combination maintenance page or combinations page presents the combinations table. This enables directly creating and maintaining account combinations. The combinations table contains all key flexfield segment columns and a unique ID column.

A typical application has only one combinations page. An application might not have a combinations page if it doesn't support maintenance by administrators.

A page containing a search region enables users to select which attributes of the key flexfield view object to use as criteria to search for flexfield metadata.

For example, you can configure seven segments for the Account key flexfield. In a foreign key reference page, users see the typical key flexfield picker with all seven segments where they can search for combinations. In a partial usage page using the same key flexfield, users potentially could see only a single segment such as the Cost Center labeled segment, or they might see multiple segments but displayed as individual segments rather than options for selecting combinations.

For more information about key flexfield pages, see the Oracle Fusion Applications Developer's Guide.

A key flexfield structure arranges the segments of a key so that you can reuse a single key flexfield in multiple combinations of the same segments or a subset of those segments. Multiple instances of a single structure can accommodate differences in the value sets assigned to the structure's segments.

The structure determines the following aspects of a key flexfield:

  • The segments to include

  • The order of the segments

  • Segment labels on the included segments

  • Properties for each segment applied to the instances of the segments in an instance of the structure

Managing Key Flexfield Structures

All the segments defined for a key flexfield are available to be included in a key flexfield structure.

You can define as many segments as there are defined segment columns in your key flexfield combinations table. Ensure that you add segments in the order that your key requires. Once deployed, the order cannot be changed.

Enable segments to indicate that they are in use. A flexfield doesn't display disabled segments in run time. To protect the integrity of your data, disable a segment if you have already used it to enter data.

A key flexfield structure can have one or more alternate structure instances. The instances of a key flexfield structure share the following aspects of the structure:

  • The same set of segments

  • The same arrangement of segments

  • The same properties at the segment and structure levels

The differences among structure instances include whether dynamic combination creation is permitted. Likewise, at the structure instance level, differences among segment instances are based on the following:

  • Value set

  • Default type and default value

  • Tree code

  • Whether the segment is any of the following:

    • Required

    • Displayed

    • Enabled for business intelligence

    • Optional or required as a query criterion

For example, you can use one group of value sets for the US and another for France.

The following figure shows two structures instances for a part number structure.

The figure shows a part number key flexfield that has
multiple possible structures. A given structure has multiple possible
instances. Also, a given structure instance has segment instances
that differentiate it from other structure instances.

The structures differ in the number of segments and the segment separators used. The structure instances share all the properties defined for that structure. However, the structure instances may vary if the properties are defined at the structure instance or segment instance level. For example, the value set assigned to the segment instances.

Query Required Segment Instances

You can designate a key flexfield segment instance as a query for making it a selectively required attribute. A user can use it as a key flexfield combination search. On the Manage Key Flexfields UI page, if you indicate that a segment instance requires indexing, add the column representing the segment to the database index. Commonly, a database administrator (DBA) adds columns to the database index.

Following deployment, the combination picker of the key flexfield displays the query required attributes as selectively required. A user must specify at least one of the query required attributes in the search criteria. This prevents unnecessary searches that could cause performance issues.

For example, you mark the cost center and account attributes as query required and ensure that the corresponding columns in the database are indexed. A user can search for combinations by entering cost center or account or both as search criteria. No search is performed if a user doesn't enter at least one query required attribute as search criteria.

Tip: Index the Structure Instance Number column on your combinations table to improve run time performance.
Dynamic Combinations

If a key flexfield supports dynamic combination creation, you can select to enable this feature by selecting Dynamic Combination Creation Allowed. As a result, users enter values at run time that produce new account combinations for the flexfield. If Dynamic Combination Creation Allowed isn't enabled, new valid combinations can only be entered using the combinations table for the flexfield.

Trees

You may define a tree code for the value set assigned to the segment instance. When you assign the tree code to the segment instance, tree hierarchy search operations are available on the segment values.

For a segment instance to be based on a tree, the following must be true.

  • Application development registered the key flexfield with a tree structure. The tree structure may be fixed across all segments in the flexfield, or may vary across segments.

  • A tree code for that tree structure exists.

  • The tree code includes tree versions containing the values of the value set assigned to the segment instance.

  • You assign the required tree code directly to the segment instance.

If these conditions are satisfied, you can assign the same or different tree codes to the different segment instances that use the same value set.

Cross-Validation Rules

You can control the creation of new key flexfield code combinations by defining cross-validation rules. A cross-validation rule defines validation across segments and enforces whether a value of a particular segment can be combined with specific values of other segments to form a new combination.

The following table compares segment validation to cross-segment validation:

Type of validation Type of control

Segment validation

Controls the values you can enter for a particular segment

Cross-segment validation

Controls the combinations of values that administrators and end users can create for key flexfields

Note: You can use cross-validation rules for any key flexfield that has cross-validation enabled. See the documentation for your key flexfield to determine if it supports cross validation.

Cross-validation rules prevent the creation of combinations with values that can't coexist in the same combination. For example, your company requires that all revenue accounts must have a specific department. Therefore, account combinations that have revenue account values, such as all values between 4000 and 5999, must have a corresponding department value other than 000, which indicates no department is specified. You can define cross-validation rules that disallow creation of combinations with incompatible segments, such as 4100-000 or 5000-000.

Alternatively, suppose your accounting key flexfield has an Organization segment with two possible values, 01 and 02. You also have a Natural Account segment with many possible values, but company policy requires that Organization 01 uses the natural account values 001 to 499 and Organization 02 uses the natural account values 500 to 999. You can create cross-validation rules to ensure that users cannot create a general ledger account with combinations of values such as 02-342 or 01-750.

The following aspects are important to understanding cross-validation rules:

  • Rule Definitions

  • Enforcement

  • Timing

Rule Definitions

The following table contains definitions used in cross-validation rules:

Rule Definition Purpose

Name

Uniquely identifies cross-validation rules in a deployment.

Description

Helps administrators identify the purpose of the rule.

Error message

Explains why the attempted combination violates the rule.

Start Date, End Date

Indicates the period of time when the rule is in effect.

Enabled

Determines whether the rule is enforced.

Condition filter

Determines the conditions in which an enabled cross-validation rule should be evaluated.

Validation filter

Determines the validation that the rule enforces when that condition is met.

When the event specified in the condition filter is applicable, the validation filter condition must be satisfied before the combination can be created. If the event specified in the condition filter isn't applicable, then the combination is considered to pass the rule and the rule won't be evaluated even if it is enabled.

Note: If you don't specify any statement in the condition filter, then the condition is always true and the rule is always evaluated.
Enforcement

Cross-validation prevents creation of invalid combinations by administrators using maintenance pages and end users using dynamic insertion in foreign key pages.

Enabled rules are enforced when there is an attempt to create a new combination of segment values. Disabled rules are ignored. Deleting the rule has the same effect, but you can re-enable a disabled rule.

Timing

When users attempt to create a new combination, the key flexfield evaluates any cross-validation rules that are enabled and in effect.

Note: Cross-validation rules have no effect on combinations that already exist. The flexfield treats any existing invalid combinations that pre-date the rule as valid.

If you want to prevent users from using previously existing combinations that are no longer valid according to your cross-validation rules, manually disable those combinations using the combinations page for that key flexfield.

When defining a cross-validation rule, specify a start and end date to limit the time when the rule is in effect. The rule is valid for the time including the From and To dates.

Considerations for Cross-Validation Rules

To validate the key flexfield combinations of segment values across segments, optimize your cross-validation rules to improve the experience of administrators and users.

Consider the following when defining cross-validation rules:

  • Filters

  • Rule Complexity

  • Maintenance

Filters

A cross-validation rule includes a condition filter and a validation filter. The rule is evaluated using the following logical order: If the condition filter is satisfied, then apply the validation filter.

The condition filter describes the event when the rule is evaluated. If the event specified in the condition filter isn't applicable, then the rule isn't evaluated, even if enabled. When the event specified in the condition filter is applicable, the validation filter condition must be satisfied before the combination can be created.

For example, your organization has determined that a certain company value called Operations can't use a specific cost center called Marketing. You can define a cross-validation rule to validate your combinations.

  1. The rule evaluates the company condition filter.

  2. When company is equal to Operations, the rule evaluates the cost center validation filter.

  3. When cost center is equal to Marketing, the rule prevents a combination from being created.

  4. The error message you defined for the rule displays to inform the user that the attempted combination violates the rule.

Such a rule doesn't affect the creation of combinations with Marketing cost center and company values other than Operations.

Rule Complexity

For optimal performance and ease of understanding, define several simple validation rules instead of using one complex rule. Simple validation rules let you provide a more specific error message and are easier to maintain over time.

Avoid rules that control validation across more than two segments, where possible. While you can define cross-validation rules that span two or more segments, it becomes difficult to interpret cross-validation error messages and rectify invalid key flexfield combinations.

Maintenance

To maintain consistent validation, review existing key flexfields when you update your cross-validation rules. Regardless of your current validation rules, you can use an existing key flexfield combination if it's enabled. Therefore, to ensure accurate validation, you must review your existing combinations and disable any combinations that don't match the criteria of your new rules.

Tip: To keep this type of key flexfield maintenance to a minimum, decide upon your cross-validation rules when you first set up your key flexfield structure. Define cross-validation rules before creating combinations and before combinations are used in transactions.

To prevent users from using existing combinations that are no longer valid according to your cross-validation rules, disable them using the combinations page.

You can use cross-validation rules to determine the valid account combinations that can be dynamically created as users enter transactions or journal entries. Once enabled, a cross-validation rule determines whether a selected value for a particular segment of an account combination can be combined with specific values in other segments to form a new account combination.

For example, your organization has determined that the company Operations can't use the cost center Marketing. You can define a cross-validation rule such that, if the company is Operations, then validate that the cost center isn't Marketing. New account combinations have to satisfy all of the cross-validation rules enabled for the chart of accounts before they can be created.

Entry and Maintenance

You can create cross-validation rules in the Setup and Maintenance work area using the following tasks:

  • Offering: Financials

  • Functional Area: General Ledger

  • Task: Create Cross Validation Rules in Spreadsheet

  • Offering: Financials

  • Functional Area: Financial Reporting Structures

  • Task: Manage Cross-Validations Rules

Use the Create Cross Validation Rules in Spreadsheet task to quickly enter large volumes of rules during implementation. Use the Manage Cross-Validation Rules task to add a one-off rule or to edit existing rules. To edit the error messages for cross-validation rules, use the following task in the Setup and Maintenance work area:

  • Offering: Financials

  • Functional Area: Financial Reporting Structures

  • Task: Manage Messages for General Ledger

Tip: When you export or import cross-validation rules to a new instance using an export or import project in the Functional Setup Manager, you must add the Manage Messages for General Ledger task before the Manage Cross-Validation Rules task. You must export or import the messages before exporting or importing the cross-validation rules.
Existing Account Combinations

If account combinations already exist that violate newly enabled cross-validation rules, those account combinations continue to be valid. Before disabling existing account combinations that violate your rules and that you no longer use, move the balances in those accounts to the correct accounts. Then disable the account combinations manually to prevent further posting. Best practice is to define and enable cross-validation rules before: account combinations are created, transactions or journal entries are imported or entered, balances are loaded.

Considerations for Enabling Key Flexfield Segments for Business Intelligence

A key flexfield registered in the database as enabled for Oracle Business Intelligence (BI) includes a BI Enabled setting for each of its segment instances. When a segment instance is BI-enabled, it's available for use in Oracle Business Intelligence.

The following aspects are important in understanding BI-enabled key flexfield segments.

  • Flattening business components to use BI-enabled segments in Oracle BI

  • Equalizing segments to prevent duplication and complexity in the flattened component

  • Mapping attributes of flattened business components to logical objects in Oracle BI

  • Managing the labels that map segments to logical objects in Oracle BI

After you deploy a business intelligence-enabled flexfield, use the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process to import the flexfield changes into the Oracle Business Intelligence repository. Users can make use of the newly-generated attributes in business intelligence applications. For additional information about logical objects and import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Flattening

When you deploy a business intelligence-enabled key flexfield, the deployment process generates an additional set of flattened business components for use in business intelligence. The flattened business components include attributes for business intelligence-enabled segment instances only.

If you assigned a label to a segment, the flattened components include a single attribute representing all segment instances with that label. If you didn't assign a label, the flattened components include a discrete attribute for each BI-enabled segment instance in each structure.

Mapping to Logical Objects in Business Intelligence

You can simplify reporting by representing similar segments as a single logical object in Business Intelligence. If you assign a label to segments that serve the same purpose in different structures, you can consolidate the segments into a single attribute. This prevents duplication and the extra workload and complexity that result from the flattening process. For example, an organization may have more than one definition of its key accounting flexfield to support different requirements for accounting reporting. A US Accounting Flexfield structure may have a segment called Subaccount to track project expenditures. The same type of information may be tracked in a UK accounting flexfield structure with a segment called Project. Equalize these two segments to create a single list of values for reporting.

Non-labeled segments aren't equalized across context values, so the flattened components include a separate attribute for each segment for each structure. It may not be possible to equalize similarly labeled segments if they have incompatible data types or value set types.

Assign a label to a segment to map the corresponding attribute in the flattened components to a logical object in Oracle Business Intelligence. Using labels to map segments to BI logical objects minimizes the steps for importing the flexfield into Oracle Business Intelligence. Assigning a label to a segment serves to equalize the attribute across structures, as well as map the equalized attribute to business intelligence.

Managing Labels

You may assign a predefined label (if available) to segments or create labels for assignment, as needed. Specify a code, name, and description to identify each label. In the BI Object Name field, enter the name of the logical object in Oracle Business Intelligence to which the segment label should map during import. Specifying the BI logical object minimizes the steps for importing the flexfield into Oracle Business Intelligence and helps to equalize context-sensitive segments across structures.

If no labels are assigned to a BI-enabled segment, or the BI Object Name on the assigned label doesn't exist in business intelligence, you must manually map the segment to the required logical object when importing into Oracle Business Intelligence. In addition, segments without labels cannot be equalized across structures. The flattened components include a separate attribute for each non-labeled segment in each structure.

Importing to Oracle Business Intelligence Repository

After you deploy a business intelligence-enabled flexfield, import the flexfield changes into the Oracle Business Intelligence repository to make use of the newly flattened business components in business intelligence. Then propagate the flexfield object changes. When you import the metadata into the Oracle Business Intelligence repository, you must do so as the FUSION_APPS_BI_APPID user.

To import flexfield changes into the Oracle Business Intelligence repository in Oracle Cloud implementations, run the Import Oracle Fusion Data Extensions for Transactional Business Intelligence process. For additional information about import, refer to the Oracle Transactional Business Intelligence Administrator's Guide.

Note: When you import a flexfield into the Oracle Business Intelligence repository, you see both <name>_ and <name>_c attributes for each segment, along with some other optional attributes. The <name>_ attribute contains the value. The <name>_c attribute contains the code of the value set that the value comes from, and is used for linking to the value dimension. You must import both attributes.

Example of a Key Flexfields

A key flexfield can capture expense account information.

Scenario

When entering details for each expense, the user specifies an account to which the expense is charged.

Entering Expense Accounts

A user interface for entering expenses helps the user select an expense account that identifies the cost center and other details needed for processing the expense.

Analysis

The expense account field is a foreign key reference to a account combination (EXPENSE_LINES.EXPENSE_ACCOUNT = ACCOUNT.COMBINATION).

Account combinations Table for Entering Accounts and Employees

The account combinations table supports entering account information, such as for expense accounts.

The following figure shows the origin in the account combinations table of the account specified by the user. The account combination ID record stores the information of the key flexfield segments used to assemble the expense account based on the key flexfield configuration.

The figure shows the expenses table and the account combinations
table obtaining the account combination ID from the expenses table.
Thereafter, the segment information is passed to the combination details
table in the form of project number. The combined data is projected
as the expense account and all details are supplied to the expense
details user interface, where a user can enter the expense amount
against the expense account.

The combinations page, which is the maintenance page for the key flexfield, is for managing rows in the combinations table. In this example, managing the combinations means adding or editing account numbers that adhere to the key flexfield metadata rules.

The following figure shows the account combination details for the example expense account reflected in the flexfield configuration and the account combinations table.

The figure shows the combination details user interface
where the account combinations table is maintained and the combination
details that result from the account combinations table.

If dynamic combination creation isn't enabled, then when entering an expense line, the user can only select an account that already exists in the ACCOUNTS (combinations) table. If they require an account that doesn't exist, they must consult with the appropriate application administrator who can add the account to the combinations table.

If dynamic combination creation is enabled, then when entering an expense line, the user can either select a preexisting account, or type in a new account that is created dynamically on the fly in the ACCOUNTS (combinations) table. Once the new combination is created, the same user can refer to it on the expense line.

When managing employee information, the user specifies the cost center that the employee belongs to. The cost center field corresponds to a single, labeled segment of the Account Key Flexfield and has metadata defined such as the allowable value set for that segment.

In the following figure, instead of specifying a cost center ID reference to an account, only the cost center segment is used and the value is stored directly on the employee table.

The figure shows the combinations details and how they
appear on the Employee Details user interface.

Attachments

You can use attachments to provide supplementary information to specific business objects. Attachments can be URLs, desktop files, text, or repository folders. For a business object you may view, create, delete, or edit attachments, depending on your role and granted privileges. For more information on attachments, see the Oracle Fusion Applications Developer's Guide.

Repository

Attachments are stored in a content management repository provided by Oracle WebCenter Content Server. Users managing attachments can't interact with the repository unless the repository mode is enabled. When enabled, users can share attachments among objects, update attachments, and perform other tasks. Access to the attachment files is controlled by a digital signing mechanism.

Security

Data security applicable to a specific business object also applies to its attachments For example, if a user has no access to a specific expense report, then that user cannot access its attachments. You can also use attachment categories to control access and actions on attachments, based on roles associated with that category. For more information on securing attachments, see the Oracle Fusion Applications Developer's Guide.

An attachment entity is usually a database entity, for example a table or view, that represents a business object with which attachments can be associated. Each attachment UI must be defined with a corresponding attachment entity. Attachment entities are used only in the context of attachments and exist separately from the database entities that they are based on.

In the Setup and Maintenance work area, use the Manage Attachment Entities task to edit and create attachment entities. You can either use the predefined attachment entities with attachment UIs or create entities, for example when developing your own UIs.

The entity name should match the name of the table or view that represents the business object used for attachment. The name is also used in the repository folder that is automatically created to store attachments for the entity.

The data security policies associated with the database resource defined for the attachment entity apply to attachments for that entity. However, the security setting must be enabled for that entity. The database resource value must match the value in the OBJ_NAME column in the FND_OBJECTS table for the business object that the entity represents.

The association between attachment entities and categories determines the use of categories for an entity. For example, categories associated with the expense report attachment entity are available in the attachment UIs for expense reports. You can configure the associations when managing either entities or categories. Between the Manage Attachment Entities and Manage Attachment Categories pages, any change in association on one page automatically reflects on the other page. You can open either page by starting in the Setup and Maintenance work area and searching for the attachment tasks.

Managing Entities

On the Manage Attachment Entities page, you determine which attachment categories are relevant to a particular entity. Each entity must have at least one category. For a particular expense report page with attachments functionality, you can specify which category to use for the attachment. Accordingly, the data security defined for each category is applied to the attachments on that page if security is enabled.

Managing Categories

If you create an attachment category and must assign it to multiple attachment entities, use the Manage Attachment Categories page. The association is the same as that on the Manage Attachment Entities page.

Attachments Troubleshooting

Attachments UIs are very user-friendly and easy to work with. You may encounter issues in certain cases such as you modify the attachments, for example create additional attachment categories, or implement data security on them.

Issue: Can't View, Add, Update, or Delete Attachments

You may encounter the following issues when trying to view attachments or perform actions such as adding attachments.

  • You can no longer see specific attachments that were earlier visible.

  • You can no longer update or delete attachments.

  • You get an error stating that you do not have permission to add attachments.

Resolution

Use the Manage Attachment Entities page to ensure that attachment categories are associated to the relevant attachment entity. You might need to check with your system administrator or help desk to determine the exact entity used on the page with the expenses attachments or what categories to assign.

If data security is implemented on the categories for the attachment entity, verify that the Enable Security check box is selected in the Manage Attachment Entities page for that entity. Also, make sure that users have a role that has the necessary privileges. The following table lists the privileges required to view, add, update, or delete attachments with a specific attachment category.

Action Privilege

View

Read Application Attachment (FND_READ_APPLICATION_ATTACHMENT_DATA)

Add or Update

Update Application Attachment (FND_UPDATE_APPLICATION_ATTACHMENT_DATA)

Delete

Delete Application Attachment (FND_DELETE_APPLICATION_ATTACHMENT_DATA)

For example, if users have the Read Application Attachment privilege for all categories associated with the expense report attachment entity, except the Receipts attachment category, then they can view all expense report attachments except those created with the Receipts category. Likewise, if users do not have the Update Application Attachment privilege for any attachment categories tied to the expense report attachment entity, then they cannot create any attachments for the expense reports.

For more information on attachment category data security, see the Oracle Fusion Applications Developer's Guide.

Certain attachments UI have predefined restrictions for users on categories. Your developers can also introduce additional filters to determine which document categories are available for a specific page. Check with your developers or help desk.

Issue: Missing Attachment Category

You can view existing attachments but the attachments no longer have an attachment category associated with them.

Resolution

When the attachment was added, at least one category existed for the corresponding attachment entity. Since then, the entity was edited so that it no longer has any assigned categories, so the user cannot see the category associated with that attachment.

Use the Manage Attachment Entities page to reassign attachment categories to the relevant attachment entity. For example, if users can no longer see the Receipts attachment category for an attachment to an expense report, then search for the expense report attachment entity and assign to it the Receipts category. You may need to check with your system administrator or help desk to determine the exact entity used on the page with the expenses attachments or any additional categories to assign.

Certain attachments UI have predefined restrictions for users on categories. Your developers can also introduce additional filters to determine which document categories are available for a specific page. Check with your developers or help desk.

FAQs for Attachments

You must use an attachment category to classify and secure an attachment. While adding attachments, you can view the available attachment categories and add the attachment to one of them. For example, attachments for an expense report can be categorized as receipts, scanned invoice images, and so on.

In the Setup and Maintenance work area, use the Manage Attachment Categories task. You can associate roles with categories to restrict user access and actions for an attachment entity. You can also create and manage categories for your own purpose, involving specific attachments with specific security requirements. For more information on attachment category data security, see the Oracle Fusion Applications Developer's Guide.