Search Results validate_request_parameters

Overview

AR_CREDIT_MEMO_API_PUB is the public, documented entry point of the Oracle Receivables Credit Memo API. It provides a supported programmatic interface through which external programs, Oracle Forms, and custom code can create credit memo requests against an existing customer transaction. Rather than inserting directly into the underlying Receivables tables, callers invoke this package so that the standard validation, defaulting, workflow initiation, and flexfield checks that Receivables requires are applied consistently. The package is classified as a PUB (public) API in the APPS schema and is shipped in both EBS 12.1.1 and 12.2.2. Its principal procedure, CREATE_REQUEST, accepts a credit memo request for a given customer transaction and drives it into the Receivables credit memo request workflow. The package is referenced by six other packages and depends on a defined set of Receivables and Workflow tables accessed through APPS synonyms.

Key Procedures and Functions

The package exposes seven documented procedures and functions:

• CREATE_REQUEST — The primary API. It accepts standard Oracle API parameters (API version, initialization of the message list, commit flag, validation level, and the standard return status / message count / message data out parameters) together with credit memo request parameters such as the customer transaction identifier, line credit flag, line, tax, and freight amounts, credit memo reason code, comments, original transaction number, tax exemption certificate number, print URLs, a credit memo line table, a skip-workflow flag, credit method options, batch source name, and organization identifier. It returns the generated request identifier. This is the standard API responsible for creating the credit memo request and, unless skipped, launching the associated workflow.
• VALIDATE_REQUEST_PARAMETERS — Performs validation of the values supplied to CREATE_REQUEST before any processing occurs.
• GET_REQUEST_STATUS — Returns the current status of a previously submitted credit memo request.
• PRINT_DEFAULT_PAGE — Serves as the default print URL referenced by the request, transaction, and transaction action URL parameters.
• VALIDATE_LINE_INT_FLEX — Validates the line-level descriptive flexfield values associated with credit memo request lines.
• VALIDATE_INT_DESC_FLEX — Validates the internal descriptive flexfield values supplied on the request.

Two further internal procedures supplement these to support internal comment handling.

Tables Accessed

The package reads and writes several Receivables and Workflow objects through APPS synonyms:

• RA_CM_REQUESTS, RA_CM_REQUEST_LINES, RA_CM_REQUEST_LINES_ALL — The credit memo request header and line tables, where the created request and its lines are persisted.
• RA_CUSTOMER_TRX, RA_CUSTOMER_TRX_ALL, RA_CUSTOMER_TRX_LINES — The originating customer transaction and its lines, used to identify and validate the transaction being credited.
• RA_CUST_TRX_TYPES, RA_BATCH_SOURCES — Transaction type and batch source definitions used in defaulting and validation.
• AR_PAYMENT_SCHEDULES — Consulted for the payment schedule of the parent transaction.
• AR_NOTES — Stores comments attached to the credit memo request.
• WF_ITEMS, WF_PROCESS_ACTIVITIES, WF_ITEM_ACTIVITY_STATUSES — Workflow tables used to initiate and track the credit memo request workflow and to report request status.
• FND_DESCRIPTIVE_FLEXS — Descriptive flexfield metadata used by the flexfield validation procedures.

HTP is referenced for page generation used by the print URL routines.

Usage Notes

CREATE_REQUEST is typically invoked from customized Oracle Forms, PL/SQL batch routines, or custom concurrent programs when the business requirement is to raise a credit memo against an existing invoice or debit memo without using the standard Credit Memo form. Callers must load the message list and inspect the returned status, message count, and message data, since the package follows the standard FND_API error-handling conventions. The validation level parameter controls how extensively input values are checked. The skip-workflow flag allows callers to create the request without immediately initiating the workflow, while the print URL parameters determine the navigation target of the resulting request. The org identifier should be supplied in a multi-org environment so the request is created in the correct operating unit.