Search Results init_doc_form
Overview
FND_ATTACHMENT_UTIL_PKG is a foundational Oracle E-Business Suite utility package owned by the APPS schema. It provides the core programmatic services that support the Oracle Attachment Framework, the shared infrastructure through which forms, concurrent programs, and self-service pages associate files, URLs, and text with business entities. In Oracle EBS 12.1.1 and 12.2.2 the package abstracts the complexity of resolving attachment functions, validating document categories, initializing attachment blocks, and maintaining the linkage between an owning entity and its stored documents in FND_ATTACHED_DOCUMENTS and FND_DOCUMENTS.
Its classification in ETRM is OTHER rather than a public API, which reflects its role as an internal utility leveraged heavily across application modules. The dependency information confirms this position: the package is referenced by 24 or more dependent objects, including customer-facing views such as AR_ADJUSTMENTS_V, RA_CUSTOMER_TRX_CM_V, OKL_TRX_HEADER_UV, and WIP_ICX_COMPONENTS_V, as well as contract, order, and service packages including OKC_CONTRACT_PVT, OKS_COPY_CONTRACT_PVT, and FND_WEBATTCH. Any change to this package therefore carries broad regression risk across Financials, Order Management, Service, and Manufacturing.
Key Procedures and Functions
The documented interface exposes eleven procedures and functions:
- GET_ATCHMT_EXISTS — Determines whether attachments already exist for a given entity context, allowing callers to branch logic or display indicators without querying the base tables directly.
- GET_ATCHMT_EXISTS_SQL — Returns a SQL fragment usable for embedding attachment-existence checks within larger queries, typically for views such as the RA_CUSTOMER_TRX and OKL header views listed in the dependencies.
- INIT_ATCHMT — Initializes the attachment context for a transaction or entity, establishing the identifiers required by subsequent attachment operations.
- INIT_FORM — Performs form-level initialization of attachment facilities, used when an Oracle Forms block must support attachments.
- INIT_DOC_FORM — Initializes the document-oriented portion of a form's attachment context, aligning the form with the correct document entity and category.
- GET_ATCHMT_FUNCTION_NAME — Resolves the attachment function name associated with a given form or entity, supporting the FND_ATTACHMENT_FUNCTIONS metadata.
- UPDATE_FILE_METADATA — Maintains the metadata attributes of an attached file, such as descriptive or storage-related properties held in FND_LOBS and FND_DOCUMENTS.
- MERGEATTACHMENTS — Reassigns attachments from a source entity to a target entity during merge processing, notably within Oracle Receivables customer merges.
- GET_USER_FUNCTION_NAME — Returns the user-facing function name associated with an attachment, used for display and navigation purposes.
- MERGECUSTATTACH — Handles customer-specific attachment merge logic, complementing the generic merge routine for HZ and RA customer merge scenarios.
Tables Accessed
The package operates on the core attachment repository tables through APPS synonyms: FND_ATTACHED_DOCUMENTS and FND_DOCUMENTS hold the attachment instances and document definitions; FND_ATTACHMENT_FUNCTIONS and FND_FORM_FUNCTIONS map entities to functions; FND_DOC_CATEGORY_USAGES governs valid category usage; FND_FORM provides form metadata; FND_LOBS stores binary large object content in 12.2.x; and FND_LOOKUP_VALUES supplies reference lookup data. For merge operations it reads RA_CUSTOMER_MERGES, RA_CUSTOMER_MERGE_HEADERS, HZ_CUSTOMER_MERGE_LOG, and HZ_CUSTOMER_MERGE_LOG_S to identify and record the parties involved. Dynamic SQL is executed via DBMS_SQL and PLITBLM.
Usage Notes
FND_ATTACHMENT_UTIL_PKG is invoked indirectly rather than by end users. Oracle Forms attachment blocks call INIT_FORM and INIT_DOC_FORM during block initialization, while views across Receivables, Leasing, Contracts, and WIP use GET_ATCHMT_EXISTS_SQL to expose attachment indicators in query results. Customer merge concurrent programs in Trading Community Architecture and Receivables invoke MERGEATTACHMENTS and MERGECUSTATTACH to preserve and reassign attachments during party consolidation. Custom code should not call this package as a public API; the supported entry point for attachment manipulation is the FND_ATTACHMENT API layer. Direct dependency on this utility risks breakage during patching, and any extension touching attachments should be validated against the dependent objects enumerated in ETRM.