Search Results validate_print




Overview

ARI_PROCESS_VALIDATE_W is an Oracle EBS Accounts Receivables (AR) PL/SQL package owned by the APPS schema. It belongs to the AutoInvoice/Receivables processing family (object prefix "ARI_") and functions as a validation wrapper (the "_W" suffix indicating a generated or wrapper layer) that exposes a public API for validating payment schedules and related receivables transactions before they are processed further. The package is classified under the API classification of "OTHER" in the ETRM 12.2.2 repository, and its header comment indicates a public specification (ARI_PROCESS_VALIDATE_PUBJ_S.pls) dated 2011, which is consistent with use in both EBS 12.1.1 and 12.2.2 releases.

The business purpose of the package is to provide programmatic entry points for validating selected payment schedules and transaction numbers belonging to a customer account and customer site, returning the subset of records that fail validation along with a standard concurrent-program style status message stack (return status, message count, and message data). This allows upstream forms, concurrent programs, or custom code to identify which disputes or payments do not satisfy AR business rules before committing to downstream processing.

Key Procedures and Functions

The package exposes seven documented program units. Four are internal-style helper procedures generated to marshal PL/SQL collections to and from Oracle JTF table types:

Three procedures form the public validation API. Each accepts a customer account ID, customer site use ID, session ID, a payment schedule table, and a transaction number table, and returns a failing payment schedule table, return status, message count, and message data:

  • VALIDATE_DISPUTE — Validates disputed payment schedules and transaction numbers for the specified customer account/site. This is the routine most relevant to the user's search term "validate_dispute".
  • VALIDATE_PAYMENT — Validates payment schedules and transactions in the context of payment processing.
  • VALIDATE_PRINT — Validates payment schedules and transactions in the context of print (statements/dunning) processing.

Because the metadata does not document the internal implementation, the specific AR validation logic executed inside each routine cannot be enumerated; callers should treat the procedures as black-box validators returning the failing set.

Tables Accessed

The only table documented as referenced via APPS synonyms is PLITBLM, the standard Oracle EBS concurrent-manager message table. It is used to store and retrieve the message text associated with the x_msg_count and x_msg_data output parameters, enabling the standard FND_MSG_PUB message retrieval pattern used by EBS public APIs. The package additionally works with the in-memory collections payment_schedule_tbl (numeric payment schedule IDs) and trx_number_tbl (transaction number strings) defined inside the ARI_PROCESS_VALIDATE package body, which are not database tables but PL/SQL types marshalled through the JTF collection types.

Usage Notes

The package has no documented referencing packages (referenced by 0 other packages in the ETRM metadata), which indicates it is typically invoked directly rather than through a higher-level PL/SQL wrapper. Its signature — customer account, site use, session ID, and JTF collection inputs — is the classic pattern used by Oracle Forms and OA Framework pages that present a multi-select list of receivables items (disputes, payments, or print candidates) and require server-side validation before submission.

Typical invocation scenarios include:

  • A receivables dispute entry or adjustment form calling ARI_PROCESS_VALIDATE_W.VALIDATE_DISPUTE to confirm that selected payment schedules and transactions are eligible for dispute.
  • A payments or refunds form calling VALIDATE_PAYMENT before committing payment activity.
  • A statements/print concurrent program calling VALIDATE_PRINT to determine which items are printable.
  • Custom PL/SQL code integrating with AR calling the procedures with JTF_NUMBER_TABLE and JTF_VARCHAR2_TABLE_200 inputs, then reading x_fail_payment_schedule_tbl and the returned message stack via FND_MSG_PUB.

Callers must always populate the session ID, inspect x_return_status for the standard FND_API.G_RET_STS_SUCCESS / ERROR values, and retrieve messages using x_msg_count and x_msg_data when the return status indicates failure.