Search Results iby_hook_payments_t




Overview
Explore in AI Chat

Overview

IBY_HOOK_PAYMENTS_T is a transient staging table within the Oracle Payments (IBY) module of Oracle E-Business Suite 12.1.1 and 12.2.2. It serves as the structured hand-off buffer between a calling application — most commonly Oracle Payables, but also Receivables, Payroll, or any external feeder system — and the Payment Service Request processing engine. When a calling application submits a payment instruction to the Payments module, it populates this table with the payment attributes, payee information, bank account details, and amounts that the payment process request later consumes. The table is therefore not a permanent ledger of payments, but rather a working table that holds the incoming payload for validation, formatting, and subsequent payment instruction creation.

From a heuristic Data Vault modeling perspective, this object exhibits the characteristics of a link table. Its structure centers on foreign-key references to two principal business entities — the payment service request (PAYMENT_SERVICE_REQUEST_ID) and the external payee (EXT_PAYEE_ID) — and it carries an OBJECT_VERSION_NUMBER and audit columns, which suggest it records transactional relationships rather than descriptive master attributes. The metadata classifies the object as standalone, but the FK evidence points to a relationship-centric role.

Key Information Stored

The most significant columns captured in this table are:

The primary key is generally the surrogate PAYMENT_SERVICE_REQUEST_ID combined with row-level identifiers, while PAYMENT_ID functions as a business-key candidate for downstream reconciliation.

Common Use Cases and Queries

Because this is a staging object, the most frequent queries target rejected or unprocessed rows during payment batch troubleshooting. A typical diagnostic query joins the staging table to IBY_PAY_SERVICE_REQUESTS to see which request generated each row:

  • Rejected payment audit: SELECT p.payment_service_request_id, p.payment_amount, p.dont_pay_reason_code FROM iby_hook_payments_t p WHERE p.dont_pay_flag = 'Y'.
  • Bank account verification: Join to IBY_EXTERNAL_PAYEES_ALL on EXT_PAYEE_ID to confirm the payee's bank account is active before submission.
  • Reconciliation reporting: Aggregate PAYMENT_AMOUNT by PAYMENT_CURRENCY_CODE and ORG_ID to reconcile staged values against the final payment instruction amounts.

Reporting usage typically centers on payment exception dashboards and end-to-end traceability from the feeder application to the payment instruction.

Related Objects

The principal related objects are documented through the FK relationships and product context:

  • IBY_PAY_SERVICE_REQUESTS — Parent request table, joined via PAYMENT_SERVICE_REQUEST_ID.
  • IBY_EXTERNAL_PAYEES_ALL — Payee master, joined via EXT_PAYEE_ID.
  • IBY_PAYMENTS / IBY_PAY_INSTRUCTIONS — Consume the staged payload to create payment instructions.
  • IBY_FD_PAYMENTS — Formatting tables that hold the rendered payment output.
  • HZ_PARTIES and HZ_CUST_ACCOUNT_SITES — Party and site context resolved via PAYEE_PARTY_ID and PARTY_SITE_ID.
  • AP_INVOICES_PAY_SCHEDULES — Originating source for Payables-driven payments.
  • FND_APPLICATION — Resolves CALLING_APP_ID to the feeder application name.

Together these objects complete the payment initialization pipeline from source application through the Oracle Payments engine.