Search Results fnd_dm_function_parameters




Overview
Explore in AI Chat

Overview

The FND_DM_FUNCTION_PARAMETERS table is a dictionary object within the Oracle E-Business Suite Application Object Library (FND) schema, owned by APPLSYS. It stores the parameter definitions associated with document management system functions, forming part of the Oracle EBS Document Management (DM) infrastructure that governs document cataloging, access, and retrieval behavior. Each row defines a single named parameter belonging to a document management function, thereby describing how a given function is configured or invoked at runtime.

The table occupies a supporting position within the FND_DM data model. Its foreign key relationship to FND_DM_FUNCTIONS establishes that every parameter row must belong to a parent function, while the reciprocal relationship from FND_DM_PRODUCT_PARM_SYNTAX indicates that parameter rows are further extended by product-specific syntax definitions. In Data Vault modeling terms, the mined relationship structure classifies this object as satellite-leaning: it carries descriptive attributes that depend on a parent business entity (the function) rather than acting as an independent hub or an associative link. This classification is a heuristic suggestion derived from the foreign key topology and should be validated against the specific modeling requirements of any downstream data warehouse implementation.

Key Information Stored

The documented physical schema for Release 12.2.2 contains three columns. The most significant are:

  • PARAMETER_ID — The surrogate primary key, enforced by the FND_DM_FUNCTION_PARAMETERS_PK constraint and additionally protected by the unique index FND_DM_FUNCTION_PARAMETERS_U1. This numeric identifier uniquely distinguishes each parameter definition across the entire table.
  • PARAMETER_NAME — The business-facing name of the parameter. Together with FUNCTION_ID, it forms the composite business key enforced by the unique index FND_DM_FUNCTION_PARAMETERS_U2, ensuring that parameter names are unique within the scope of a single function.
  • FUNCTION_ID — The foreign key to FND_DM_FUNCTIONS, identifying the document management function to which the parameter belongs. This column anchors the table to its parent entity and is the primary join predicate for function-level reporting.

The distinction between the surrogate key (PARAMETER_ID) and the business-key candidate (FUNCTION_ID plus PARAMETER_NAME) is important for integration work: external systems should generally resolve parameters using the composite natural key rather than relying on surrogate values, which may differ between environments.

Common Use Cases and Queries

Typical usage centers on introspection of document management configuration — identifying which parameters are available for a given function, validating setup during implementations or upgrades, and reporting on the parameter inventory across functions. A representative query joining the table to its parent function is:

  • SELECT p.parameter_id, p.parameter_name, p.function_id FROM applsys.fnd_dm_function_parameters p WHERE p.function_id = :function_id ORDER BY p.parameter_name;
  • SELECT f.function_name, p.parameter_name FROM applsys.fnd_dm_functions f, applsys.fnd_dm_function_parameters p WHERE f.function_id = p.function_id ORDER BY f.function_name, p.parameter_name;
  • Locating syntax definitions for a parameter: SELECT s.* FROM applsys.fnd_dm_product_parm_syntax s WHERE s.parameter_id = :parameter_id;

These patterns are useful during impact analysis before patching document management components, and in migration scripts that must confirm parameter parity between source and target instances.

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; joined on FND_DM_PRODUCT_PARM_SYNTAX.PARAMETER_ID = FND_DM_FUNCTION_PARAMETERS.PARAMETER_ID.
  • FND_DM_FUNCTION_PARAMETERS_PK / _U1 / _U2 — The primary key and unique index constraints that enforce row identity and business-key uniqueness.
  • FND_DM_NODES and related FND_DM configuration tables — Sibling objects in the Document Management schema that share the same APPLSYS ownership and are frequently queried together when auditing DM setup.
  • FND_DM_FUNCTIONS-based function registration APIs — Dictionary-driven components that read parameter metadata to drive runtime behavior of document management functions.

Because the table is small and dictionary-oriented, it is generally read-only in production and should be queried directly rather than through DML, with all changes applied through supported Oracle EBS setup or patching mechanisms.