Search Results s_fee_trigger_cat




Overview
Explore in AI Chat

Overview

IGS_FI_VAL_FT is a student financials validation package within the Oracle E-Business Suite (EBS) 12.1.1 / 12.2.2 higher education solution. It belongs to the Student System (IGS) product family and is owned by the APPS schema, declared with AUTHID CURRENT_USER so that privileges are resolved against the invoking user rather than the package owner. The package encapsulates business rules that govern fee type configuration and, in particular, the optional payment indicator and the fee trigger category (s_fee_trigger_cat) attribute. Its role is to centralise the consistency checks that would otherwise be duplicated across the fee setup forms and self-service pages, returning a Boolean result and an OUT message name that the calling UI layer translates into an end-user error or warning message.

The object is classified as OTHER in the ETRM documentation rather than as a public or private API, which reflects its use as an internal validation routine invoked during data entry. Its source header indicates an original ship date of 2002, consistent with a long-standing component of the Student System fee configuration framework.

Key Procedures and Functions

The package exposes four documented functions, each returning BOOLEAN and each carrying a PRAGMA RESTRICT_REFERENCES assertion of WNDS (write no database state), confirming that these routines perform pure validation and do not mutate data.

  • FINP_VAL_FT_OPT_PYMT — Validates whether the optional payment indicator may legitimately be set to 'Y' for a given fee type, ensuring the configuration is permitted before it is saved.
  • FINP_VAL_FT_TRIG — Validates changes to the fee trigger category (s_fee_trigger_cat), comparing the new value against the prior value so that transitions between categories are permitted only where the underlying fee setup allows it.
  • FINP_VAL_FT_SFT_TRIG — Validates that a system fee type (s_fee_type) and a fee trigger category (s_fee_trigger_cat) are compatible with one another, preventing invalid pairings of fee type to trigger.
  • FINP_VAL_FT_SFTC — Performs a second, related validation of changes to s_fee_trigger_cat, applying the fee type context to the new and old trigger categories.

The signatures follow a consistent pattern: an identifying fee type, the new and old trigger category values (where relevant), and an OUT parameter returning a message name. This design allows the caller to obtain both a pass/fail decision and the message name to surface in the form.

Tables Accessed

Validation depends on the fee configuration and trigger setup tables, reached through APPS synonyms. The primary fee definition tables are IGS_FI_FEE_TYPE_ALL, IGS_FI_FEE_AS_RATE and IGS_FI_FEE_RET_SCHD, which hold fee type and repayment schedule attributes. Trigger configuration is read from IGS_FI_UNIT_FEE_TRG, IGS_PS_FEE_TRG, IGS_PS_GRP_FEE_TRG and IGS_PS_TYPE_FEE_TRG, covering unit-, program-, group- and type-level fee triggers. The package also references IGS_EN_UNITSETFEETRG, IGS_FI_ELM_RANGE and IGS_FI_TP_RET_SCHD, which relate to enrolment unit set triggers, element ranges and third-party repayment schedules. All access is read-only, consistent with the WNDS assertions declared on each function.

Usage Notes

IGS_FI_VAL_FT is invoked during fee setup data entry, typically from the Oracle Forms-based Student System administration screens and from self-service fee configuration pages, at the point where an operator sets or changes the optional payment indicator or the fee trigger category. It is also referenced by one other package in the APPS schema, indicating that a broader validation flow calls into it rather than duplicating the checks. Because the functions return Boolean and expose a message name OUT parameter, callers must wrap the invocation in PL/SQL and convert the Boolean to a form-level error message. Custom extensions that maintain or validate fee type and trigger data should call these routines instead of reimplementing the rules, since the logic reflects the seeded compatibility constraints among fee types, trigger categories and repayment schedules.