Search Results igs_personstats_pub




Overview
Explore in AI Chat

Overview

IGS_PERSONSTATS_PUB is a public PL/SQL API package in the APPS schema that belongs to the Oracle Student System (formerly Oracle iStrategy / Oracle Higher Education) product family. Its role is to maintain and recompute "person statistics" — aggregated attributes that describe a person's involvement with the institution, such as their status as a student, applicant, or prospect. The package exposes a public API surface intended for external callers (forms, concurrent programs, and custom extensions), while internally it enforces the standard Oracle E-Business Suite API discipline: initialisation of the global API context, use of the message stack, and consistent error propagation via FND_MSG_PUB and FND_API.

The package body is marked VALID in the APPS schema across EBS 12.1.1 and 12.2.2. It is implemented as a "PUB" (published) API, meaning the procedures are designed to be called programmatically rather than executed ad hoc. The package is not referenced by any other database object, confirming it is a top-level entry point whose consumers are external (application forms, concurrent request definitions, or customer-written code) rather than server-side PL/SQL dependencies.

Key Procedures and Functions

The ETRM metadata documents a single public procedure for this package body:

  • REDERIVE_PERSON_STATS — This is the core published operation of the package. Its purpose is to re-derive (recalculate) the person statistics for a given person record, ensuring that the derived status attributes held against the person are consistent with the current underlying data. It is the procedure that downstream forms and batch processes call when the categorical or summary attributes of a person must be regenerated after changes to that person's party record or their identifier group membership.

No additional documented procedures or functions appear in the metadata. As a consequence, callers should treat REDERIVE_PERSON_STATS as the primary (and documented) interface of this package.

Tables Accessed

The package body accesses the following tables, either directly or through API-layer dependencies:

  • HZ_PARTIES — The central TCA (Trading Community Architecture) table of parties. Person statistics are keyed to a party record, so the package reads (and, through the derivation logic, supports updates to) the person's party attributes.
  • FND_COLUMNS — A generic Application Object Library repository of column metadata, used here for flexible/attribute-driven processing rather than fixed column coding.
  • FND_TABLES — The companion AOL repository of table metadata, consulted alongside FND_COLUMNS to drive the same generic mechanism.

In addition, the metadata shows indirect dependencies on IGS_PE_PERSID_GROUP, IGS_PE_PRSID_GRP_MEM, and IGS_PE_PRSID_GRP_MEM_V. These person-identifier-group and group-membership tables/vies supply the grouping context used when deciding which statistics apply to the party. The derivation logic is therefore driven by party data plus identifier-group membership, with AOL metadata tables providing the configurable lookup framework.

Usage Notes

REDERIVE_PERSON_STATS is normally invoked in three ways:

  • From Oracle Student System forms — when a user saves changes to person or party-identifier data, the form triggers re-derivation so displayed statistics remain accurate.
  • From concurrent programs — batch jobs that refresh person statistics across a population call the procedure for each qualifying person, typically after bulk data loads or interface runs.
  • From custom code — implementers writing extensions must call the public procedure rather than updating the underlying statistics tables directly, so that API context initialisation, message-stack handling, and error propagation follow Oracle's supported pattern.

Because the package depends on FND_API, FND_MSG_PUB, and IGS_GE_MSG_STACK, callers should expect standard EBS API semantics: a message stack that must be initialised before the call and inspected afterwards, and return status conveyed through the API's own error-handling conventions rather than raw Oracle exceptions. As the package is VALID and referenced by no other database object, it can be called safely without concern for unintended upstream side effects, provided the caller supplies a valid person context.