Search Results get_ret_sts_unexp_error

Overview

APPS.RCV_ACCRUALUTILITIES_GRP is a public PL/SQL package declared with AUTHID CURRENT_USER, owned by the APPS schema and classified within the E-Business Suite as an API group (GRP) rather than a single-purpose API. Its functional remit is accrual, purge, and utility processing for the Receiving (RCV) module in Oracle EBS 12.1.1 and 12.2.2. In practical terms, the package provides the plumbing that allows receiving-side accrual logic and purge routines to be executed consistently against the standard RCV schema while deriving session-level privileges from the calling user. Because it is an AUTHID CURRENT_USER package rather than a definer-rights package, runtime privilege checking is performed against the invoker, which is significant for installs that create custom wrapper code around the standard RCV APIs.

The package exposes both a set of constant-returning helper functions and a smaller set of business methods. The helper functions exist chiefly so that dependent code can obtain canonical FND_API status values and boolean/level flags without hard-coding literals or referencing FND_API directly. The business methods handle receiving accrual validation, purchase-order purge validation and execution, and retrieval of receiving unit price and encumbrance reversal amounts.

Key Procedures and Functions

• GET_RET_STS_SUCCESS — Returns the G_RET_STS_SUCCESS constant from FND_API, permitting callers to compare API return status without a direct FND_API dependency.
• GET_RET_STS_ERROR — Returns the G_RET_STS_ERROR constant from FND_API for expected, handled error conditions.
• GET_RET_STS_UNEXP_ERROR — Returns the G_RET_STS_UNEXP_ERROR constant from FND_API. This is the function most frequently sought by developers when diagnosing unexpected-error handling in receiving accrual and purge flows; it lets custom code classify a failure as an unhandled exception rather than a validation error.
• GET_TRUE / GET_FALSE — Return the G_TRUE and G_FALSE constants from FND_API, used for boolean-typed flags in the surrounding API conventions.
• GET_VALID_LEVEL_NONE / GET_VALID_LEVEL_FULL — Return the corresponding FND_API validation-level constants, allowing callers to specify or test validation scope.
• GET_RECEIVINGUNITPRICE — Retrieves the receiving unit price, used in accrual and accounting-event calculations for received goods.
• VALIDATE_PO_PURGE — Determines whether a purchase order is eligible for purge, populating the purge output structure that carries the purge_allowed flag.
• PURGE — Executes the purge of the identified entity set, accepting the purge input record type (entity_ids) and returning purge eligibility/output information.
• GET_ENCUMREVERSALAMT — Returns the encumbrance reversal amount associated with the receiving/accrual transaction under evaluation.

The package also declares the TBL_NUM, TBL_V1, purge_in_rectype, and purge_out_rectype types that carry entity identifier collections and purge outcomes.

Tables Accessed

Access to base tables is via APPS synonyms. Receiving and transaction detail is drawn from RCV_TRANSACTIONS, RCV_RECEIVING_SUB_LEDGER, and RCV_ACCOUNTING_EVENTS, which form the core of accrual and accounting-event processing. MTL_MATERIAL_TRANSACTIONS and MTL_TRANSACTION_ACCOUNTS supply inventory transaction and accounting-line data. Purchase-order context comes from PO_HEADERS_ALL, PO_LINE_LOCATIONS_ALL, and PO_DISTRIBUTIONS_ALL, which support purge validation and encumbrance logic. WIP_COST_TXN_INTERFACE and WIP_TRANSACTIONS cover work-in-process cost transactions relevant to the same accrual/accounting population, and PLITBLM is referenced for concurrent-program interface handling.

Usage Notes

RCV_ACCRUALUTILITIES_GRP is not an end-user-facing object. It is invoked from Receiving forms and concurrent programs that process accruals, purge stale receiving or purchasing records, and calculate receiving unit price and encumbrance reversals, and it is called by custom PL/SQL that extends or reports on those flows. Because it is AUTHID CURRENT_USER, custom callers must hold the necessary privileges on the underlying synonyms. It is referenced by five other packages, so changes to its specification should be treated as having downstream impact. Developers should rely on the constant-returning functions rather than substituting literal values, ensuring consistent FND_API semantics across the Receiving schema.