Search Results iby_ext_fd_pmt_err_1_0_v




Overview
Explore in AI Chat

Overview

IBY_EXT_FD_PMT_ERR_1_0_V is a public Oracle E-Business Suite database view owned by the APPS schema and defined in the IBY (Payments) product module. It exposes payment-level transaction errors recorded by the Oracle Payments error framework, joining each error to its originating payment record and translating internal lookup codes into user-readable meanings. The view is a fixed-version integration object: the "_1_0_V" suffix identifies it as a versioned extension interface view intended for external consumption, including outbound reporting, extract programs, and third-party or bank-format feeds that must surface payment failure diagnostics.

Because error codes stored in the underlying error table are internal, the view performs the decoding at the database layer by joining to FND_LOOKUPS twice — once for error type and once for error status. This allows downstream consumers to query human-readable values without embedding lookup logic. The view is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2, so its structure and column list remain stable across those releases, which matters for interfaces that depend on a frozen signature.

Underlying Base Objects

Per the documented ETRM metadata, the view is defined over four referenced objects:

The join condition links PMT.PAYMENT_ID to ERR.TRANSACTION_ID, restricted to ERR.TRANSACTION_TYPE = 'PAYMENT'. The error-type lookup is an outer join (FND_ERR_TYPE_LOOKUP(+) with LOOKUP_TYPE(+) = 'IBY_TRANSACTION_ERROR_TYPES'), so payments with an unrecognized or missing type code still return a row with a null meaning. The error-status lookup is an inner join on LOOKUP_TYPE = 'IBY_TRANSACTION_ERROR_STATUSES'.

Key Columns

  • PAYMENT_ID — primary identifier of the payment in IBY_PAYMENTS_ALL. This is the join key to other payment views and tables.
  • TRANSACTION_ERROR_ID — unique identifier of the error row in IBY_TRANSACTION_ERRORS; a single payment may have multiple errors.
  • ERROR_TYPE — internal lookup code classifying the error, validated against IBY_TRANSACTION_ERROR_TYPES.
  • ERROR_TYPE_MEANING — decoded, user-facing meaning of the error type.
  • ERROR_CODE — the specific error or rejection code, often originating from a payment system, bank, or processor response.
  • ERROR_MESSAGE — descriptive text describing the failure, frequently the raw message from the external source.
  • ERROR_DATE — timestamp at which the error was recorded.
  • ERROR_STATUS — internal lookup code for the current status of the error, validated against IBY_TRANSACTION_ERROR_STATUSES.
  • ERROR_STATUS_MEANING — decoded, user-facing meaning of the error status.

Common Use Cases and Queries

Typical scenarios include diagnosing failed payment instructions, building exception dashboards, and feeding rejected-payment details to downstream reconciliation or treasury systems. A basic retrieval for a single payment:

SELECT PAYMENT_ID, TRANSACTION_ERROR_ID, ERROR_TYPE_MEANING, ERROR_CODE, ERROR_MESSAGE, ERROR_DATE, ERROR_STATUS_MEANING FROM APPS.IBY_EXT_FD_PMT_ERR_1_0_V WHERE PAYMENT_ID = :p_payment_id;

To report all currently open payment errors grouped by type and status:

SELECT ERROR_TYPE_MEANING, ERROR_STATUS_MEANING, COUNT(*) FROM APPS.IBY_EXT_FD_PMT_ERR_1_0_V GROUP BY ERROR_TYPE_MEANING, ERROR_STATUS_MEANING ORDER BY 3 DESC;

Because the payment ID is exposed directly, the view is conveniently joined to IBY_PAYMENTS_ALL or payment status views for richer exception reporting. Consumers should be aware that the outer join on error type may return null meanings for unmapped codes, and that visibility depends on the join to FND_LOOKUPS being seeded correctly in each operating unit and language environment.