Search Results ari_process_validate

Overview

ARI_PROCESS_VALIDATE is a PL/SQL package body owned by the APPS schema within Oracle E-Business Suite Receivables (AR). It serves as the validation engine for the iReceivables self-service application, the customer-facing web module that allows external users to review and act upon their account transactions. The package encapsulates the business rules that determine whether a specific transaction, payment schedule, or print request is eligible for a requested action before that action is committed to the database. In effect, it acts as a gatekeeper: calling programs submit transaction identifiers, and the package returns a status indicating whether each item passed or failed validation.

The package header block exposes two global variables that govern its operational context. G_DEBUG and G_DEBUG_COUNT control diagnostic output, while G_PKG_NAME is a constant VARCHAR2(30) initialized to the literal string 'ARI_PROCESS_VALIDATE'. This constant is used throughout the package, most notably in the private LOG_MESSAGE routine, where it is passed as the module identifier to FND_LOG.STRING so that all messages emitted by the package are consistently attributed to it in the Oracle Applications logging framework. Packaged constants of this pattern are the standard EBS convention for identifying the source of runtime log entries, which is the reason the string "g_pkg_name" commonly surfaces in searches against this object.

Key Procedures and Functions

The package body exposes three documented public procedures:

• VALIDATE_DISPUTE — Validates a transaction before a dispute is raised against it. According to the embedded header comments, the procedure accepts a customer account identifier, a site use identifier, the current iReceivables session identifier, a table of payment schedule identifiers, and a table of transaction numbers for display. It returns a table of failed payment schedule identifiers, a return status of 'S' for success or 'E' for error, a message count, and the validating error message text. The procedure is therefore designed for bulk validation, allowing an entire set of scheduled payments to be screened in a single call.
• VALIDATE_PAYMENT — Performs the corresponding eligibility checking for payment transactions submitted through the iReceivables interface.
• VALIDATE_PRINT — Validates whether requested documents or transactions are eligible to be printed or reprinted.

All three procedures share the standard EBS API return convention of x_return_status, x_msg_count, and x_msg_data. An internal LOG_MESSAGE procedure writes to FND_LOG when the requested log level meets or exceeds FND_LOG.G_CURRENT_RUNTIME_LEVEL, and its exception handler re-enters itself with LEVEL_UNEXPECTED if logging fails, ensuring diagnostics never propagate an error to the caller.

Tables Accessed

The only table documented as referenced through APPS synonyms is PLITBLM, a standard Oracle Applications interim table used to stage rows during multi-row processing. Its presence is consistent with bulk validation of payment schedule and transaction identifier tables, where candidate identifiers are loaded and then evaluated. Additional transaction and payment schedule data is accessed indirectly through the payment schedule identifier inputs supplied by the caller.

Usage Notes

This package is not an end-user entry point; it is invoked programmatically. In a standard deployment it is called from the iReceivables JSP and servlet layer, or from other PL/SQL packages in the Receivables self-service stack. The ETRM metadata records that one other package references ARI_PROCESS_VALIDATE, confirming its role as a shared internal service. Customizations should call the documented procedures rather than the private logging routine, check x_return_status before proceeding, and retrieve the full message stack via FND_MSG_PUB when x_msg_count exceeds zero. Because the package version is 120.4 (last modified 2011), behavior is consistent across both 12.1.1 and 12.2.2 online patching environments, though the G_PKG_NAME constant reports the same identifier in both.