Search Results igs_as_doc_details




Overview
Explore in AI Chat

Overview

The IGS_AS_DOC_DETAILS table is a data object within the Oracle E-Business Suite (EBS) Student System (IGS) module. As indicated by its description, its primary role is to store detailed information about documents associated with a specific order. This table is part of the application's transactional foundation for managing academic service orders and their related documentation. Critically, the ETRM metadata explicitly classifies the IGS - Student System as "Obsolete" and notes that this table was "Not implemented in this database." This indicates that while the table was designed for a specific functional purpose, it was not deployed in the standard EBS 12.1.1 or 12.2.2 instances. Consequently, it is an artifact of the application's data model that is not actively used in production environments.

Key Information Stored

Based on the provided foreign key relationships, the table's structure is designed to link document details to several core entities. The primary key is the ITEM_NUMBER column, uniquely identifying each document record. The table stores foreign keys that establish critical relationships: the ORDER_NUMBER links the document to its parent order header (IGS_AS_ORDER_HDR). The PLAN_ID associates the document with a service plan (IGS_AS_SERVIC_PLAN). The PRODUCED_BY column references the party (HZ_PARTIES) responsible for creating the document. The DELIVERY_METHOD_TYPE defines how the document is transmitted, referencing a lookup (IGS_AS_DOC_DLVY_TYP). Furthermore, the table links to academic calendar instances (IGS_CA_INST_ALL) for key dates via three separate foreign key pairs: enrollment term (ENR_TERM_CAL_TYPE, ENR_CI_SEQUENCE_NUMBER), degree hold (DEGHOLD_CAL_TYPE, DEGHOLD_SEQ_NUM), and final grade (FGRADE_CAL_TYPE, FGRADE_SEQ_NUM).

Common Use Cases and Queries

Given its non-implemented status, there are no active operational use cases for this table in standard EBS deployments. However, analyzing its design reveals its intended purpose. It was architected to support queries for retrieving all documents for a specific service order, tracking documents by their producer, or listing documents based on their delivery method or associated academic calendar periods. A sample analytical query based on its structure might aim to join document details with order and party information, though such SQL would return no data in a standard instance. For example: SELECT d.ITEM_NUMBER, o.ORDER_NUMBER, p.PARTY_NAME FROM IGS_AS_DOC_DETAILS d JOIN IGS_AS_ORDER_HDR o ON d.ORDER_NUMBER = o.ORDER_NUMBER JOIN HZ_PARTIES p ON d.PRODUCED_BY = p.PARTY_ID WHERE d.DELIVERY_METHOD_TYPE = 'ELECTRONIC'; This pattern illustrates how the table was intended to consolidate document metadata for reporting and process tracking.

Related Objects

The ETRM metadata defines clear relationships for IGS_AS_DOC_DETAILS. The table references the following parent tables via foreign keys:

  • IGS_AS_ORDER_HDR via ORDER_NUMBER
  • IGS_AS_SERVIC_PLAN via PLAN_ID
  • HZ_PARTIES via PRODUCED_BY
  • IGS_AS_DOC_DLVY_TYP via DELIVERY_METHOD_TYPE
  • IGS_CA_INST_ALL via three separate column pairs: (ENR_TERM_CAL_TYPE, ENR_CI_SEQUENCE_NUMBER), (DEGHOLD_CAL_TYPE, DEGHOLD_SEQ_NUM), and (FGRADE_CAL_TYPE, FGRADE_SEQ_NUM)
Conversely, one child table references IGS_AS_DOC_DETAILS: This relationship suggests a design where a single document detail record could be associated with multiple duplicate document records.