Search Results document_description

Overview

POR_ATTACHMENTS_SUMMARY_V is an APPS-owned database view in Oracle E-Business Suite, registered under the ICX (Oracle iProcurement) product and documented with the description "Attachments Summary View." It is a thin presentation layer over the Oracle Foundation attachments infrastructure, exposing a curated subset of attachment metadata so that iProcurement and related purchasing flows can retrieve attachments associated with a given transactional entity without querying the underlying framework tables directly. The view is listed with STATUS = VALID in the ETRM repository for both release 12.1.1 and 12.2.2, and its definition is stored as APPS.POR_ATTACHMENTS_SUMMARY_V in the data dictionary. Because it is a read-only view, it carries no storage of its own; it materializes attachment rows on demand at query time.

Underlying Base Objects

The documented definition of the view selects from a single base object, FND_ATTACHED_DOCS_FORM_VL, which is itself a view within the Oracle Application Object Library (FND) schema. The column list in the view definition maps the base view's columns to aliases consumed by the caller: SEQ_NUM, CATEGORY_DESCRIPTION, DATATYPE_ID, DATATYPE_NAME, DOCUMENT_DESCRIPTION, FUNCTION_NAME, ENTITY_NAME, PK1_VALUE, PK2_VALUE, ATTACHED_DOCUMENT_ID, MEDIA_ID, FILE_NAME, and a trailing space literal. Notably, several source columns are renamed on projection: CATEGORY_DESCRIPTION is surfaced from the base view's TYPE_ID/TYPE family, DOCUMENT_DESCRIPTION from DESCRIPTION, and ATTACHED_DOCUMENT_ID from ATTACHED_DOC_ID. The literal ' ' column produces DCD_NAME in the exposed column list, which is effectively a placeholder and carries no meaningful data. Because the view is defined entirely over FND_ATTACHED_DOCS_FORM_VL, its content is governed by the attachment records maintained through the standard FND attachments forms, with datatype, media, and document category information joined from the attachment framework's own lookup and entity tables.

Key Columns

• SEQ_NUM — Sequence number used to order attachment rows within a query result.
• CATEGORY_DESCRIPTION — Human-readable attachment category (for example, to supplier, to buyer, or to approver) derived from the base view's type information.
• DATATYPE_ID / DATATYPE_NAME — Identifier and name of the attachment datatype (such as file, URL, text, or image), controlling how the attachment is rendered and launched.
• DOCUMENT_DESCRIPTION — Free-text description entered by the user when the attachment was created.
• FUNCTION_NAME / ENTITY_NAME — The FND function and entity that own the attachment, indicating which application form or object the attachment belongs to.
• PK1_VALUE / PK2_VALUE — The primary key values of the owning entity. These columns are the join keys used by callers, including iProcurement, to retrieve only the attachments belonging to a specific requisition, order, or other transactional record.
• ATTACHED_DOCUMENT_ID / MEDIA_ID / FILE_NAME — Internal document identifier, media identifier, and stored file name used to locate and display the attachment content.

Common Use Cases and Queries

The view is typically queried by entity, filtering on FUNCTION_NAME, ENTITY_NAME, PK1_VALUE, and PK2_VALUE to return the attachment set for one business object. A representative query is:

• SELECT seq_num, category_description, datatype_name, document_description, file_name FROM apps.por_attachments_summary_v WHERE function_name = :p_function AND entity_name = :p_entity AND pk1_value = :p_pk1 ORDER BY seq_num;
• iProcurement and purchasing pages use equivalent predicates to render the attachment list on requisition, order, and approval screens.
• Reporting and integration routines join PK1_VALUE and PK2_VALUE back to the owning transaction table to produce attachment registers or migration extracts.

Because the definition is a simple projection over an FND view, response is fast, but all access is subject to the grants and security applied at the underlying FND attachment objects; the view itself should be treated as read-only reference data rather than a maintenance surface.