Results for “online_auth_format_code”

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

Overview

IBY_FNDCPT_SYS_CC_PF_B is a Payments (IBY) module table that stores system-level credit card processing profile definitions in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the Funds Capture infrastructure, which governs how payment instruments such as credit cards are authorized, captured, settled, and confirmed against external payment processors. The table functions as the configuration backbone for a given payment system: each row defines which message formats, transmission protocols, and acknowledgement readers are applied to the online authorization, settlement, and query phases of the funds capture lifecycle, together with grouping, limiting, and payer-notification behaviour.

The record is keyed by SYS_CC_PROFILE_CODE, described in the metadata as the primary key. A unique index, IBY_FNDCPT_SYS_CC_PF_SPC_U1 on (SYS_CC_PROFILE_CODE, ZD_EDITION_NAME), indicates that the profile is edition-aware, consistent with the multi-tenant, editioned data model introduced in EBS 12.2. Under the documented Data Vault classification heuristic, the object is modelled as a link: it sits at the junction of independent reference entities — formats, transmission protocols, and acknowledgement readers — holding the keys that connect them rather than the descriptive attributes of those entities themselves. The physical schema documents 52 columns in the IBY schema.

Key Information Stored

The most significant columns fall into three groups. The first is identity and ownership: SYS_CC_PROFILE_CODE (the surrogate primary key that uniquely names the profile) and PAYMENT_SYSTEM_ID, which ties the profile to the payment system it serves. The second group comprises the three-phase communication configuration. For online authorization, the table stores ONLINE_AUTH_FORMAT_CODE, ONLINE_AUTH_TRANS_PRTCL_CODE, and ONLINE_AUTH_ACK_RDR_CODE. For settlement, it stores SETTLEMENT_FORMAT_CODE, SETTLEMENT_TRANS_PRTCL_CODE, SETTLEMENT_ACK_RDR_CODE, and SETTLEMENT_COMPLETE_POINT. For query and reconciliation, it stores QUERY_FORMAT_CODE, QUERY_TRANS_PRTCL_CODE, and QUERY_ACK_RDR_CODE.

The third group governs how captured transactions are aggregated and constrained. GROUP_BY_ORG, GROUP_BY_LEGAL_ENTITY, GROUP_BY_INT_BANK_ACCOUNT, GROUP_BY_SETTLEMENT_CURR, and GROUP_BY_SETTLEMENT_DATE control the batch key structure submitted to the processor, while LIMIT_BY_TOTAL_AMT, LIMIT_BY_AMT_CURR, LIMIT_BY_EXCH_RATE_TYPE, and LIMIT_BY_SETTLEMENT_NUM cap batch composition. Payer notification is controlled through OVERRIDE_PAYER_DELIVERY_FLAG, PAYER_NOTIFICATION_FORMAT, PAYER_NOTIFICATION_DEL_METHOD, AUTOMATIC_PN_SUBMIT_FLAG, PAYER_NOTIFICATION_CONDITION, and PN_COND_NUM_OF_RECEIPTS. Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN), OBJECT_VERSION_NUMBER for optimistic locking, INACTIVE_DATE, ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 for descriptive flexfields, EXCLUDE_TRXN_DET_EXTRACTION, and ZD_EDITION_NAME complete the structure.

Common Use Cases and Queries

Implementation and support teams query this table to diagnose why a card transaction failed authorization, to confirm which settlement format is mapped to a processor, or to audit funds capture configuration across environments. A typical retrieval of the active profile for a payment system is:

• SELECT p.SYS_CC_PROFILE_CODE, p.PAYMENT_SYSTEM_ID, p.ONLINE_AUTH_FORMAT_CODE, p.SETTLEMENT_FORMAT_CODE, p.QUERY_FORMAT_CODE FROM IBY.IBY_FNDCPT_SYS_CC_PF_B p WHERE p.PAYMENT_SYSTEM_ID = :payment_system_id AND (p.INACTIVE_DATE IS NULL OR p.INACTIVE_DATE > SYSDATE);
• Batch grouping and limit settings are commonly extracted for reconciliation reporting, joining to the payment system definition to present the processor name alongside GROUP_BY_* and LIMIT_BY_* flags.
• Impact analysis before disabling a format or acknowledgement reader: query this table by SETTLEMENT_FORMAT_CODE, QUERY_FORMAT_CODE, or PAYER_NOTIFICATION_FORMAT to identify every affected profile.
• Payer notification rule auditing, filtering on AUTOMATIC_PN_SUBMIT_FLAG and PAYER_NOTIFICATION_CONDITION to verify which profiles auto-submit notifications.
• Edition and upgrade investigations using ZD_EDITION_NAME, particularly when comparing 12.1.1 single-edition configurations with 12.2 multi-edition deployments.

Related Objects

The documented foreign keys establish the principal dependencies of this table. IBY_FORMATS_B is referenced three times — through SETTLEMENT_FORMAT_CODE, QUERY_FORMAT_CODE, and PAYER_NOTIFICATION_FORMAT — making it the most heavily depended-upon reference table. IBY_TRANSMIT_PROTOCOLS_B is referenced twice, via SETTLEMENT_TRANS_PRTCL_CODE and QUERY_TRANS_PRTCL_CODE, and IBY_ACK_READERS is likewise referenced twice, through SETTLEMENT_ACK_RDR_CODE and QUERY_ACK_RDR_CODE. Although the metadata does not document a foreign key on PAYMENT_SYSTEM_ID, that column logically associates each profile with the payment system configuration in the IBY module, and it is the most common filter predicate in operational queries. Downstream, funds capture processing, credit card transaction tables, and settlement batch generation routines consume these profile settings at runtime, while the Funds Capture configuration user interface reads and maintains them during setup.