Search Results ar_cm_app_val_pvt




Overview
Explore in AI Chat

Overview

APPS.AR_CM_APP_VAL_PVT is a private (PVT) PL/SQL validation package in Oracle Receivables, introduced in the 11i/12.x code line and documented in ETRM for 12.2.2. Its stated purpose is to serve as the validation package for the Credit Memo Application API. Before a credit memo application is created, reversed, or otherwise processed, the Credit Memo Application API invokes this package to confirm that the transaction, amounts, dates, currencies, and approval limits satisfy Receivables business rules. The package header carries the source control identifier $Header: ARXCMAVS.pls 120.2 2005/10/30 03:59:08 appldev ship $, and the modification history records that it was created by jbeckett on 27-JAN-05. The public procedures are declared in the package specification; consistent with its PVT classification, the package is not a supported public API and is intended for internal use by the Credit Memo Application API and other Receivables program units. The ETRM metadata records one referencing package, confirming that callers reach these validation routines through the application API layer rather than directly from end-user code.

Key Procedures and Functions

Three documented procedures constitute the package interface. Each returns a standard p_return_status OUT NOCOPY parameter so that callers can branch on FND_API.G_RET_STS_SUCCESS or error status and retrieve messages through the paired AR_CM_APP_VAL_PVT error handling.

  • validate_activity_app — Performs the core validation of a credit memo application. Its parameters supply the receivables transaction identifier, payment schedule identifier, customer transaction identifier, credit memo GL date, unapplied amount, transaction date, amount applied, application GL date, apply date, credit memo currency code, approval limit flag, and the calling context (p_called_from). This is the procedure associated with the user search term "validate_activity_app" and is the principal entry point used when a credit memo is applied against an activity such as an invoice, debit memo, or chargeback.
  • validate_unapp_activity — Validates the unapplied portion of a credit memo activity. It works with the transaction GL date, receivable application identifier, reversal GL date, apply GL date, and credit memo unapplied amount, confirming that the unapplied balance being processed is valid before the application is committed.
  • validate_credit_memo — Performs credit memo level validation, accepting the initialization message list flag and the customer transaction identifier. It establishes whether the credit memo itself is in a valid state to be applied.

Tables Accessed

Validation is driven by direct reads of the Receivables data model. Via APPS synonyms the package queries RA_CUSTOMER_TRX to confirm the credit memo transaction attributes, AR_PAYMENT_SCHEDULES to confirm payment schedule status and remaining balances, and AR_RECEIVABLE_APPLICATIONS for existing application activity. AR_RECEIVABLES_TRX classifies the activity type, while AR_APPROVAL_USER_LIMITS supports the approval limit check exposed through the p_chk_approval_limit_flag parameter. Receipt-related validation relies on AR_RECEIPT_CLASSES, AR_RECEIPT_METHODS, and AR_RECEIPT_METHOD_ACCOUNTS, which together determine the accounting and receipt setup associated with the transaction. These lookups are read-only; the package validates and signals status rather than persisting application rows itself.

Usage Notes

AR_CM_APP_VAL_PVT is invoked indirectly whenever the Credit Memo Application API is used — for example from the Receivables credit memo application forms, from concurrent or batch application programs, and from custom extensions that call the supported credit memo application API. It may also be called within AutoLockbox, lockbox, and other receipt-based workflows that apply credit memos. Because the package is classified PVT, direct invocation from custom code is not supported, and validation logic may change without notice between 12.1.1 and 12.2.2. Oracle Forms and concurrent programs should always be routed through the public API layer, which calls these validation routines and interprets p_return_status on the caller's behalf.