Search Results adm_action_code




Overview
Explore in AI Chat

Overview

IGS.IGS_SV_BTCH_SUMMARY is a transactional table within the Oracle E-Business Suite 12.1.1 / 12.2.2 environment, owned by the IGS (Student Systems / Student Information) schema. Its documented purpose is to store details about the information included in each batch processed by the IGS Student System batch engine. Each row represents a single item of business information — for example a person, program, financial, or dependent record — that has been captured in a batch and staged for downstream processing.

The object is registered in FND Design Data as IGS.IGS_SV_BTCH_SUMMARY, resides in the APPS_TS_TX_DATA tablespace, and is classified as VALID. Functionally it acts as a staging or staging-adjacent ledger: rather than holding the authoritative business record itself, it records which primary table holds the information, what its primary key value is, and what action is intended against it. This design allows the batch processor to resolve heterogeneous source records through a single uniform structure.

Applying a Data Vault modelling heuristic, the mined foreign key structure classifies this table as a link. It connects two hubs — the batch (IGS_SV_BATCHES) and the party (IGS_PE_HZ_PARTIES) — while also carrying descriptive attributes such as ACTION_CODE and TAG_CODE. This link classification is offered as a modelling suggestion derived from the FK relationships, not as a native EBS concept.

Key Information Stored

The table contains 13 documented columns. The most significant are:

  • SUMMARY_ID (NUMBER, 14) — Surrogate primary key, sequence-generated, enforced by the unique index IGS_SV_BTCH_SUMMARY_PK. This is the only documented business-key candidate.
  • BATCH_ID (NUMBER, 14) — Identifies the batch to which the summary row belongs; foreign key to IGS_SV_BATCHES.
  • PERSON_ID (NUMBER, 15) — The person associated with the staged information; foreign key to IGS_PE_HZ_PARTIES.
  • ACTION_CODE (VARCHAR2, 30) — The intended operation, such as ADD, EDIT, DELETE, or TERMINATE.
  • TAG_CODE (VARCHAR2, 30) — The category of information, such as PERSON, PROGRAM, FINANCIAL, or DEPENDENT.
  • ADM_ACTION_CODE (VARCHAR2, 30) — Indicates whether the record is on HOLD, together with the admission action context.
  • OWNER_TABLE_NAME (VARCHAR2, 30) — Stores the name of the primary table that holds the information being staged.
  • OWNER_TABLE_IDENTIFIER (VARCHAR2, 30) — Stores the primary key value that identifies the information in the staging table, for example a Dependent ID or Employment ID.
  • CREATION_DATE, CREATED_BY, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO audit columns tracking row provenance and change history.

The pairing of OWNER_TABLE_NAME with OWNER_TABLE_IDENTIFIER is the defining characteristic of the object: it provides a generic pointer into any participating source table without requiring a dedicated foreign key per source entity. Three non-unique indexes support access paths: IGS_SV_BTCH_SUMMARY_N1 on (ADM_ACTION_CODE, TAG_CODE), N2 on (PERSON_ID), and N3 on (BATCH_ID, PERSON_ID).

Common Use Cases and Queries

Typical usage centres on batch validation, staging reconciliation, and audit reporting. A common pattern is to retrieve all staged items for a batch, resolved to their underlying person:

  • List all rows for a batch: SELECT * FROM IGS.IGS_SV_BTCH_SUMMARY WHERE BATCH_ID = :p_batch_id;
  • Find held or exception records: SELECT SUMMARY_ID, PERSON_ID, TAG_CODE FROM IGS.IGS_SV_BTCH_SUMMARY WHERE ADM_ACTION_CODE IS NOT NULL;
  • Count staged items by category and action: SELECT TAG_CODE, ACTION_CODE, COUNT(*) FROM IGS.IGS_SV_BTCH_SUMMARY GROUP BY TAG_CODE, ACTION_CODE;
  • Resolve the source record pointer: SELECT OWNER_TABLE_NAME, OWNER_TABLE_IDENTIFIER FROM IGS.IGS_SV_BTCH_SUMMARY WHERE SUMMARY_ID = :p_id;

Because OWNER_TABLE_NAME is not a foreign key, application logic rather than the database enforces valid pointer values; report and interface code should validate the resolved table name before dynamic lookups.

Related Objects

The documented dependency information states that IGS_SV_BTCH_SUMMARY references no database object directly at the object level, but the mined FK structure identifies two parent relationships, and the table is exposed to the APPS layer.

  • IGS.IGS_SV_BATCHES — joined via BATCH_ID to IGS_SV_BTCH_SUMMARY.BATCH_ID; provides batch header context.
  • IGS.IGS_PE_HZ_PARTIES — joined via PERSON_ID to IGS_SV_BTCH_SUMMARY.PERSON_ID; supplies party identity.
  • IGS_SV_BTCH_SUMMARY (APPS synonym/view) — the APPS-layer access point through which concurrent programs and forms read the table.
  • IGS.IGS_SV_BTCH_SUMMARY_PK / _N1 / _N2 / _N3 — the supporting indexes on SUMMARY_ID; (ADM_ACTION_CODE, TAG_CODE); PERSON_ID; and (BATCH_ID, PERSON_ID).
  • Staging tables referenced indirectly through OWNER_TABLE_NAME / OWNER_TABLE_IDENTIFIER — for example dependent or employment staging tables resolved by the pointer columns rather than by a declared foreign key.

Because the object is an IGS-owned staging link table, any extraction or interface that consumes it should be treated as version-sensitive across 12.1.1 and 12.2.2, with column semantics confirmed against the target instance.