Standard Request Submission

Overview of Flexfields and Standard Request Submission

This chapter contains information on how Standard Request Submission interacts with flexfields. It also contains suggestions for designing a report parameter window for your custom reports and integrating flexfields into your report parameters.

For more information on Standard Request Submission, see the Oracle E-Business Suite User's Guide and the Oracle E-Business Suite Setup Guide.

In Oracle Forms-based applications, Standard Request Submission uses a special descriptive flexfield on the Submit Requests window and related windows. This descriptive flexfield provides pop-up windows for users to enter reporting choices such as values they want to report on.

You may want to write a Standard Request Submission report that has several report parameters whose values are chosen by a user at submission time. Since the report parameter pop-up window is a descriptive flexfield, you must set up special descriptive flexfield segments even if your actual report has nothing to do with reporting on flexfield data. These special segments are your report parameters.

Important: Since report parameters are a special type of descriptive flexfield segment, we use the terms "report parameters" and "segments" somewhat interchangeably, especially in descriptions of flexfield setup forms.

While many of the setup steps are similar, such as defining value sets, the Standard Request Submission descriptive flexfield differs from a normal descriptive flexfield in some important ways. The main difference is that you use the Concurrent Programs window to define your segments instead of using the Descriptive Flexfield Segments window. The other differences appear in the ways you define and use value sets, which are often more complex for Standard Request Submission report parameters than they would be for a normal descriptive flexfield.

Warning: You should never change or delete a predefined value set that Oracle E-Business Suite supplies. Such changes may unpredictably affect the behavior of your application features such as reporting.

This section discusses how you set up report parameter segments to pass values to your report using the Submit Requests form. For a discussion of how you should write your actual report program once you have planned your report parameter pop-up window, see the Oracle E-Business Suite Developer's Guide.

Related Topics

Descriptive Flexfield Segments

Planning Your Report Parameters

Using Flexfield Information in Your Report Parameters

Report Parameter Window Planning Diagrams

Planning Your Report Parameters

As with any flexfield, planning how your flexfield pop-up window should look and behave is the most important step. For Standard Request Submission reports, however, this planning is even more important because the arrangement of your parameters in the pop-up window affects the way parameter values or arguments are passed to your report. You should keep this arrangement in mind as you write your report program.

Simplify Passing Argument Values to Your Reports

Using descriptive flexfield segments as report parameters allows you to provide a very user-friendly report submission window while still passing specific values to your reports. You can use report parameters to "translate" from end user-oriented values such as an application name (for example, Oracle Order Entry) to an "ID" value (such as 12345). You can then write your report to use the ID value directly, rather than having to write extra program code to parse the end user terms yourself and translate them to your ID values. You can get most of this information from the Oracle Application Object Library tables, but that involves additional queries and trips to the database tables. You can also avoid the opposite effect using report parameters, that is, you need not force your end users to provide the ID values themselves just to make your program simpler.

Use Hidden Parameters to Simplify End User Report Submission

You can simplify users' report submission by defining hidden parameters and defaulting values users would otherwise need to enter. For example, some reports might use the current date as a parameter. You can set up a hidden report parameter that defaults to the current date, and your users need not enter the date themselves or even see that parameter. Similarly, you could set up a hidden parameter that defaults to the value of a profile option such as the user's set of books or organization ID number. You set up default values and hidden parameters when you define your concurrent program and report parameters using the Concurrent Program windows.

Limit Value Choices Based on Prior Segments

Another way you can simplify users' report submission is by making your parameter values depend on the values of previous parameters. You use the special bind variable $FLEX$ in a value set WHERE clause to make a report parameter depend on a prior report parameter. By carefully planning and defining your value sets, you can make your reports easier to use by presenting only a limited number of appropriate values from which your user can choose. See: Value Set Windows.

Using Flexfield Information in Your Report Parameters

Report Parameter Window Planning Diagrams

Using Flexfield Information in Your Report Parameters

Standard Request Submission lets you use value sets to pass key flexfield values and combinations to your reports. You use "Special" validation type value sets to provide a flexfield-within-a-flexfield. That is, you can define a single report parameter (a descriptive flexfield segment) to pop open a flexfield, such as the Accounting Flexfield, where your user can enter flexfield segment values as reporting criteria.

Report Parameters in Standard Request Submission

the picture is described in the document text

Using a flexfield as a report parameter requires several steps:

Design your report and report parameter window
Determine your flexfield routine calls
Define your special value set
Build your report program
Register your concurrent program and define report parameters

You can also use a flexfield range in your report parameters ("Pair" validation instead of Special validation). All the steps are the same except that you define your flexfield call arguments and your value set slightly differently.

Design Your Report and Report Parameter Window

First you design your report and your report parameter window. You must decide what your report requires as parameters from your user, and how those correlate to the way your user submits your report.

For example, if you are writing a report that provides information related to a specific Accounting Flexfield combination or group of Accounting Flexfield combinations, your report probably requires a code combination ID or a concatenated group of segment values. On the other hand, your user doesn't know the CCID number, and instead would prefer to fill in the usual Accounting Flexfield pop-up window. Since you can use value set mechanisms to translate between displayed end user-oriented values and hidden ID values, as well as to translate between flexfield pop-up windows your user sees and the CCID or concatenated values your report requires, you can design your report and its submission interface to satisfy both needs.

Determine Your Flexfield Routine Calls

Determine the flexfield routine calls you need to pop open and validate the appropriate flexfield. These calls are variations of the flexfield calls you code into a custom application form (POPID(R), VALID(R), and so on). You use special arguments to these routines so that they work within your report parameter window. See: Syntax for Key Flexfield Routines, Special Validation Value Sets.

Define Your Special Value Set

Define your special value set. Note that you define only one value set for your entire flexfield, though that single value set may have more than one flexfield routine call. For example, you might need both a POPID and a VALID call for your flexfield value set. Type in your special flexfield routine calls as functions for the appropriate events in the Special Validation region (same for Pair Validation) of the Define Value Set form. Be sure to type carefully, because it is often difficult to find errors later in the flexfield routine syntax if your report parameter doesn't behave as you expect. See: Value Set Windows.

The maximum size for the value set is 240 characters.

If your value set is a Special or Pair (user-exit validated) value set or has :block.field references, the concurrent program that uses it for parameters can only be used from Forms-based applications.

Build Your Report Program

Build your report program to accept the resulting values that it will receive when a user submits your report. Follow the guidelines for building concurrent programs given in the Oracle E-Business Suite Developer's Guide and the Oracle E-Business Suite Setup Guide.

Register Your Concurrent Program and Define Report Parameters

Register your concurrent program with Oracle E-Business Suite using the Concurrent Programs and Concurrent Program Executable windows, and define your report parameter to use your special value set. Note that you use only one value set per report parameter; one special value set contains the entire flexfield.

In the Concurrent Program Parameters window, ensure that the Required flag is marked if the parameter is required. Check "Enable Security" if you want segment security to be applied to parameters (note that this field is display only if the value set does not have security enabled).

Report Parameter Window Planning Diagrams

The following diagrams can help you plan your report parameter window structures. Add or subtract segments as appropriate for your programs.

For each report, you can list your report parameter prompts, segment values, and value descriptions.

Simple Report Parameter Planning Diagram

the picture is described in the document text

The following diagram can help you plan more complex report parameter setups.

For example, you can list the segment values, whether they are visible or hidden, their prompts, their value descriptions, their value sets, their hidden IDs, and any dependencies on other parameters.

Complex Report Parameter Planning Diagram

the picture is described in the document text