Search Results igs_ad_offresp_batch




Overview

IGS_AD_OFFRESP_BATCH is a table within the IGS (Student System) product family of Oracle E-Business Suite, historically available in releases such as 12.1.1 and 12.2.2. The table stores batch-level control and audit information for the "offer response" interface — the mechanism by which external systems or bulk loading processes deposit admission offer response records into the EBS database. Each row in this table represents a single interface batch run and acts as the parent header under which individual offer response interface records are grouped.

The ETRM metadata classifies this table as hub-leaning under a heuristic Data Vault model. In practice this suggests the table functions as a central, relatively stable reference entity — its primary key is referenced by other tables rather than being a purely transactional detail. Treat this classification as a modeling suggestion rather than a hard architectural constraint; it reflects the fact that the table holds a surrogate key (BATCH_ID) that child interface rows depend upon.

Note that this table is documented as obsolete and, in the reference database examined by the ETRM extractor, is not implemented. It should therefore be treated as legacy metadata relevant to historical upgrades, migrations, and code archaeology rather than a target for new development.

Key Information Stored

The table is documented with eleven physical columns. The most important are:

  • BATCH_ID — the surrogate primary key (IGS_AD_OFFRESP_BATCH_PK) and sole business-key candidate via unique index IGS_AD_OFFRESP_BATCH_U1. It uniquely identifies each offer response interface batch and is the column child rows reference.
  • BATCH_DESC — a free-text descriptor for the batch, typically used to label or explain the purpose of a given load.
  • REQUEST_ID — the concurrent request identifier that spawned or is associated with the batch, linking the batch to the Concurrent Manager execution history.
  • PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE — standard Oracle EBS "Who" program-context columns capturing which concurrent program and application created or last touched the batch.
  • CREATED_BY, CREATION_DATE — standard audit columns recording the creating user and timestamp.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns recording the most recent modification and the login session responsible for it.

The surrogate key (BATCH_ID) is distinct from any business key; here the unique index simply enforces uniqueness on the surrogate itself. There is no separate natural/human business identifier documented beyond BATCH_DESC, which is descriptive rather than a guaranteed-unique business key.

Common Use Cases and Queries

Because the table is a batch header for the offer response interface, typical usage centers on reconciling, monitoring, and troubleshooting interface loads. Common scenarios include:

  • Identifying which concurrent request produced a batch and whether it completed successfully, by joining REQUEST_ID to FND_CONCURRENT_REQUESTS.
  • Counting child records per batch to validate load volume, by joining to IGS_AD_OFFRESP_INT on BATCH_ID.
  • Auditing who created or last modified a batch using the standard WHO columns.

A representative reconciliation query pattern:

  • SELECT b.batch_id, b.batch_desc, b.request_id, COUNT(i.batch_id) FROM igs_ad_offresp_batch b LEFT JOIN igs_ad_offresp_int i ON i.batch_id = b.batch_id GROUP BY b.batch_id, b.batch_desc, b.request_id;

Report-writing on this object is only meaningful where the table has been implemented; in databases where it is absent, equivalent batch-tracking data would reside in whatever replacement interface structure was adopted.

Related Objects

The documented relationship metadata identifies one clear dependency:

  • IGS_AD_OFFRESP_INT — the offer response interface detail table. Its BATCH_ID foreign key column references IGS_AD_OFFRESP_BATCH.BATCH_ID, making it the principal child (link/satellite) table. The join column is BATCH_ID on both sides.
  • Indirectly, the REQUEST_ID and PROGRAM_ID columns of IGS_AD_OFFRESP_BATCH relate conceptually to Concurrent Manager objects such as FND_CONCURRENT_REQUESTS and FND_CONCURRENT_PROGRAMS, though these are not documented as declared foreign keys in the supplied metadata.

Because the ETRM extract lists only the single FK relationship above, no further parent or sibling tables can be asserted from the documented facts. Any additional integration points should be verified directly against the application schema before being relied upon in migration or reporting logic.