Search Results format_value




Overview

IBY_EXT_FD_INS_1_0_V is an Oracle E-Business Suite view owned by the APPS schema within the IBY (Payments) product. It exists in release 12.1.1 and 12.2.2 and carries a status of VALID in the ETRM data dictionary. The name follows the Oracle Payments extract naming convention: the "EXT" segment identifies it as an extract definition, "FD" identifies the Funds Disbursement extract family, "INS" indicates the underlying entity is the payment instruction, and the "1_0" suffix denotes the first versioned layout of the extract interface. The view therefore functions as a denormalized reporting and extraction layer over payment instructions, resolving the many foreign key codes stored on the instruction and profile rows into their human-readable meanings.

Rather than performing the joins repeatedly in custom reports, external payment systems can query this single view to obtain a flattened record per payment instruction, including the grouping rules that were applied when the instruction was created.

Underlying Base Objects

The view is defined over a combination of base tables, synonyms, and lookup views. The driving object is IBY_PAY_INSTRUCTIONS_ALL, which supplies the payment instruction header columns. The extract rules are joined from IBY_INSTR_CREATION_RULES (synonym), which contains the GROUP_BY_* flags. Profile data is taken from IBY_PAYMENT_PROFILES, while the bank account key (BEP_ACCOUNT_ID) is resolved through IBY_BEPKEYS (synonym). Payment formats are described by IBY_FORMATS_VL, bank instruction values by IBY_BANK_INSTRUCTIONS_VL and IBY_PAYMENT_REASONS_VL, and status descriptions by FND_LOOKUPS. Documented dependencies also include CE_LOOKUPS, CE_PAYMENT_DOCUMENTS, CE_SECURITY_PROFILES_GT, FND_GLOBAL, IBY_FD_EXTRACT_GEN_PVT, and IBY_FD_POST_PICP_PROGS_PVT. Joins to the creation rules, the account key, and the bank instruction lookups are outer joins, so instructions without a complete profile or rule configuration are still returned, with nulls in the corresponding columns.

Key Columns

The view exposes the instruction identifier PAYMENT_INSTRUCTION_ID along with PAYMENT_INSTRUCTION_STATUS and its decoded MEANING from FND_LOOKUPS. Settlement attributes include PAYMENT_DATE, PAYMENT_CURRENCY_CODE, PAYMENT_COUNT, and PAYMENT_REASON_CODE, with the last decoded through IBY_PAYMENT_REASONS_VL into MEANING and FORMAT_VALUE. Profile columns include PAYMENT_PROFILE_ID, SYSTEM_PROFILE_CODE, PAYMENT_PROFILE_NAME, PROCESSING_TYPE, and the payment format columns FORMAT_CODE and FORMAT_NAME. Bank routing and identification values are presented through BANK_ASSIGNED_REF_CODE, PAY_ADMIN_ASSIGNED_REF_CODE, BANK_INSTRUCTION1_CODE, and BANK_INSTRUCTION2_CODE, each accompanied by MEANING and FORMAT_VALUE columns from IBY_BANK_INSTRUCTIONS_VL. The grouping controls—GROUP_BY_PAYMENT_DATE, GROUP_BY_PAYMENT_CURRENCY, GROUP_BY_PAY_SERVICE_REQUEST, GROUP_BY_LEGAL_ENTITY, GROUP_BY_ORGANIZATION, and GROUP_BY_PAYMENT_REASON—are sourced from IBY_INSTR_CREATION_RULES and show which criteria the payment process used to bundle payments into instructions. Multi-organization and periodic sequence counters such as PERIODIC_SEQUENCE_NAME_1 through _3 and LAST_USED_NUMBER_1 through _3 are also exposed.

Common Use Cases and Queries

The view is used to reconcile payment instructions sent to a payment system, to audit the grouping behavior of the instruction creation rules, and to feed data extracts to banks or external disbursement engines. The search term "group_by_payment_date" corresponds directly to the GROUP_BY_PAYMENT_DATE column, which is commonly filtered to identify payments batched by payment date. A representative query is:

SELECT payment_instruction_id,
       payment_date,
       payment_currency_code,
       group_by_payment_date,
       group_by_payment_currency,
       payment_profile_name
FROM   apps.iby_ext_fd_ins_1_0_v
WHERE  group_by_payment_date = 'Y'
AND    payment_date >= :p_from_date;

Another frequent pattern joins the view to IBY_PAY_INSTRUCTIONS_ALL on PAYMENT_INSTRUCTION_ID to retrieve additional header detail, or aggregates instructions by payment profile and processing type to measure extract volumes. Because the view includes ORG_ID and LEGAL_ENTITY_ID, queries can be restricted to the operating unit or legal entity under review, and the decoded lookup columns remove the need for further joins to the lookup tables in most reporting scenarios.