Search Results igs_as_order_hdr_pkg




Overview
Explore in AI Chat

Overview

IGS_AS_ORDER_HDR_PKG is an Oracle EBS APPS schema PL/SQL package that serves as the table-handling API for the Academic Student (AS) order header entity, part of the Oracle Student System / Enterprise Trading and Records Management (ETRM) product family. In EBS 12.1.1 and 12.2.2 it encapsulates the low-level DML and row-locking logic used to maintain order header records — the top-level document that groups and identifies orders processed by the academic order management flow. By providing a stable, centrally-maintained interface over the IGS_AS_ORDER_HDR tables, the package allows higher-level APIs, forms and concurrent programs to create, update and lock order headers without embedding direct SQL against the base tables.

Key Procedures and Functions

The package exposes eight documented routines. Their names follow Oracle's standard table-handling API conventions, indicating that this is a generated or semi-generated stub layer rather than a business-rule engine.

  • INSERT_ROW — Inserts a new order header row, populating the entity's columns and returning any system-generated identifiers.
  • UPDATE_ROW — Modifies an existing order header, applying the changed attribute values while preserving audit columns.
  • DELETE_ROW — Physically removes an order header record as part of the ordering document's lifecycle or cleanup.
  • LOCK_ROW — Acquires a SELECT ... FOR UPDATE lock on a specific order header, serialising concurrent modification by multiple sessions.
  • ADD_ROW — An alternate insertion entry point, typically invoked where the caller expects the package to manage key derivation.
  • GET_PK_FOR_VALIDATION — Performs a primary-key lookup, returning the entity's key so callers can validate existence before dependent processing.
  • GET_FK_IGS_FI_INV_INT — Retrieves the foreign key relating the order header to the IGS_FI_INV_INT (invoice interface) entity, supporting cross-entity integrity checks.
  • BEFORE_DML — A hook invoked prior to DML operations to enforce standard WHO/audit column population and any pre-write consistency checks.

Tables Accessed

The package operates through APPS synonyms on the following base objects:

  • IGS_AS_ORDER_HDR — The primary order header table holding the live business data for each order. This is the target of INSERT_ROW, ADD_ROW and UPDATE_ROW, the source for GET_PK_FOR_VALIDATION, and the object of the lock in LOCK_ROW.
  • IGS_AS_ORDER_HDR_S — The shadow/complementary table (the "_S" suffix is the Oracle convention for a companion or translated table) used to maintain secondary or language-specific attribute data linked to the header.
  • DUAL — Used for single-row expressions, most likely in key-generation and validation logic where no table access is required.

The foreign-key reference to IGS_FI_INV_INT and the use of FND_API (the Oracle Application Object Library API package) confirm that the package participates in the FI (Financials) invoice interface integration and complies with the standard Oracle API coding standard, including FND_API.G_MISS_*, FND_API.G_RET_STS_* return conventions and STANDARD exception handling.

Usage Notes

IGS_AS_ORDER_HDR_PKG is referenced by four other packages: IGS_AS_DOCUMENTS_API, IGS_AS_DOC_DETAILS_PKG, IGS_AS_PROD_DOC and IGS_AS_SS_DOC_REQUEST. These dependencies show that the package is invoked indirectly through the academic order/document APIs, particularly during document creation, product document processing and self-service document requests, rather than being called directly by end users.

Typical invocation points therefore include:

  • Higher-level ETRM APIs (the four referencing packages) that delegate persistence and locking of the order header to this package.
  • Oracle Forms-based maintenance screens in the Academic Student subsystem, which call the update and lock routines when a user edits an order header.
  • Concurrent programs and custom extensions that need to create or validate order headers programmatically; custom code should call the documented routines rather than INSERT/UPDATE the base tables directly, to preserve the package's BEFORE_DML audit handling and locking semantics.

Because the package is registered as VALID in the APPS schema with API classification OTHER, it functions as an internal building block of the ETRM layer. No direct end-user responsibility is associated with it, and its interface should be treated as governed by the higher-level APIs that consume it.