Results for “igs_fi_posting_int_all”

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

Overview

IGS_FI_POSTING_INT_ALL is a transaction interface table in the Oracle E-Business Suite Student System (IGS) product family, owned by the IGS schema. Its documented purpose is to consolidate transaction information drawn from three source transaction tables — IGS_FI_CR_ACTIVITIES, IGS_FI_INVLN_INT_ALL, and IGS_FI_APPLICATIONS — so that the rows can be processed for financial posting. The table is explicitly described as an interim staging step: records are gathered here, enriched with debit and credit account information, and then consumed by the downstream posting process that ultimately creates general ledger entries.

Because the table both carries the concatenated transaction detail and serves as the parent for the source rows that reference it, the heuristic Data Vault classification supplied in the metadata is hub-leaning. Treated as a modeling suggestion, this implies IGS_FI_POSTING_INT_ALL behaves like a central entity keyed by POSTING_ID, with the source transaction tables acting as satellites or links that hang off that key. Its column set also contains descriptive and status attributes (batch name, accounting date, amount, status), which is consistent with a hub that carries a modest amount of denormalized context for the posting program. In EBS 12.1.1 the table is documented with 25 columns; the structure is unchanged in 12.2.2.

Key Information Stored

The table defines a surrogate primary key, POSTING_ID, enforced by the IGS_FI_POSTING_INT_ALL_PK constraint and mirrored by the unique index IGS_FI_POSTING_INT_ALL_U1. POSTING_ID is propagated into each of the three source tables, which is what makes it the join spine of the posting process.

• POSTING_ID — surrogate primary key and the business-key candidate; the value that links back to IGS_FI_APPLICATIONS, IGS_FI_CR_ACTIVITIES, and IGS_FI_INVLN_INT_ALL.
• BATCH_NAME — grouping label used to run and reconcile posting batches.
• ACCOUNTING_DATE and TRANSACTION_DATE — the GL accounting date and the originating transaction date, which may differ.
• CURRENCY_CD — currency of the transaction amount.
• AMOUNT — the monetary value to be posted.
• DR_ACCOUNT_CD and CR_ACCOUNT_CD — debit and credit account codes, both foreign-keyed to IGS_FI_ACC_ALL.
• DR_GL_CODE_CCID and CR_GL_CODE_CCID — the resolved GL code combination identifiers used for the actual ledger entry.
• SOURCE_TRANSACTION_ID and SOURCE_TRANSACTION_TYPE — identify the originating record and which of the three source tables it came from.
• STATUS — processing state of the row as it moves through the posting cycle.
• POSTING_CONTROL_ID — foreign key to AR_POSTING_CONTROL, tying the row to the Receivables posting control record.
• ORG_ID — operating unit, supporting multi-org reporting.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE — concurrent program audit trail for the run that created or last touched the row.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS who-columns.

Common Use Cases and Queries

Typical usage is operational and reconciliatory: confirming that all staged rows for a batch were posted, diagnosing rows stuck in a non-final STATUS, or tracing a GL balance back to its student-system origin. A representative query lists unposted rows by batch:

• SELECT posting_id, batch_name, source_transaction_type, amount, status FROM igs_fi_posting_int_all WHERE batch_name = :batch AND status <> 'POSTED' ORDER BY posting_id;
• Tracing a GL entry back to source: filter on DR_GL_CODE_CCID or CR_GL_CODE_CCID, then join SOURCE_TRANSACTION_ID to the originating source table based on SOURCE_TRANSACTION_TYPE.
• Reconciliation of debit versus credit totals per accounting date and currency using SUM(AMOUNT) grouped by ACCOUNTING_DATE and CURRENCY_CD.
• Audit by concurrent request: filter on REQUEST_ID or PROGRAM_ID to see exactly which rows a given posting run produced or modified.

Related Objects

The documented foreign keys make the dependency graph explicit in both directions.

• IGS_FI_APPLICATIONS — references IGS_FI_POSTING_INT_ALL.POSTING_ID; a primary source of application-based transactions.
• IGS_FI_CR_ACTIVITIES — references POSTING_ID; supplies credit activity transactions.
• IGS_FI_INVLN_INT_ALL — references POSTING_ID; supplies invoice line transactions.
• IGS_FI_ACC_ALL — referenced via CR_ACCOUNT_CD and DR_ACCOUNT_CD; the account master validating both sides of the entry.
• AR_POSTING_CONTROL — referenced via POSTING_CONTROL_ID; the Receivables-side posting control record.
• Downstream GL interface objects that consume DR_GL_CODE_CCID and CR_GL_CODE_CCID complete the posting chain from IGS into the general ledger.