Search Results q_scon

Overview

HR_DIRBAL is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, subject to the standard product schema naming convention for Oracle Human Resources and Oracle Payroll components (the HR_ prefix with the DIRBAL suffix denoting "direct balance"). It exposes a set of balance-retrieval and date-derivation utilities used by the payroll balance engine. Its central purpose is to return the value of a defined balance for a payroll assignment under a specified effective date, assignment action, or dimension/period combination, and to determine whether a balance has expired relative to a defined year, period, or quarter boundary. Because these are compiled program units, described with PRAGMA RESTRICT_REFERENCES (WNDS) declarations on the date functions, they may be invoked freely from SQL and other PL/SQL contexts without violating purity-level constraints.

Key Procedures and Functions

• GET_BALANCE — the primary overloaded function family. One overload resolves a balance from an assignment identifier, a defined balance identifier, and an effective date (Date Mode). A second overload resolves the same using an assignment action identifier and defined balance (Assignment Action Mode). A third, specialised overload adds dimension and period identifiers and is documented as usable only within the PAYGBTPL report in the Q_SCON context.
• BALANCE_EXPIRED — returns a BOOLEAN indicating whether a balance associated with an assignment action has passed its expiry boundary, accepting optional owning action, defined balance, database item suffix, effective date, and action effective date arguments.
• START_YEAR_DATE — returns the DATE on which the balance year begins for a given assignment action and database item suffix.
• EXPIRED_YEAR_DATE — takes an action effective date and returns the DATE on which the associated balance year expires.
• EXPIRED_PERIOD_DATE and EXPIRED_QUARTER_DATE — return the expiry DATE for the period and quarter containing the supplied action effective date.
• GET_ACTION_DATE — the function behind the "get_action_date" search. It derives the effective date of an assignment action, providing callers with the authoritative date reference used throughout the balance-expiry logic described above.

Tables Accessed

The package reads from the core payroll balance and time-period data model through APPS synonyms. PAY_ASSIGNMENT_ACTIONS supplies the assignment action records used in Assignment Action Mode and in all expiry-date calculations. PAY_DEFINED_BALANCES identifies the balance definition being resolved, while PAY_BALANCE_DIMENSIONS supplies dimension and period-to-date dimension information used by the dimension-aware GET_BALANCE overload. PAY_PAYROLL_ACTIONS provides the payroll action context against which assignment actions and their dates are interpreted. PER_TIME_PERIODS supplies the period boundaries required to compute period and quarter expiry dates and year-start dates. The documented operations are read-oriented; no inserts, updates, or deletes are described.

Usage Notes

HR_DIRBAL is a supporting package rather than a user-facing one. It is referenced by twelve other packages in the ETRM repository, indicating that it sits beneath higher-level payroll balance APIs and balance-extraction routines. GET_BALANCE overloads are the documented consumption path for balance values from date-driven or action-driven contexts, while BALANCE_EXPIRED and the family of expiry-date functions enforce the temporal validity rules of payroll balances. The reference to PAYGBTPL and Q_SCON in the package header confirms at least one legacy report dependency for the four-argument GET_BALANCE overload. In Oracle EBS 12.1.1 and 12.2.2 the package would typically be invoked from concurrent programs, Oracle Forms-based payroll windows, and custom PL/SQL that needs a definitionally consistent balance value or action date. The GET_ACTION_DATE function in particular is the appropriate entry point when a caller requires the effective date of an assignment action without duplicating the derivation logic. Customisations should call the packaged functions rather than querying the underlying tables directly, so that future changes to balance expiry rules remain transparent to the calling code.