Search Results fnd_appfldr




Overview
Explore in AI Chat

Overview

FND_APPFLDR is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM object inventory as an "OTHER" API type. Its name derives from "Application Folder," and its function is to provide the low-level database access layer supporting the Oracle EBS Folder Technology framework. Folder Technology allows end users to personalize and save their own tabular layouts — selecting which columns appear, their order, prompt text, and width — without changing the underlying form definition. FND_APPFLDR supplies the programmatic primitives that create, modify, and remove the metadata records underpinning these saved folder definitions.

The package is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2. Its dependency footprint is deliberately minimal: it references only SYS.STANDARD directly, and it is referenced by no other packages in the documented inventory. This narrow dependency profile indicates a leaf-level utility package that is not part of a broader public API chain.

Key Procedures and Functions

The ETRM metadata documents eight callable units in the package. These divide into three functional groups:

  • INSERT_FND_FOLDERS — Inserts a new folder definition header record. This establishes a named, user-owned folder for a given form or block.
  • INSERT_FND_FOLDER_COLUMNS — Inserts the column-level detail rows that belong to a folder definition, capturing which fields are included in the layout.
  • INSERT_FND_DEFAULT_FOLDERS — Inserts default folder configuration, used to seed a folder for users who have not created a personalized version.
  • UPDATE_FND_FOLDERS — Modifies an existing folder header record, supporting subsequent edits to a saved folder definition.
  • DELETE_FND_FOLDERS — Removes a folder header record from the definitions table.
  • DELETE_FND_FOLDER_COLUMNS — Removes the column detail rows associated with a folder, typically executed alongside a folder deletion to avoid orphaned detail records.
  • DELETE_FND_DEFAULT_FOLDERS — Removes default folder configuration records.

The documented procedure list totals seven named units; the eighth entry in the object inventory is the package specification-level construct associated with the body. Parameter lists are not published in the metadata and are therefore not reproduced here.

Tables Accessed

The package operates against five documented tables, all reached through APPS synonyms:

  • FND_FOLDERS and FND_FOLDERS_S — the folder definition header table and its corresponding sequence or shadow table. These store the identity and ownership of each saved folder.
  • FND_FOLDER_COLUMNS — the column-level detail table, holding the per-field attributes of each folder definition.
  • FND_DEFAULT_FOLDERS — the table holding seed or default folder configurations applied when no user-specific folder exists.
  • DUAL — the standard Oracle single-row utility table, typically used for sequence value retrieval or simple expression evaluation within the package body.

The INSERT, UPDATE, and DELETE procedure names map directly to these tables: FND_FOLDERS and FND_FOLDERS_S receive header maintenance, FND_FOLDER_COLUMNS receives detail maintenance, and FND_DEFAULT_FOLDERS receives default configuration maintenance. The pairing of each INSERT with a corresponding DELETE for the column, folder, and default-folder entities reflects a complete maintenance cycle.

Usage Notes

FND_APPFLDR is an internal support package rather than a documented public API. It is normally invoked indirectly — by the Folder Technology runtime in Oracle Forms-based EBS forms when a user saves, renames, or resets a personalized folder, and by administrative utilities or concurrent programs that administer folder definitions in bulk. Because the package is referenced by no other documented packages, custom code should treat it as private implementation rather than as a supported integration point.

Developers who need to manipulate folder definitions programmatically are advised to confirm the current signature and behavior of each procedure against the actual database before use, since the ETRM metadata provides the procedure names and target tables but does not publish parameter contracts. Direct DML against the FND_FOLDERS, FND_FOLDERS_S, FND_FOLDER_COLUMNS, and FND_DEFAULT_FOLDERS tables is strongly discouraged, as it bypasses the validation and sequencing logic encapsulated in these procedures.