Search Results igs_or_gen_012_pkg




Overview

IGS_OR_GEN_012_PKG is a general-purpose PL/SQL package in the APPS schema belonging to the Oracle E-Business Suite footprint historically associated with Oracle Student System / Higher Education (the IGS_ product family), and it remains a shipped, VALID object in EBS 12.1.1 and 12.2.2. Its core responsibility is the creation and maintenance of "organizations" as understood by the student-information model, plus the delivery of dynamic WHERE-clause fragments used to restrict queries against those organizations. The package therefore sits between the organization data model and the many consuming modules — admissions, prospect/recruitment, registration, placement and legacy validation routines — that need to search for, filter, and persist organization records.

The package is classified as OTHER in the ETRM metadata rather than as a public API, indicating that it is an internal utility layer. Its widely shared nature is confirmed by the dependency report: it depends on FND_LOOKUP_VALUES and STANDARD, and is referenced by six other packages (IGS_AD_IMP_026, IGS_OR_GEN_001, IGS_OR_INST_IMP_002, IGS_PR_PROUT_LGCY_PUB, IGS_PS_VALIDATE_LGCY_PKG and IGS_RE_SPRVSR_LGCY_PUB), spanning admissions import, organization, institution import, prospect legacy, validation and supervisor legacy processing.

Key Procedures and Functions

Seven documented program units are exposed:

  • CREATE_ORGANIZATION — inserts a new organization record, applying the package's validation and defaulting rules before persistence.
  • UPDATE_ORGANIZATION — modifies an existing organization record, re-applying the same validation and defaulting logic.
  • GET_WHERE_CLAUSE — returns a dynamically constructed SQL WHERE fragment used to filter an organization query.
  • GET_WHERE_CLAUSE_FORM — variant of the WHERE-clause generator tailored to the Forms (client-side) context.
  • GET_WHERE_CLAUSE_API — variant intended for programmatic/API invocation rather than interactive Forms use.
  • GET_WHERE_CLAUSE_FORM1 — a further Forms-oriented overload/variant of the filter builder.
  • GET_WHERE_CLAUSE_API1 — a further API-oriented overload/variant of the filter builder.

The repeated GET_WHERE_CLAUSE* naming pattern indicates that the filtering logic is centralised in this one package and parameterised by calling context (Forms versus API) and by variant (suffix 1 versus unsuffixed). Parameter signatures are not documented in the ETRM extract and should be confirmed against the shipped package header.

Tables Accessed

The documented table references are:

  • FND_LOOKUP_VALUES — the standard Oracle Application Object Library lookup table, consulted to resolve lookup codes (statuses, types, categories) into their meanings and to drive valid-list filtering within the WHERE-clause logic.
  • HZ_PARTIES — the Trading Community Architecture party table, used to associate the IGS organization with its underlying party record and to support party-based filtering and validation.
  • IGS_OR_FUNC_FLTR — the IGS organization function filter table, which stores the filter definitions that the GET_WHERE_CLAUSE* functions translate into runtime predicates.

Usage Notes

IGS_OR_GEN_012_PKG is not normally called directly by end users. Instead it is invoked from the six dependent packages listed above, which cover organization maintenance (IGS_OR_GEN_001), admissions and institution imports (IGS_AD_IMP_026, IGS_OR_INST_IMP_002), prospect legacy processing (IGS_PR_PROUT_LGCY_PUB) and legacy validation/supervisor logic (IGS_PS_VALIDATE_LGCY_PKG, IGS_RE_SPRVSR_LGCY_PUB). Typically this means the package is exercised during concurrent-program imports, validation batches and form-driven organization maintenance.

Because the package is a shared internal utility rather than a public API, customisations should avoid calling it directly and should instead use the documented public APIs of the dependent packages. Where custom code must reference it, the GET_WHERE_CLAUSE_FORM variant should be used from Forms-based extensions and GET_WHERE_CLAUSE_API from PL/SQL or concurrent processing, matching the package's own contextual split. As with all seeded APPS code, any change should be made by wrapping rather than modifying the shipped package body, since the object status is VALID and is expected to remain untouched by patching.