Search Results display_parameters

Overview

APPS.AR_CM_API_PUB is a public PL/SQL package body in Oracle E-Business Suite Receivables that exposes programmatic interfaces for on-account credit memo processing. The package allows callers to apply an on-account credit memo against a debit memo or invoice, and to reverse that application, without navigating the Receivables application forms. The header comment in the package source states this intent explicitly: the credit memo APIs allow users to apply or unapply an on-account credit memo against a debit memo or invoice through simple PL/SQL calls.

The package conforms to the standard Oracle Application Object Library API model. Almost all procedures accept the conventional p_api_version, p_init_msg_list, and p_commit control parameters and return the standard x_return_status, x_msg_count, and x_msg_data output arguments. This contract, together with the use of FND_MSG_PUB message-level constants and FND_API.G_FALSE defaults, makes AR_CM_API_PUB suitable for direct invocation from custom concurrent programs, forms, and other PL/SQL packages. It is classified as a PUB API in the ETRM repository, indicating that it is a supported public interface rather than an internal implementation detail.

Key Procedures and Functions

• APPLY_ON_ACCOUNT — Applies an on-account credit memo to a debit memo or invoice. The caller supplies an API version, initialization and commit flags, and a credit memo application record (cm_app_rec_type). The procedure returns the standard API status outputs plus the identifier of the created application and the accounted amounts applied from and to the source and target transactions. Internally the procedure resolves the credit memo and invoice transaction identifiers, validates the application, derives GL dates and currencies, and writes the resulting application record.
• UNAPPLY_ON_ACCOUNT — Performs the reverse operation, removing a previously created on-account application. This supports correction and reversal scenarios in which a credit memo must be unlinked from the debit memo or invoice against which it was applied.

Both procedures follow the same error-handling pattern, populating the FND message stack and returning a status of success, error, or unexpected error so that the calling program can interrogate x_msg_count and x_msg_data. The internal validation steps referenced in the package body, including flexfield and defaulting checks, are performed before the application is committed.

Tables Accessed

• AR_RECEIVABLE_APPLICATIONS — The primary table written and read by this package. It stores the application record linking the credit memo to the debit memo or invoice, including the accounted amounts applied from and to each side.
• AR_PAYMENT_SCHEDULES — Read to locate the installment and payment schedule rows for both the credit memo and the target transaction, and to obtain the applied payment schedule identifier.
• RA_CUSTOMER_TRX — Read to resolve the credit memo and invoice transaction headers, their transaction dates, currency codes, and GL dates.
• RA_CUSTOMER_TRX_LINES — Read to resolve the specific transaction line against which the application is made.
• FND_CURRENCIES — Read to validate and resolve the currency codes of the credit memo and the invoice during application processing.

Usage Notes

AR_CM_API_PUB is typically invoked from custom PL/SQL code, from Oracle Forms-based extensions, or from concurrent programs that automate credit memo application and reversal. The package depends on other Receivables and AOL packages for defaulting, validation, and messaging, and the ETRM metadata records that it is referenced by two other packages, confirming its role as a shared service layer. When calling these procedures, developers must pass a valid API version and should inspect x_return_status and the returned message stack on every invocation, because the procedures do not raise exceptions for business-rule failures. The p_commit flag allows the caller to control transaction boundaries, so integration code should commit only after all related API calls in a logical unit have returned success.