Search Results assp_val_lr_dflt_one

Overview

IGS_OR_VAL_LR is a validation package in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 release levels, owned by the APPS schema. It belongs to the Oracle Student System / Higher Education product family, indicated by the "IGS" (Institution of Higher Education) prefix. Its documented purpose, taken directly from the source header, is to "Validate the location relationship." Location relationships in the student system describe how a primary location relates to a sub-location, for example a campus building tied to a floor, room, or delivery site. The package centralizes the business rules that determine whether a given location and sub-location combination is valid before it is committed to the database. It is classified as an OTHER API, meaning it is an internal validation utility rather than a public, callable integration API. The package is declared with AUTHID CURRENT_USER, so it executes with the privileges of the calling session rather than the definer. The header carries the source control tag $Header: IGSOR07S.pls 115.4 2002/11/29, indicating it is a long-standing component of the product.

Key Procedures and Functions

The documented package exposes five functions, all returning BOOLEAN to signal success or failure of the relevant validation, and all receiving an OUT NOCOPY parameter named p_message_name for returning the error or message text.

• ORGP_VAL_LR — Validates a location relationship by accepting a location code and sub-location code. It is the core general-purpose validation routine for the location relationship concept.
• ORGP_VAL_LOC_CD — Validates the location code itself, confirming that the supplied location is a recognized value. It takes only the location code and the message parameter.
• ASSP_VAL_LR_DFLTSLOT — Marked as retrofitted, this function validates the default slot indicator (dflt_ind) on a location relationship, using typed parameters anchored to IGS_AD_LOCATION_REL columns. It checks whether the default flag assignment for the given location and sub-location is permissible.
• ASSP_VAL_LR_DFLT_ONE — Also retrofitted, this function validates that only one default exists for a sub-location type (p_sub_s_location_type) within the specified location relationship, enforcing the single-default rule.
• ASSP_VAL_LR_LR — The function matching the user's search term "assp_val_lr_lr," also retrofitted. It performs the principal location relationship validation, taking a location code and sub-location code and confirming that the pair constitutes a valid relationship in IGS_AD_LOCATION_REL.

No additional parameters beyond those shown in the source are documented, and the package contains no public procedures, only these functions.

Tables Accessed

The only documented table referenced by this package, through APPS synonyms, is IGS_AD_LOCATION_REL. This is the location relationship entity table, holding the valid combinations of location codes, sub-location codes, default indicators, and sub-location types. The functions read this table to confirm that a proposed relationship exists and that its default settings comply with business rules; the BOOLEAN return values and p_message_name output convey the result back to the caller without modifying the table directly.

Usage Notes

IGS_OR_VAL_LR is typically invoked as a server-side validation layer rather than by end users directly. Oracle Forms in the Student System commonly call these functions during record validation, for example when a user enters or updates a location relationship, allowing the form to raise an error before the record is saved. The package is referenced by one other package, indicating it participates in a small dependency chain of validation utilities. Concurrent programs or custom PL/SQL that insert or update location relationship data should call the appropriate function—ORGP_VAL_LR or ASSP_VAL_LR_LR for general relationship checks, ASSP_VAL_LR_DFLT_ONE for the single-default rule, and ASSP_VAL_LR_DFLTSLOT for default slot validation—and handle the BOOLEAN result and message accordingly. Because it is an internal OTHER-classified API and uses AUTHID CURRENT_USER, custom code should invoke it from within the APPS context.