Search Results wsh_interface_errors_u1

Overview

WSH.WSH_INTERFACE_ERRORS is a transactional error-logging table in the Warehouse Management (WSH) schema of Oracle E-Business Suite. It stores the error messages generated when records are processed through the WSH open interface programs — the concurrent processes that load delivery, shipping, trip, and pick-confirm data from staging interface tables into the operational WSH tables. When a row in an interface table fails validation or fails during insertion, the corresponding diagnostic message is written to WSH_INTERFACE_ERRORS, allowing users to review, correct, and resubmit the rejected data.

The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, and its indexes are held in APPS_TS_TX_IDX. Physically it comprises 18 columns. The ETRM dependency data records no foreign-key relationships to other database objects, so the table is heuristically classified as standalone. Under a Data Vault modeling convention this would be treated as a satellite-like diagnostic record — it captures descriptive, time-stamped attributes about processing outcomes rather than serving as a shared hub or link for master or transactional entities. It is referenced by the APPS synonym WSH_INTERFACE_ERRORS.

Key Information Stored

The table is anchored by a single-column surrogate primary key, INTERFACE_ERROR_ID (NUMBER), documented as the primary key for the table. A unique index, WSH_INTERFACE_ERRORS_U1, enforces uniqueness on this same column and therefore represents the documented business-key candidate, though in practice the column is a system-generated identifier rather than a natural business key.

The columns that carry the substantive content are:

• INTERFACE_ERROR_GROUP_ID — groups all errors produced during the same processing cycle for one interface record, enabling a single logical failure to be reviewed as a unit.
• INTERFACE_TABLE_NAME — the name of the interface (staging) table from which the rejected record originated.
• INTERFACE_ID — the primary-key value of the corresponding row in that interface table, linking the error back to its source record.
• MESSAGE_CODE and MESSAGE_NAME — the diagnostic code and short name associated with the failure.
• ERROR_MESSAGE — the full textual context of the error, stored as VARCHAR2(4000).
• INTERFACE_ACTION_CODE — the action the interface was attempting when the error occurred.

The remaining columns are standard Oracle EBS Who columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_BY, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, and REQUEST_ID — which together identify the concurrent request and user that produced the error, supporting audit and traceability.

Common Use Cases and Queries

The principal use case is diagnosing interface failures. Support and functional analysts query the table to retrieve the error text associated with a rejected staging record. A typical lookup by source record is:

SELECT INTERFACE_ERROR_ID, INTERFACE_TABLE_NAME, INTERFACE_ID, MESSAGE_NAME, ERROR_MESSAGE
FROM WSH.WSH_INTERFACE_ERRORS
WHERE INTERFACE_TABLE_NAME = :p_table AND INTERFACE_ID = :p_id;

Grouping by processing cycle supports review of all failures from one concurrent run, using INTERFACE_ERROR_GROUP_ID or REQUEST_ID. Reporting queries frequently count errors by MESSAGE_CODE or MESSAGE_NAME over a date range to identify recurring validation problems, and joins on REQUEST_ID to concurrent request history allow the responsible program and submission time to be established. Error rows are typically purged or archived once the corrected records are successfully resubmitted.

Related Objects

The documented dependency data shows no outbound foreign keys and no inbound references other than the APPS synonym. The most significant related objects are therefore the WSH interface staging tables referenced indirectly through INTERFACE_TABLE_NAME and INTERFACE_ID, together with the concurrent programs that populate the error log. These include the WSH delivery and shipping interface tables, the trip and pick interface tables, and the WSH open interface concurrent programs that read from them. The REQUEST_ID column links the table to FND concurrent request data for run-level analysis. Because the table is standalone, no declarative joins to parent entities exist; relationships are maintained by convention through the table-name and interface-ID pairing rather than by database constraints.