Search Results iby_hook_docs_in_pmt_t




Overview
Explore in AI Chat

Overview

IBY_HOOK_DOCS_IN_PMT_T is a transactional table in the IBY (Payments) schema of Oracle E-Business Suite, documented as VALID in both release 12.1.1 and 12.2.2. It serves as the staging and holding area through which documents selected for payment are passed into the Oracle Payments payment process. Conceptually, it is the "payment instruction line" table for documents that originate outside the standard Oracle Payables flow — it carries the payable document, the calling application that submitted it, the payee, the payment amount, and the payment-processing controls that the payment engine applies when a payment is built.

Each row represents one payable document submitted for payment, stamped with the ORG_ID and CALLING_APP_ID that identify the business unit and the source application. The table is written by the Payments "hook" interface, in which an external or internal application presents its documents to IBY and IBY drives the payment instruction, formatting, and payment creation.

The ETRM metadata classifies this table heuristically as standalone in the Data Vault sense. From a modeling perspective, it is more naturally treated as a link-style transaction table joining a payment, a payable document, and an external payee, with the CREATED_BY/CREATION_DATE and LAST_UPDATED_BY/LAST_UPDATE_DATE audit columns behaving as satellite attributes. The "standalone" classification simply reflects that the documented FK footprint is narrow.

Key Information Stored

The table exposes 30 documented columns. The most operationally significant are:

The metadata documents no explicit surrogate key column for this table; PAYMENT_ID together with DOCUMENT_PAYABLE_ID behaves as the effective composite business key in practice. The audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) follow the standard EBS WHO-column convention.

Common Use Cases and Queries

The principal use cases are reconciliation of source documents to generated payments, diagnosis of do-not-pay conditions, and source-application auditing.

To reconcile documents to payments for a business unit:

  • SELECT payment_id, document_payable_id, document_amount, document_currency_code, dont_pay_flag FROM iby_hook_docs_in_pmt_t WHERE org_id = :org_id;

To identify documents suppressed from payment:

  • SELECT document_payable_id, dont_pay_reason_code, dont_pay_description, calling_app_id FROM iby_hook_docs_in_pmt_t WHERE dont_pay_flag = 'Y';

To trace a document back to its source, the CALLING_APP_DOC_UNIQUE_REF1–5 columns are joined against the calling application's own tables — for example, invoice identifiers in Oracle Payables. Reporting against this table is typically narrow and grouped by payment, source application, or payee, since the table is transactional rather than analytical in nature.

Related Objects

The documented foreign keys and the payments context point to the following significant related objects:

  • IBY_DOCS_PAYABLE_ALL – master record of payable documents; joined on DOCUMENT_PAYABLE_ID.
  • IBY_EXTERNAL_PAYEES_ALL – payee definitions; joined on EXT_PAYEE_ID.
  • IBY_PAYMENTS_ALL / IBY_PAY_INSTRUCTIONS_ALL – the payment and payment instruction entities reached via PAYMENT_ID.
  • IBY_PAY_PROCESS_PROFILES and the IBY payment process request tables – supply the transaction-type and process attributes referenced by PAY_PROC_TRXN_TYPE_CODE.
  • IBY_PAYMENT_TRXN_LINES and IBY_FD_PAYMENTS – downstream formatted-payment objects that carry the results of processing these hook documents.
  • IBY_DOCUMENT_LINES_ALL – line-level detail underlying the payable document referenced by DOCUMENT_PAYABLE_ID.

These join paths make IBY_HOOK_DOCS_IN_PMT_T the natural starting point when tracing a payment back to the document that prompted it and forward to the payment that discharged it.