Search Results hz_party_interface_errors_pk

Overview

HZ_PARTY_INTERFACE_ERRORS is a Receivables (AR) module table that stores error information generated by the party interface APIs during the processing of records staged in HZ_PARTY_INTERFACE. When bulk party, party site, or account import programs attempt to load records into the TCA (Trading Community Architecture) registry, records that fail validation or business-rule checks are not written to the base entity tables; instead, a diagnostic row describing the failure is written to this table. It therefore functions as the diagnostic and reconciliation layer for inbound party import processing, and is a critical object for troubleshooting failed customer, supplier, and party-site loads.

The Vault classification mined from the foreign-key structure is standalone, and this classification is best understood as a modeling suggestion rather than a hard architectural fact. HZ_PARTY_INTERFACE_ERRORS does not behave as a pure satellite, because its relationship to the interface staging table is not a strict temporal dependency tied to a single parent key at the grain of the error. It carries its own surrogate identifier and qualifies as an independent diagnostic entity. In practice, the most defensible modeling recommendation is to treat it as a link-like diagnostic table hanging off the party interface hub, rather than a satellite of that hub.

Key Information Stored

The table contains eight documented physical columns. The most functionally significant are listed below, with the surrogate key distinguished from business-key candidates.

• INTERFACE_ERROR_ID — the surrogate primary key of the table, enforced by HZ_PARTY_INTERFACE_ERRORS_PK, and also the sole column in unique index HZ_PARTY_INTERFACE_ERRORS_U1. This column is the primary key of the table and serves as the unique identifier referenced throughout error reporting queries. The identifier is system-generated and has no business meaning beyond row uniqueness.
• PARTY_INTERFACE_ID — the foreign key referencing HZ_PARTY_INTERFACE. This column links each error row back to the exact staged record that failed, and is the essential join pathway for diagnosing a specific import failure. It is not a business-key candidate in this table, as a single interface row can generate multiple distinct error rows.
• MESSAGE_TEXT — the free-text diagnostic message produced by the API. This carries the actual error description (for example, validation failures, duplicate detection, or missing mandatory attributes) and is the primary investigative payload of the table.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit columns. These establish who and which login session generated the error, and when. They are also used by the concurrent program processing framework for ownership and traceability of concurrent-manager initiated runs.

Because the single unique index is on the surrogate key only, no natural or composite business key is documented for this object.

Common Use Cases and Queries

The primary use case is resolving failed party interface batches. A typical diagnostic query joins the error table to the interface staging table to surface both the failing record and its message:

• Retrieve all errors for one interface batch, joined on PARTY_INTERFACE_ID, to determine whether failures are isolated or systemic.
• Filter by MESSAGE_TEXT to bucket errors into categories, such as duplicates, missing mandatory attributes, or invalid references, in order to size remediation effort.
• Use CREATION_DATE ranges and CREATED_BY to correlate failures with a specific concurrent request or user session.
• Report on error volumes over time as an operational health metric for inbound party data quality.
• Reference INTERFACE_ERROR_ID directly when the user has only the error identifier and needs to trace back to the failed interface row through PARTY_INTERFACE_ID.
• Purge or archive rows older than a defined retention window after successful remediation.

Related Objects

The significant related objects, based on documented foreign-key and key relationships, are:

• HZ_PARTY_INTERFACE — referenced by HZ_PARTY_INTERFACE_ERRORS.PARTY_INTERFACE_ID. This is the parent staging table and the single inbound foreign-key relationship documented for this object.
• HZ_PARTY_INTERFACE_ERRORS_PK — the primary-key constraint on INTERFACE_ERROR_ID.
• HZ_PARTY_INTERFACE_ERRORS_U1 — the unique index on INTERFACE_ERROR_ID.
• HZ_PARTY_INTERFACE_ERRORS_S and its associated triggers, where present in a given instance, which populate the surrogate key from a sequence.
• The TCA import APIs (for example, the party import and party-site import routines) that populate MESSAGE_TEXT, though these are program units rather than tables.

The table should be regarded as the terminal diagnostic node of the party interface load path, consuming keys from HZ_PARTY_INTERFACE and producing no downstream dependencies of its own.