Search Results iby_result_codes_u1

Overview

IBY.IBY_RESULT_CODES is a reference (lookup) table in the Oracle Payments (IBY) schema. It stores the standardized result codes returned by the public payment APIs — the internal interfaces exposed to callers such as Payables, Receivables, and Payroll — and maps each code to a request interface, a general result category, and an Oracle Application Object Library (FND) message name. Because every IBY public API returns one of these codes in its out parameter, the table functions as the semantic dictionary of payment processing outcomes: success, warning, business failure, and system error. Consultants and developers use it to interpret API responses, to drive conditional branching after a payment call, and to translate cryptic codes into user-facing messages.

The table resides in the APPS_TS_TX_DATA tablespace, and its status is VALID across Oracle EBS 12.1.1 and 12.2.2. In the 12.2.2 documented schema it contains 11 columns. The heuristic Data Vault classification mined from its foreign-key structure is standalone; as a modeling suggestion this means the object is best treated as a single reference (hub-like) table with no subordinate link or satellite decomposition, since it carries no outbound relationships and is not broken out into dependent structures.

Key Information Stored

The most significant columns, drawn from the documented schema, are:

• RESULT_CODE (VARCHAR2 30) — the API result code itself; the value returned by an IBY public interface.
• REQUEST_INTERFACE_CODE (VARCHAR2 30) — identifies the public interface to which the result code belongs, scoping each code to its owning API.
• RESULT_CATEGORY (VARCHAR2 30) — the general category of the API result, the attribute most often used for programmatic branching.
• MESSAGE_NAME (VARCHAR2 30) — the FND message code used to render the result as a translatable, user-facing message.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Who columns providing audit lineage.
• OBJECT_VERSION_NUMBER — the standard optimistic-locking version counter.
• ZD_EDITION_NAME — the editioning column introduced by the 12.2 online patching (ADOP) architecture; it is present in the documented 12.2.2 schema and forms part of the unique index IBY_RESULT_CODES_U1.

Two business-key candidates are documented. The primary key is defined as IBY_RESULT_CODES_UK over (REQUEST_INTERFACE_CODE, RESULT_CODE), and the unique index IBY_RESULT_CODES_U1 covers (REQUEST_INTERFACE_CODE, RESULT_CODE, ZD_EDITION_NAME). The latter is the edition-aware unique index: because 12.2 edition-based redefinition requires uniqueness to hold within an edition, ZD_EDITION_NAME is appended to the 12.1 key columns. Consequently, in 12.2.2 any query that must return exactly one row per logical code should either include ZD_EDITION_NAME in the predicate or filter to the current edition.

Common Use Cases and Queries

The most frequent scenario is resolving an API return code to its category and message. A typical pattern joins IBY_RESULT_CODES to FND_MESSAGES on MESSAGE_NAME = FND_MESSAGES.MESSAGE_NAME to obtain display text:

• Diagnosing a failed payment: filter by the REQUEST_INTERFACE_CODE of the called interface and order or group by RESULT_CATEGORY to distinguish business exceptions from system errors.
• Validating supported codes: confirm that a given (REQUEST_INTERFACE_CODE, RESULT_CODE) pair exists before interpreting an API response, guarding against hard-coded assumptions.
• Building exception reports: aggregate counts of results per interface and category to trend processing failures.
• Confirming which interfaces and codes are affected in a given edition following an online patch cycle.

The query text documented in the ETRM metadata selects all columns from IBY.IBY_RESULT_CODES; that form is convenient for ad hoc inspection, while production code should project only RESULT_CODE, REQUEST_INTERFACE_CODE, RESULT_CATEGORY, and MESSAGE_NAME.

Related Objects

Per the documented dependency information, IBY.IBY_RESULT_CODES does not reference any database object — it has no outbound foreign keys, consistent with its standalone classification. It is referenced by an APPS synonym, APPS.IBY_RESULT_CODES, which is the name used by application code. Significant related objects, joined on the documented columns, include:

• APPS.IBY_RESULT_CODES — the synonym through which callers access the table.
• FND_MESSAGES — joined on MESSAGE_NAME = FND_MESSAGES.MESSAGE_NAME to resolve translatable message text.
• FND_MESSAGE_TRANSLATIONS — joined on the same message name plus language, to obtain locale-specific text.
• The IBY public interface packages (for example IBY_PAYMENT and IBY_FD_PAYMENT-related APIs) that return RESULT_CODE values documented here.
• Calling application modules such as AP and AR that consume these codes when they invoke IBY public APIs.

Because the table is reference data shipped by Oracle, it should be treated as read-only in customizations; extensions are properly implemented through FND message personalization rather than direct inserts.