Search Results check_approval

Overview

PA_CLIENT_EXTN_RTE is a client extension package body owned by APPS in Oracle E-Business Suite. It is delivered as an empty, customer-modifiable hook rather than a functional business module. The package is designed to let implementers inject custom routing logic into the Oracle Projects expense and timecard approval flow, specifically at the point where an approver's final authority over an expenditure is evaluated. As delivered, the package contains no default business rules; all of the code that effects customer-specific behavior must be written by the implementing organization. The documented API classification is OTHER, and the package exposes exactly one documented routine: CHECK_APPROVAL.

Key Procedures and Functions

The single documented entry point is CHECK_APPROVAL, a procedure that receives the expenditure identifier, the person who incurred the expenditure, the expenditure end date, expense class code, amount, the prospective approver identifier, the routing mode, an optional timecard table (defaulted to a dummy structure) and an optional module name. It returns a status code plus an application identifier, message code, and up to five token values. The status is the controlling output: a value of zero indicates the approver held final authority to approve the expenditure, a negative value indicates an unexpected error in the extension, and a positive value indicates the approver did not hold final authority. The delivered body simply initializes every OUT parameter to NULL, provides a WHEN OTHERS handler that assigns SQLCODE to the status, and leaves the business-rule region empty for customer code. Because the default status is zero, an unmodified installation always approves.

Tables Accessed

The documented metadata lists no tables referenced through APPS synonyms. This is consistent with the package's design as a pure extension stub: it performs no direct SQL against Oracle Projects or Oracle Time and Labor base tables in its delivered form. Customer implementations that add routing logic are free to query the base tables relevant to their rule set, and the P_Timecard_Table parameter provides a structured conduit for timecard data originating from PA_OTC_API rather than a table dependency of the package itself. The absence of documented table access means the package has no built-in integrity or locking implications.

Usage Notes

The package is not invoked directly by end users. Oracle Projects calls it as a client extension during expenditure approval processing, most commonly from the routing and approval flows associated with expense reports, timecards, and pre-approved expenditure batches. The referenced-by count of one package indicates a single caller in the delivered code. Customers normally extend it by adding business rules between the initialization block and the exception handler, leaving all OUT parameter assignments intact so the caller can interpret the result. Returned message code and token values are typically used to raise a user-facing message when final authority is absent, and the application identifier directs the caller to the owning application for that message. Because the package relies on WHEN OTHERS capturing SQLCODE into the status, errors raised by custom code are surfaced to the caller as negative statuses rather than propagated exceptions. The routine must be recompiled and the approval flow retested after any modification, and upgrades may replace or invalidate the delivered edition unless the customization is preserved. A routine search for "check_approval" resolves to this object because it is the only documented procedure the package contains.