Search Results iby_payment_profiles




Overview
Explore in AI Chat

Overview

IBY_PAYMENT_PROFILES is a PL/SQL view owned by the APPS schema within the Oracle Payments (IBY) product family in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It presents a consolidated, reportable representation of payment profiles, joining system-level payment profile definitions with account-level profile assignments. The view gives functional consultants, developers, and reporting tools a single denormalized access point to the configuration that drives how payments are formatted, secured, transmitted, and acknowledged.

Because payment processing is highly configurable, downstream objects such as payment instructions, payment files, and transmission records depend on the profile settings surfaced here. The view therefore plays a central role in reporting and integration: it is used to audit profile configuration, support custom extracts to banking partners, and provide the profile context required by outbound interfaces that reformat or route payment data. The view is listed as VALID and is identified in ETRM as a reporting-facing object rather than a base table, meaning it is intended for query access and not for direct DML.

Underlying Base Objects

The documented base objects referenced by IBY_PAYMENT_PROFILES in 12.2.2 are two views: IBY_SYS_PMT_PROFILES_VL and IBY_ACCT_PMT_PROFILES_VL. These are the system payment profile and account payment profile views respectively. The view text joins them through aliases S (system) and A (account), matching system profile definitions to the account-specific payment profile rows that reference them.

The join is effectively a left outer style relationship driven by the BEPID, where system-level attributes (security protocol, transmit protocol, payment format, declaration options, and so on) are combined with account-level identifiers (PAYMENT_PROFILE_ID, PAYMENT_PROFILE_NAME, BEP_ACCOUNT_ID, security and transmit configuration identifiers, and sequence numbering columns). Notably, the view applies a DECODE on INACTIVE_DATE to select the later applicable inactivity date from the system and account profiles, ensuring that an account profile is treated as inactive if either the system or account definition is inactive.

Key Columns

Common Use Cases and Queries

Typical uses include auditing profile configuration prior to payment runs, identifying profiles that share a payment format or transmission protocol, and extracting profile metadata for reconciliation and SOX reporting. A common query lists active account profiles with their system profile names:

SELECT payment_profile_id,
       payment_profile_name,
       system_profile_code,
       payment_format_code,
       transmit_protocol_code
FROM   apps.iby_payment_profiles
WHERE  inactive_date IS NULL;

A second pattern filters by payment system (BEPID) to confirm protocol and security settings before transmission, and a third extracts numbering sequences to verify that LAST_USED_NUMBER values are within expected ranges. Because the object is a view, all queries should be run in a reporting or read-only context, and callers should be aware that the effective inactivity date is computed rather than stored, so any comparison against SYSDATE must use the derived INACTIVE_DATE column rather than a base table column.