Results for “bank_charge_amount”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

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:

• PAYMENT_SERVICE_REQUEST_ID — Foreign key to IBY_PAY_SERVICE_REQUESTS; identifies the parent payment service request that owns the payment row.
• PAYMENT_ID — Identifier for the payment instruction generated or referenced during processing.
• CALLING_APP_ID and CALL_APP_PAY_SERVICE_REQ_CODE — Identify the originating application and the code by which that application labels its request.
• PAYMENT_AMOUNT and PAYMENT_CURRENCY_CODE — The monetary value and currency of the payment to be made.
• DISCOUNT_AMOUNT_TAKEN and BANK_CHARGE_AMOUNT — Adjustments applied to the payment value.
• EXT_PAYEE_ID — Foreign key to IBY_EXTERNAL_PAYEES_ALL, identifying the external party receiving funds.
• PAYEE_PARTY_ID, PARTY_SITE_ID, and SUPPLIER_SITE_ID — Ties the payment to the correct party and site records.
• INTERNAL_BANK_ACCOUNT_ID and EXTERNAL_BANK_ACCOUNT_ID — The disbursement bank account on the paying side and the receiving account on the payee side.
• DONT_PAY_FLAG, DONT_PAY_REASON_CODE, and DONT_PAY_DESCRIPTION — Control flags and reasons for suppressing payment, used extensively in validation workflows.
• ORG_ID and ORG_TYPE — Multi-org operating unit context for the transaction.
• OBJECT_VERSION_NUMBER, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard audit and optimistic-locking columns.

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.