Results for “transmission_date”

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

Overview

IBY_PAY_INSTRUCTIONS_H is the history table for payment instructions within the Oracle Payments (IBY) module in Oracle E-Business Suite 12.1.1 and 12.2.2. A payment instruction is the logical grouping that a pay administrator creates to collect a set of payments destined for a single payment process profile, payment format, and transmission configuration. The _H suffix denotes the historical (audit) counterpart of the transactional IBY_PAY_INSTRUCTIONS_ALL table, capturing point-in-time snapshots of each payment instruction as it moves through its lifecycle, from creation through formatting, transmission, and acknowledgement.

Because every row is stamped with a PMT_INSTRUCTION_HISTORY_DATE and points back to its originating instruction through PAYMENT_INSTRUCTION_ID, the table supports full temporal reconstruction of instruction state, which is essential for payment reconciliation, dispute investigation, and regulatory audit. The heuristic Data Vault classification mined from its foreign-key structure is satellite-leaning: the record describes attributes of a business key owned elsewhere, and the primary key is a non-business surrogate rather than a natural key. Modelers treating this as raw material for a Data Vault build would therefore cast it as a satellite attached to a payment-instruction hub/link.

Key Information Stored

The table contains 52 documented columns. The surrogate primary key is PAYMENT_INSTRUCTION_HISTORY_ID (constraint IBY_PAY_INSTRUCTIONS_H_PK), a system-generated identifier with no business meaning. The business-key candidate linking each historical row to the live instruction is PAYMENT_INSTRUCTION_ID, and the snapshot date is PMT_INSTRUCTION_HISTORY_DATE.

• PAYMENT_INSTRUCTION_ID / PAYMENT_INSTRUCTION_NAME — the originating instruction and its user-assigned name.
• PAYMENT_FORMAT_CODE and POSITIVE_PAY_FORMAT_CODE — the payment and positive-pay formats in effect at snapshot time.
• PROCESS_TYPE and PAYMENT_INSTRUCTION_STATUS — whether the run was standard, bill payable, or another process class, and its workflow status.
• BEPID — the payment process profile (IBY_BEPINFO) governing formatting and validation.
• TRANSMIT_CONFIGURATION_ID and TRANSMISSION_DATE / ACKNOWLEDGEMENT_DATE — how and when the file was delivered and confirmed.
• PAYMENT_COUNT, PAYMENTS_COMPLETE_FLAG, REMITTANCE_ADVICE_CREATED_FLAG — completeness and advice-generation state.
• BANK_ASSIGNED_REF_CODE / PAY_ADMIN_ASSIGNED_REF_CODE — reconciliation references.
• LEGAL_ENTITY_ID, PAYMENT_FUNCTION, PRINTER_NAME, PAYMENT_REASON_CODE, SEQUENCE_NUMBER — organisational, printing, and reason context.
• PAYMENT_INSTRUCTION_STATUS together with the CREATED_BY / CREATION_DATE / LAST_UPDATED_BY / LAST_UPDATE_DATE / OBJECT_VERSION_NUMBER audit columns.
• The fifteen ATTRIBUTE / ATTRIBUTE_CATEGORY DFF columns for client extensions.

Common Use Cases and Queries

Typical applications include auditing the progression of a payment instruction, comparing the state at transmission against current state, and reporting on bank acknowledgement lag. A representative query retrieves the latest snapshot per instruction:

SELECT h.payment_instruction_id,
       h.payment_instruction_name,
       h.payment_instruction_status,
       h.transmission_date,
       h.acknowledgement_date
FROM   iby_pay_instructions_h h
WHERE  h.pmt_instruction_history_date =
       (SELECT MAX(x.pmt_instruction_history_date)
        FROM   iby_pay_instructions_h x
        WHERE  x.payment_instruction_id = h.payment_instruction_id);

Joining to IBY_PAYMENTS_H on PAYMENT_INSTRUCTION_HISTORY_ID reconstructs the individual payments contained in each historical instruction, supporting settlement analysis and unclaimed-property reporting.

Related Objects

• IBY_PAYMENTS_H — references this table via PAYMENT_INSTRUCTION_HISTORY_ID; the child payment history records for each instruction snapshot.
• IBY_PAY_INSTRUCTIONS_ALL — the transactional (non-historical) parent, joined on PAYMENT_INSTRUCTION_ID.
• IBY_BEPINFO — payment process profiles, joined on BEPID.
• IBY_FORMATS_B — referenced twice, via PAYMENT_FORMAT_CODE and POSITIVE_PAY_FORMAT_CODE.
• IBY_TRANSMIT_CONFIGS_B — transmission configuration, joined on TRANSMIT_CONFIGURATION_ID.
• IBY_PAYMENT_REASONS_B — reason codes, joined on PAYMENT_REASON_CODE.
• FV_LEGAL_ENTITIES — legal entity, joined on LEGAL_ENTITY_ID.

Oracle Payments concurrent programs and the standard payment dashboards consume this table indirectly; direct DBA queries should be read-only, as the table is maintained exclusively by the application's history-archiving logic.