Search Results get_trx_date

Overview

APPS.PAY_US_PAYMENT_PKG is a United States–specific payroll payment utility package within the Oracle E-Business Suite Payroll (PAY) module. Its documented purpose is singular and focused: it supplies the payment date associated with a check payroll action. The package header carries the RCS identifier pyuspymt.pkh 120.0, indicating it forms part of the standard Oracle applications source tree rather than a customer-specific extension. It was created in April 2005 by rsethupa and, as reflected in the tight functional scope described in its header comments, exposes a single public function rather than a broad set of procedural APIs.

In the context of payroll processing in EBS 12.1.1 and 12.2.2, payment dating is a critical compliance and reconciliation concern. The payment date determines when a negotiable instrument — a check — is treated as issued, which in turn drives check register reporting, bank reconciliation, and statutory reporting. PAY_US_PAYMENT_PKG centralizes that determination in one callable unit so that concurrent processes, online forms, and custom code all resolve the payment date consistently, using the same business logic that Oracle Payroll itself applies.

Key Procedures and Functions

The ETRM metadata documents a single callable element in this package: the function named in the source header as get_trx_date. Its documented description is to return the payment date for a check payroll action. The function is declared with a set of optional identifiers that allow the caller to supply the business group, payroll action, assignment action, payroll, consolidation set, and organization payment method as context. Because the metadata does not fully enumerate parameter semantics, integrators should treat these as input selectors that narrow the payment date lookup to the correct payroll action context rather than as values the function returns or modifies.

No other procedures or functions are documented for this package. The absence of additional entries is itself informative: PAY_US_PAYMENT_PKG is a narrow helper package, not a general-purpose payment API. Where broader payment processing is required, other payroll packages should be used; this one should be reserved for its documented purpose of date resolution.

Tables Accessed

The package operates against five documented tables, all referenced through APPS synonyms. PAY_PAYROLL_ACTIONS is the parent record of the payroll run or action whose payment date is being resolved. PAY_ASSIGNMENT_ACTIONS holds the per-assignment work records generated by that action, and is the level at which the payment date is ultimately applied. PAY_PRE_PAYMENTS stores pre-payment information used in the check issuance flow. PAY_ACTION_INLOCKS is the interlock table that serializes competing payroll processes and prevents a payment date from being read or written while an action is mid-flight. PLITBLM is the standard Oracle PL/SQL in-memory table construct used for array-style bulk processing within server-side code. Taken together, these dependencies show the function reads payroll action and assignment action state and consults pre-payment data to derive the check payment date.

Usage Notes

Because this is a server-side PL/SQL package without a documented form-block or concurrent program registration, it is normally invoked from custom PL/SQL code, from other payroll packages, or from report logic that needs an authoritative payment date. The metadata records that it is referenced by one other package, confirming its role as a dependent helper rather than an entry point. When calling get_trx_date, supply the payroll action and associated identifiers for the check action of interest; the function returns the applicable payment date to the caller. Always call it within the same business group context as the action. In 12.2.2 the underlying tables reside in the same APPS schema, so no additional grants are required; in 12.1.1 the same calling pattern applies. Avoid embedding date rules of your own when this function is available, since divergent logic will cause reconciliation discrepancies between the check register and downstream bank reporting.