Search Results fnd_dm_function_parameters_u2

Overview

APPLSYS.FND_DM_FUNCTION_PARAMETERS is a seed data table within the Oracle E-Business Suite Applications Object Library (FND) schema. It stores the possible parameters accepted by every Document Management (DM) product supported for a given DM function. The table defines the contract between the DM open API and the underlying product implementations: each row describes one parameter that a function accepts, binding a parameter name to the function that owns it. Records are held in the APPS_TS_SEED tablespace with a PCT Free of 25, consistent with its role as a reference rather than transactional data.

Within a Data Vault heuristic classification, this object is satellite-leaning. It is not a pure hub or link; it carries descriptive attributes (the parameter name) that qualify an association between a function and its parameters. Modelers should treat FUNCTION_ID as the parent reference and PARAMETER_NAME as descriptive context, with PARAMETER_ID serving as the synthetic row identifier.

Key Information Stored

The table contains only three documented columns, all of which carry structural meaning:

• PARAMETER_ID (NUMBER) — The surrogate primary key. Enforced by the unique index FND_DM_FUNCTION_PARAMETERS_U1, and by the primary key constraint FND_DM_FUNCTION_PARAMETERS_PK. This identifier is referenced by dependent configuration tables.
• PARAMETER_NAME (VARCHAR2(80)) — The name of the parameter as recognized by the DM open API. Together with FUNCTION_ID it forms the business-key candidate expressed by the composite unique index FND_DM_FUNCTION_PARAMETERS_U2.
• FUNCTION_ID (NUMBER) — Identifier of the DM function to which the parameter belongs. This column is a foreign key to APPLSYS.FND_DM_FUNCTIONS and the second component of the U2 business key.

The distinction between the surrogate key (PARAMETER_ID) and the natural business key (FUNCTION_ID, PARAMETER_NAME) is important: integrations and data migrations should typically resolve parameters by function and name, since the numeric identifier is assignment-generated and environment-specific.

Common Use Cases and Queries

The principal use case is discovery and validation of the DM open API surface. Developers writing to the document management API query this table to confirm which parameters a function accepts before constructing a call. The canonical projection is:

• SELECT PARAMETER_ID, PARAMETER_NAME, FUNCTION_ID FROM APPLSYS.FND_DM_FUNCTION_PARAMETERS;

Common refinements include listing all parameters for a named function, ordering by name, and joining to FND_DM_FUNCTIONS to resolve the function name into a readable report. Reporting patterns frequently join forward to FND_DM_PRODUCT_PARM_SYNTAX on PARAMETER_ID to determine how a parameter maps to a specific DM product's syntax. Data lineage and impact analysis queries, used before patching or upgrading, extract the full parameter inventory to compare against a target release. Diagnostic queries also look up whether a given function/parameter pair exists, which is a direct probe against the U2 unique index and therefore inexpensive.

Related Objects

• FND_DM_FUNCTIONS — Parent table. Joined on FND_DM_FUNCTION_PARAMETERS.FUNCTION_ID = FND_DM_FUNCTIONS.FUNCTION_ID.
• FND_DM_PRODUCT_PARM_SYNTAX — Child table referencing this object via PARAMETER_ID. Used to associate a parameter with a specific product's syntactic representation.
• FND_DM_FUNCTION_PARAMETERS# — The runtime editioning/synonym counterpart that references this table in the APPLSYS schema.
• FND_DM_FUNCTION_PARAMETERS_U1 / _U2 — The two unique indexes in APPS_TS_SEED that enforce the primary key and the function/parameter business key.
• APPLSYS schema — Owner of the object and of the dependencies; the FND design data name is FND.FND_DM_FUNCTION_PARAMETERS.

These relationships confirm the table's position as a configuration reference bridged between the DM function definition and the product-level parameter syntax layer.