Search Results fnd_dm_functions_pk

Overview

FND_DM_FUNCTIONS is a reference table owned by the APPLSYS schema in Oracle E-Business Suite (validated against 12.1.1 and 12.2.2). It catalogues the document management functions that can be invoked through the Oracle EBS Document Management Open Interface. In practical terms, each row defines a discrete, callable action — such as attaching, retrieving, or updating a document — that external applications, concurrent programs, or integration layer components may trigger against the document management framework. The table therefore acts as the master registry of supported operations rather than a transactional store of document events.

Under the heuristic Data Vault classification mined from its foreign-key structure, FND_DM_FUNCTIONS is hub-leaning. This suggestion aligns with its role as a durable list of business entities (functions), uniquely identified by a stable business key and referenced by downstream child tables. It is not a link table (no composite many-to-many relationships are present) and not a satellite (it does not carry the time-variant descriptive payload typical of one).

Key Information Stored

The table contains seven documented columns. The most significant are:

• FUNCTION_ID — the surrogate primary key, enforced by FND_DM_FUNCTIONS_PK. It is also a business-key candidate via unique index FND_DM_FUNCTIONS_U1.
• FUNCTION_NAME — the human/machine-readable identifier of the document management function. It is the second business-key candidate, enforced by unique index FND_DM_FUNCTIONS_U2.
• SEQUENCE — controls the ordering in which functions are presented or evaluated, supporting predictable display and execution flow.
• NEW_DOCUMENT_FUNCTION — a flag/indicator denoting whether the function applies to newly created documents.
• EXISTING_DOCUMENT_FUNCTION — the counterpart indicator denoting applicability to already-existing documents.
• RESOURCE_NAME — the underlying resource (for example, the programmatic or Java resource) bound to the function.
• ICON_NAME — the icon asset associated with the function in the user interface.

Distinguishing surrogate from business keys matters here: FUNCTION_ID is the technical join key used throughout the child tables, while FUNCTION_NAME is the stable, meaningful identifier that integrations should reference when they cannot rely on the numeric identifier.

Common Use Cases and Queries

Typical scenarios include enumerating the functions exposed by the Open Interface, resolving a function name to its internal ID before inserting parameter metadata, and driving UI rendering of document actions. Sample patterns:

• List all supported functions in presentation order:
  SELECT function_id, function_name, sequence, resource_name FROM fnd_dm_functions ORDER BY sequence;
• Resolve a business key to its surrogate key:
  SELECT function_id FROM fnd_dm_functions WHERE function_name = :p_name;
• Find functions applicable to new versus existing documents for workflow gating.
• Join to parameter definitions to build a complete call signature for an integration (see below).

Reporting use cases center on auditing which document actions are enabled and how they are sequenced, which is useful during upgrades or when documenting integration touchpoints.

Related Objects

The foreign-key relationships reveal the dependent objects that reference this hub:

• FND_DM_FUNCTION_PARAMETERS — references FND_DM_FUNCTIONS.FUNCTION_ID; holds the parameter definitions (call signatures) for each function.
• FND_DM_PRODUCT_FUNCTION_SYNTAX — references FND_DM_FUNCTIONS.FUNCTION_ID; defines product-specific invocation syntax.

These two child tables are the principal consumers of the hub's key, and any query that fully describes a document management operation should join FND_DM_FUNCTIONS to both, using FUNCTION_ID as the common column.