Search Results ozf_sd_res_header_intf




Overview
Explore in AI Chat

Overview

OZF_SD_RES_HEADER_INTF is an interface (staging) table in the OZF schema, owned by the Oracle Trade Management module. Its documented purpose is to hold vendor and distributor details sent as part of a response, typically associated with supplier/distributor (SD) response processing and related electronic data interchange (EDI) or XML messaging flows between a buying organization and its trading partners.

The table functions as a transient repository: inbound response documents are loaded into the interface, validated, and then consumed by concurrent programs that populate the production Trade Management and supplier-facing tables before the processed rows are purged or flagged. Because the table stores partner identity, role, address, and business descriptor data in a flat, denormalized form, it supports high-throughput insert operations during batch import without requiring immediate relational integrity checks against the core entities.

Mined from its foreign key structure, the heuristic Data Vault classification for this object is standalone — no parent or child FK relationships are documented. As a modeling suggestion, this places the table outside a classical hub/link/satellite hierarchy; it behaves more like a raw landing table whose natural business keys are captured but not yet resolved into conformed dimensions or links.

Key Information Stored

The table contains 65 documented columns. The most significant are the following.

  • RES_HEADER_INTF_ID — the surrogate primary key, enforced by OZF_SD_RES_HEADER_INTF_PK and also covered by the unique index OZF_SD_RES_HEADER_INTF_U1. It is the sole documented business-key candidate and serves as the record identifier for the interface row.
  • REQDOCID, REQDOCDATETIME, THISDOCGENDTTIME — request document identifier and timestamps identifying the original request and the moment the response document was generated.
  • GLBDOCFUNCCODE — the global document function code that classifies the type of response document being received.
  • SUPP_QUOTE_NUMBER, AUTH_NUMBER, BLANKET_FLAG — commercial reference data such as the supplier quotation number, authorization number, and an indicator of whether the response pertains to a blanket agreement.
  • FROMROLE_* columns — the originator role's identity data, including contact name, email, and telephone (FROMROLE_CINFO_CTNAME, _EMAIL, _TEL_NUMBER), business name and identifiers (FROMROLE_B_BNAME, FROMROLE_P_BUSDESC_GLBBUSID, _GLBSUPPCODE), and address elements (FROMROLE_P_PLOC_ADD1/2/3, _CITY, _REGION, _POSTALCODE, _COUNTRY, _POBOXID).
  • TOROLE_* columns — the equivalent mirrored set describing the destination role (vendor or distributor), including TOROLE_CINFO_CTNAME, TOROLE_CINFO_EMAIL, TOROLE_P_BUSDESC_GLBBUSID, TOROLE_P_GLBPRTCCODE, and the TOROLE_P_PLOC_* location columns.
  • REQUEST_NUMBER, PROCESSED_FLAG, ERROR_TXT — the operational control columns: the originating concurrent request, a status flag indicating whether the row has been consumed, and an error message field populated when validation or processing fails.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the standard Oracle EBS descriptive flexfield columns, allowing clients to extend the interface without schema modification.

Common Use Cases and Queries

The most frequent operational pattern is monitoring inbound processing status. A typical query identifies unprocessed or failed rows for a given request:

SELECT RES_HEADER_INTF_ID, REQDOCID, REQUEST_NUMBER, PROCESSED_FLAG, ERROR_TXT FROM OZF.OZF_SD_RES_HEADER_INTF WHERE PROCESSED_FLAG = 'N' OR ERROR_TXT IS NOT NULL;

Support teams reconcile vendor identity data by extracting the from/to role blocks, for example grouping by TOROLE_P_BUSDESC_GLBSUPPCODE or TOROLE_P_GLBPRTCCODE to count responses per trading partner. Reporting on turnaround times compares REQDOCDATETIME to THISDOCGENDTTIME. Purging strategies typically delete rows where PROCESSED_FLAG = 'Y' and no error is present, after downstream tables have been confirmed populated.

Related Objects

Because the mined relationship data classifies this table as standalone, no formal FK dependencies are documented. In practice it interfaces logically with the following OZF Trade Management and supplier-facing objects:

  • OZF_SD_RES_LINES_INTF — the line-level companion interface table, joined by the header interface identifier.
  • OZF_SD_REQ_HEADER_INTF — the originating request header interface, linked through REQDOCID.
  • The OZF supplier/distributor response base tables — populated by the interface processing concurrent program after validation.
  • FND_CONCURRENT_REQUESTS — joined via REQUEST_NUMBER to trace which batch loaded or consumed the rows.

Implementers should treat the interface as write-mostly and read-rarely, retaining rows only long enough to guarantee successful downstream processing.