Search Results resp_err_field

Overview

IGF.IGF_SL_ED_PRC_RSLTS is a transaction data table within the Oracle E-Business Suite (EBS) 12.1.1 / 12.2.2 Internet Government Framework (IGF) schema. It stores the edit process results parsed from the response XML file returned by external trading partner systems or validation engines. In the context of Subledger Accounting and the ETRM (Electronic Tax Reporting / Transaction Reporting) integration flows, this table persists the outcome of edit checks applied against response detail records, enabling users and concurrent programs to review which records were accepted, rejected, or flagged by the remote processing authority.

The table resides in the APPS_TS_TX_DATA tablespace and is exposed to the APPS schema through a synonym (APPS.IGF_SL_ED_PRC_RSLTS). From a heuristic Data Vault classification perspective, the structure suggests a link entity: it carries a surrogate primary key (EDIT_REC_ID) yet its functional grain is defined by the foreign key column EDIT_ID, which joins out to multiple response detail tables (IGF_SL_CR_RESP_DTLS, IGF_GR_RESP_DTLS, IGF_SL_AS_RESP_DTLS, IGF_SL_DI_RESP_DTLS, and IGF_SL_DL_RESP_DTLS). This many-target foreign key pattern indicates the table associates edit outcomes across several response source hubs rather than describing a single business entity.

Key Information Stored

• EDIT_REC_ID — Numeric surrogate primary key, enforced by the unique index IGF_SL_ED_PRC_RSLTS_PK. It uniquely identifies each edit result row.
• EDIT_ID — VARCHAR2(100) business-key candidate referencing the primary key of the parent response detail record. This is the principal join column to the response tables.
• LEVEL_CODE — VARCHAR2(30) indicating the level at which the edit was performed (for example, header, line, or detail level).
• RESP_ERR_CODE — VARCHAR2(30) identifying the response error code returned by the external process. This is the column most commonly searched by users investigating edit failures.
• RESP_MSG_TXT — VARCHAR2(150) holding the human-readable response message text associated with the error.
• RESP_ERR_FIELD — VARCHAR2(35) naming the response error field that triggered the edit failure.
• RESP_ERR_VALUE — VARCHAR2(150) capturing the erroneous value returned by the response.
• REPORTED_VALUE — VARCHAR2(150) storing the value originally reported, allowing comparison against RESP_ERR_VALUE.
• Standard Who columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide audit lineage for each row.
• Concurrent program context — PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, and REQUEST_ID link each row to the batch or request that produced the edit results.

Common Use Cases and Queries

The primary use case is diagnostic reporting on edit failures. Investigators search by RESP_ERR_CODE to isolate specific validation exceptions, then join to the response detail tables through EDIT_ID to retrieve the originating transaction. A typical pattern is:

• SELECT EDIT_ID, LEVEL_CODE, RESP_ERR_CODE, RESP_MSG_TXT FROM IGF_SL_ED_PRC_RSLTS WHERE RESP_ERR_CODE = :p_error_code;
• Grouping by RESP_ERR_CODE with a COUNT(*) to produce an error frequency report across a request, filtering on REQUEST_ID.
• Comparing RESP_ERR_VALUE against REPORTED_VALUE to identify reconciliation mismatches.
• Joining to IGF_SL_CR_RESP_DTLS or IGF_GR_RESP_DTLS on EDIT_ID = the response detail primary key to build a full trace from source transaction to error message.

Related Objects

The table is referenced by the APPS synonym APPS.IGF_SL_ED_PRC_RSLTS and maintains foreign key relationships through EDIT_ID to the following response detail tables:

• IGF.IGF_SL_CR_RESP_DTLS — customer/credit response details.
• IGF.IGF_GR_RESP_DTLS — general response details.
• IGF.IGF_SL_AS_RESP_DTLS — assessment response details.
• IGF.IGF_SL_DI_RESP_DTLS — invoice/declaration line response details.
• IGF.IGF_SL_DL_RESP_DTLS — additional declaration line response details.

The metadata also records unresolved foreign key targets (shown as "%"), indicating additional response detail tables participate in the EDIT_ID relationship. Queries should therefore verify the parent table by LEVEL_CODE and request context before assuming a single response source.