Search Results igs_fi_refund_int_all_pk

Overview

IGS.IGS_FI_REFUND_INT_ALL is a public interface table in the Oracle E-Business Suite IGS (Student Systems / Financial Aid) product schema. Its functional name is "Refunds (Non-Oracle Payables) Transactions Extract." The table stores staged refund voucher records that are exported from Oracle Student Systems to an external, non-Oracle payables system. It does not hold the live transactional refund record; instead it serves as the outbound staging area through which refund data is transferred before being picked up by the external payables process. The object is registered as FND Design Data under IGS.IGS_FI_REFUND_INT_ALL, is scoped public, and has an active lifecycle. Physically it resides in the APPS_TS_TX_DATA tablespace with PCT Free 10, and its unique primary-key index, IGS_FI_REFUND_INT_ALL_PK, resides separately in APPS_TS_TX_IDX.

From a Data Vault modeling perspective, the mined heuristic classification for this object is link. This is a modeling suggestion rather than a physical designation: the table carries foreign-key references to HZ_PARTIES on both PERSON_ID and PAY_PERSON_ID, and its natural role is to associate parties (the refund beneficiary and the payee) with a refund event, which is the characteristic shape of a link table rather than a hub or satellite.

Key Information Stored

The documented schema contains 50 columns. The most significant are summarized below; the surrogate and business keys are distinguished explicitly.

• REFUND_ID (NUMBER 15) — Refund voucher id. This is the mandatory surrogate primary key and the single column of the unique index IGS_FI_REFUND_INT_ALL_PK, making it the only documented unique business-key candidate.
• PERSON_ID (NUMBER 15) — Unique identification of the person associated with the refund; FK to HZ_PARTIES.
• PAY_PERSON_ID (NUMBER 15) — Identifier of the payee of the refund voucher; FK to HZ_PARTIES.
• VOUCHER_DATE (DATE) — Date on which the refund voucher is created.
• REFUND_AMOUNT (NUMBER) — Amount of the refund; the documented rule states the value cannot be zero.
• DR_GL_CCID / CR_GL_CCID (NUMBER 38) — GL account code combination identifiers, populated when Oracle Accounts Receivables is installed.
• DR_ACCOUNT_CD / CR_ACCOUNT_CD (VARCHAR2 40) — Account codes used instead when Oracle Accounts Receivables is not installed.
• FEE_TYPE (VARCHAR2 10) — Fee type used for applying fees and charges.
• FEE_CAL_TYPE (VARCHAR2 10) — Fee calendar type code defining the period in which the fee type operates.
• FEE_CI_SEQUENCE_NUMBER (NUMBER) — Uniquely identifies the calendar instance.
• PAYMENT_NUMBER / PAYMENT_DATE / PAYMENT_MODE — Payment reference, date, and mode for the refund disbursement.
• SOURCE_REFUND_ID / INVOICE_ID — Traceability back to the originating refund and invoice.
• ORG_ID — Multi-org operating unit identifier.
• Standard WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) plus concurrent-program columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE).
• GL_DATE (DATE) — Accounting date carried through to the payables system, alongside 20 generic ATTRIBUTE columns and ATTRIBUTE_CATEGORY for extensibility.

Common Use Cases and Queries

The primary use case is reconciliation and monitoring of the refund extract: confirming which refund vouchers have been staged for the external payables system, and validating key fields before export.

• Extracting staged refunds with party and payment detail:

  SELECT r.refund_id, r.voucher_date, r.person_id, r.pay_person_id,
         r.refund_amount, r.payment_number, r.payment_date, r.payment_mode
  FROM   igs.igs_fi_refund_int_all r
  WHERE  r.org_id = :p_org_id
  AND    r.voucher_date >= :p_from_date;

• Identifying refunds lacking a payment reference, or with zero/undefined amounts — a data-quality check before handoff to the non-Oracle payables system.
• Reconciling accounting distributions by selecting DR_GL_CCID/CR_GL_CCID (Receivables installed) or DR_ACCOUNT_CD/CR_ACCOUNT_CD (Receivables not installed) and joining to GL code combination definitions.
• Auditing the concurrent program that populated the rows using REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID.
• Reconciling the extract against the source refund via SOURCE_REFUND_ID and INVOICE_ID to confirm completeness of the transfer.

Related Objects

The documented foreign-key relationships anchor this table to the Trading Community Architecture party model, and the surrounding refund and payables objects depend on it for extraction.

• HZ_PARTIES — Referenced twice: IGS_FI_REFUND_INT_ALL.PERSON_ID and IGS_FI_REFUND_INT_ALL.PAY_PERSON_ID both join to HZ_PARTIES.PARTY_ID, identifying the refund beneficiary and the payee.
• IGS_FI_REFUND_INT_ALL_PK — The unique index on REFUND_ID in APPS_TS_TX_IDX; the primary access path for single-voucher lookups.
• Oracle Payables interface tables (e.g., AP_INVOICES_INTERFACE / AP_INVOICE_LINES_INTERFACE) — The downstream consumers to which the extract is transferred by the external payables integration.
• General Ledger code combination definitions — Joined through DR_GL_CCID and CR_GL_CCID (or the account-code columns when Receivables is absent) to resolve accounting strings.
• IGS refund and voucher base tables — Linked logically through SOURCE_REFUND_ID and REFUND_ID for pre-extract reconciliation, since these are stored as identifiers rather than enforced foreign keys.
• FND concurrent request objects — FND_CONCURRENT_REQUESTS is joined via REQUEST_ID to attribute each staged row to the program run that created it.