Search Results pending_review_pmt_val_errors

Overview

IBY_PAYMENT_MANAGER_PKG is a PL/SQL package owned by the APPS schema within the Oracle Payments (IBY) module of Oracle E-Business Suite. Its principal business purpose is to support the Payables Payment Manager Home Page by aggregating and exposing the status of Payment Process Requests (PPRs). The package is declared with AUTHID CURRENT_USER, meaning that the privileges of the invoking user are used when resolving the objects referenced inside the package body.

The central design element of the package is a pipelined query function that returns snapshot counts of Payment Process Requests, grouped according to logical status categories. These categories consolidate PPR states originating from both Oracle Payables (AP) and Oracle Payments (IBY) into a single, user-friendly view. This consolidation allows the Home Page to present counts such as "Need Action By Me," "Processing," "User Terminated," "Program Errors," and "Completed" without the caller needing to understand the underlying status codes from either application. Because the function is pipelined, its results can be consumed in a standard SQL query, making it suitable for embedding in the Payment Manager dashboard.

Key Procedures and Functions

The documented package exposes two callable units:

• GET_PSR_SNAPSHOT_PIPE — A pipelined function designed for the Payables Payment Manager Home Page. It returns the total count of Payment Process Requests whose status, or combination of statuses, maps to a particular snapshot code. The snapshot codes consolidate AP and IBY statuses. For example, NEED_ACTION_BY_ME includes AP statuses 'REVIEW' and 'MISSING RATES' together with IBY statuses such as 'INFORMATION_REQUIRED', 'PENDING_REVIEW_DOC_VAL_ERRORS', 'PENDING_REVIEW_PMT_VAL_ERRORS', and 'PENDING_REVIEW'. PROCESSING covers AP statuses such as 'UNSTARTED', 'SELECTING', 'CANCELING', 'CALCULATING', and 'SELECTED', plus IBY statuses including 'INSERTED', 'SUBMITTED', 'ASSIGNMENT_COMPLETE', 'DOCUMENTS_VALIDATED', and the retry states. USER_TERMINATED covers AP 'CANCELED' and 'CANCELLED NO PAYMENTS' along with IBY 'TERMINATED'. PROGRAM_ERRORS and COMPLETED map to IBY validation-error and 'PAYMENTS_CREATED' statuses respectively. The function also supports a total count across AP.
• CHECK_ORG_ACCESS — A helper function that validates whether the current user has access to a given organization (operating unit) before Payment Manager data is displayed or acted upon. This enforces multi-org security so that snapshot counts and payment data are restricted to the organizations the user is authorized to view.

NEVER invent parameter lists — the documented metadata identifies these units by name and purpose only.

Tables Accessed

The package references the following tables (accessed via APPS synonyms):

• IBY_PAY_SERVICE_REQUESTS — the primary source of Payment Process Request status information used to compute the snapshot counts.
• IBY_PAYMENTS_ALL and IBY_PAY_INSTRUCTIONS_ALL — payment and payment instruction records associated with PPRs.
• AP_INV_SELECTION_CRITERIA_ALL — Payables payment selection criteria, linking AP-side selection data to the PPR.
• FND_LOOKUP_VALUES — lookup values, typically used to resolve or translate status codes.
• DUAL — used for scalar evaluations.
• PLITBLM — the standard PL/SQL table used to support pipelined function output.

Usage Notes

IBY_PAYMENT_MANAGER_PKG is invoked primarily by the Payables Payment Manager Home Page to populate snapshot counters. CHECK_ORG_ACCESS is typically called during page initialization to enforce operating-unit security. The package may also be invoked from concurrent programs or custom code that needs to reproduce the Home Page snapshot logic. It is not referenced by any other documented package, so its use is generally confined to the Payment Manager user interface and related customizations. Developers extending Payment Manager dashboards should call GET_PSR_SNAPSHOT_PIPE through SQL (SELECT ... FROM TABLE(...)) and gate access using CHECK_ORG_ACCESS rather than querying the underlying PPR tables directly.