Search Results ece_attachment_details_u1

Overview

EC.ECE_ATTACHMENT_DETAILS is a temporary staging table in the Oracle E-Business Suite E-Commerce Gateway (ECE) schema. It stores the body content of attachments awaiting extraction, together with the linkage data required to associate each attachment body with its corresponding document header stored in EC.ECE_ATTACHMENT_HEADERS. The table resides in the APPS_TS_INTERFACE tablespace, a location consistent with its role as an interface/staging object rather than a permanent transactional store. In the ECE architecture, the table acts as a transient landing area populated during attachment extraction concurrent programs (identified by RUN_ID) and consumed during the outbound document generation process.

The heuristic Data Vault classification mined from the foreign key structure is standalone. This suggests that, under a Data Vault model, the object would not be treated as a conventional hub, link, or satellite, but rather as an isolated staging structure. This classification reflects the table's dependency-light design: it references only FND_ATTACHED_DOCUMENTS through the ATTACHED_DOCUMENT_ID foreign key, with no other inbound or outbound foreign key constraints documented.

Key Information Stored

The table contains 23 columns. The most significant are described below.

• TRANSACTION_RECORD_ID — A unique identifier linking the transaction base table to its associated extension table. This column is the business-key candidate, enforced by the unique index ECE_ATTACHMENT_DETAILS_U1.
• RUN_ID — The identifier of the extraction run that populated the row. A non-unique index, ECE_ATTACHMENT_DETAILS_N1, exists on this column to support run-scoped queries and purge operations.
• ATT_SEQ_NUM — Attachment sequence number, distinguishing multiple attachments associated with the same transaction record.
• SEGMENT_NUMBER and CONTINUE_FLAG — Together these describe how a large attachment body is chunked across multiple rows. CONTINUE_FLAG signals whether additional segments follow.
• ATTACHMENT_SEGMENT — Holds up to 2000 characters of the attachment body per row, making the table the physical storage location for extracted content.
• ENTITY_NAME and NAME — Identify the entity and the attachment category (for example, a document type or attachment function name).
• PK1_VALUE through PK5_VALUE — Flexible primary key columns that, in combination, uniquely identify the source document to which the attachment belongs.
• ATTACHED_DOCUMENT_ID — Foreign key to FND_ATTACHED_DOCUMENTS, providing the canonical reference to the attachment metadata record in the FND attachment framework.
• Standard Who columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE provide audit and concurrent program context.

No explicit surrogate primary key column is documented; the unique index on TRANSACTION_RECORD_ID serves as the business-key candidate, while the flexible PK1_VALUE–PK5_VALUE set provides the logical document identity.

Common Use Cases and Queries

Typical use cases center on extraction diagnostics, attachment linkage validation, and staging cleanup. A common pattern is to group segments by attachment to reconstruct a body:

• Select all segments for a given attachment ordered by SEGMENT_NUMBER to reassemble content.
• Join to ECE_ATTACHMENT_HEADERS on the shared run and sequence identifiers to pair bodies with headers.
• Filter by RUN_ID to audit a specific extraction run or to purge stale staging rows.
• Join to FND_ATTACHED_DOCUMENTS on ATTACHED_DOCUMENT_ID to confirm the attachment record exists and is active.
• Aggregate by ENTITY_NAME and NAME to report attachment volumes by entity and category.

Example: SELECT TRANSACTION_RECORD_ID, ATT_SEQ_NUM, SEGMENT_NUMBER, ATTACHMENT_SEGMENT FROM EC.ECE_ATTACHMENT_DETAILS WHERE RUN_ID = :run_id ORDER BY ATT_SEQ_NUM, SEGMENT_NUMBER;

Because the table is an interface object in APPS_TS_INTERFACE, reporting should generally target it only during or immediately after an extraction cycle; long-term reporting belongs on the corresponding header or FND tables.

Related Objects

• EC.ECE_ATTACHMENT_HEADERS — The companion staging table holding header-level attachment data; joined to details on run and sequence identifiers.
• FND_ATTACHED_DOCUMENTS — Referenced through ATTACHED_DOCUMENT_ID; the canonical attachment framework table.
• FND_DOCUMENTS — Underlies FND_ATTACHED_DOCUMENTS and holds document-level metadata used to interpret attachment content.
• EC.ECE_ATTACHMENT_DETAILS_U1 — Unique index on TRANSACTION_RECORD_ID, the business-key candidate.
• EC.ECE_ATTACHMENT_DETAILS_N1 — Non-unique index on RUN_ID supporting run-scoped access and purge.
• ECE outbound extraction concurrent programs — The programs whose RUN_ID values populate this table and drive the extraction workflow.

Together these objects form the attachment extraction pipeline within E-Commerce Gateway, with ECE_ATTACHMENT_DETAILS serving as the transient body-storage layer between source documents and the outbound interface.