Search Results iby_pay

Overview

IBY_FD_PAYMENTS_V is a public APPS-owned view in Oracle E-Business Suite Release 12.1.1 and 12.2.2 that exposes payment records processed through the Oracle Payments (IBY) funds disbursement infrastructure. The view forms part of the payment extraction and reporting layer used by the Funds Disbursement (FD) extraction generator, and it is the object most frequently referenced when developers and analysts search for "iby_pay" or look for a stable reporting surface over the IBY_PAYMENTS_ALL table. Unlike the base transaction tables, which carry full audit and processing internals, IBY_FD_PAYMENTS_V presents a curated projection of payment attributes suitable for extracts, reconciliation reports, and integration feeds into external treasury or cash management systems. It is defined in the APPS schema and inherits the standard multi-org and audit semantics of the underlying Payment tables.

Underlying Base Objects

The view is defined over the synonym IBY_PAYMENTS_ALL (pointing to the IBY_PAYMENTS table), with secondary access to IBY_PAY_INSTRUCTIONS_ALL and the package IBY_FD_EXTRACT_GEN_PVT. IBY_PAYMENTS_ALL is the primary source: nearly every column projected by the view is drawn directly from that table's payment record, including the payment identifier, status, method, amounts, and the attribute flexfield set. IBY_PAY_INSTRUCTIONS_ALL supplies instruction-level context that links a payment to its instruction and, in turn, to the payment profile and process request. IBY_FD_EXTRACT_GEN_PVT is the extraction generator package that uses the view as part of its processing logic for producing formatted payment files. Because the view is built on the "_ALL" synonym, it is org-striped against ORG_ID and respects the operating unit security model applied to the Payment tables.

Key Columns

The view exposes a broad set of payment attributes. Identification and routing columns include PAYMENT_ID, PAYMENT_SERVICE_REQUEST_ID, PAYMENT_INSTRUCTION_ID, PAYMENT_PROFILE_ID, PAYEE_PARTY_ID, PARTY_SITE_ID, SUPPLIER_SITE_ID, and REMIT_TO_LOCATION_ID. Financial columns comprise PAYMENT_AMOUNT, PAYMENT_CURRENCY_CODE, DECLARATION_AMOUNT, DECLARATION_CURRENCY_CODE, DISCOUNT_AMOUNT_TAKEN, BANK_CHARGE_AMOUNT, and ANTICIPATED_VALUE_DATE. Lifecycle and status columns include PAYMENT_STATUS, PAYMENT_METHOD_CODE, PAYMENT_FUNCTION, PROCESS_TYPE, PAYMENTS_COMPLETE_FLAG, DELIVERY_CHANNEL_CODE, and PREGROUPED_PAYMENT_FLAG. Stop-payment handling is represented in detail through STOP_REQUEST_*, STOP_CONFIRMED_*, and STOP_RELEASED_* column trios, each with date, actor, reason, reference, and flag. Void information is captured via VOIDED_BY, VOID_DATE, and VOID_REASON. Standard audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE) and the ATTRIBUTE_CATEGORY/ATTRIBUTE1-15 descriptive flexfield are also projected, along with ORG_ID, ORG_TYPE, and LEGAL_ENTITY_ID. Remittance narrative is available through REMITTANCE_MESSAGE1 and REMITTANCE_MESSAGE2.

Common Use Cases and Queries

Typical scenarios include payment reconciliation, stop-payment auditing, and building disbursement extracts for banks or treasury systems. A reconciliation query might select PAYMENT_ID, PAYMENT_DATE, PAYMENT_AMOUNT, PAYMENT_CURRENCY_CODE, and PAYMENT_STATUS filtered by ORG_ID and a date range:

• SELECT payment_id, payment_date, payment_amount, payment_currency_code, payment_status FROM apps.iby_fd_payments_v WHERE org_id = :p_org AND payment_date BETWEEN :p_from AND :p_to;
• Stop-payment reporting: filter on STOP_REQUEST_PLACED_FLAG = 'Y' or STOP_CONFIRMED_FLAG = 'Y' to list payments with active or confirmed stops.
• Void tracking: select VOID_DATE, VOID_REASON, and VOIDED_BY for payments where VOID_DATE IS NOT NULL.
• Instruction/profile joins: join PAYMENT_INSTRUCTION_ID or PAYMENT_PROFILE_ID to IBY_PAY_INSTRUCTIONS_ALL or IBY_PAYMENT_PROFILES_ALL for full instrument and profile detail.

Because the view respects ORG_ID inherently, callers should always constrain by operating unit where applicable to avoid cross-org leakage and to leverage the underlying indexes.