Search Results documents_payable_rejected

Overview

CE_PMT_CALLOUT_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Cash Management (CE) module and functions as a callout interface package for the payments subsystem. Its role is to provide a standardized, callable entry point through which events originating in the payment lifecycle can be communicated to Cash Management so that downstream payment reconciliation logic can be triggered. The package is declared with AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking user and rely on APPS-owned synonyms for any underlying tables. The specification header carries a revision string, cepmtcos.pls 120.1, indicating a relatively stable and lightweight interface rather than a large functional library. The package exposes three public procedures and no functions, all designed around notification-style events: rejected payable documents, completed payments, and voided payments. In the 12.1.1 and 12.2.2 releases, the API classification is recorded as OTHER, meaning it is not one of the primary public APIs documented for external integration, but it remains an operational component of the cash management payment processing flow.

Key Procedures and Functions

• DOCUMENTS_PAYABLE_REJECTED — The procedure most directly associated with the search term "documents_payable_rejected". It signals to Cash Management that a group of documents has been rejected as payable. It accepts the standard EBS API boilerplate parameters (API version, initialization of the message list, commit control) along with an output return status, message count, and message data. Its substantive business parameter is a rejected documents group identifier, which allows the caller to convey the set of rejected documents in a single call rather than item by item.
• PAYMENTS_COMPLETED — Notifies Cash Management that a group of payments has been completed. It follows the same standard API parameter pattern and takes a completed payments group identifier. This supports confirmation that payment processing finished successfully and allows Cash Management to update the affected payment records accordingly.
• PAYMENT_VOIDED — Notifies Cash Management that an individual payment has been voided. In addition to the standard boilerplate parameters, it accepts a payment identifier and a void date. The presence of an explicit void date distinguishes it from the group-oriented procedures: voiding applies to a specific payment at a specific point in time.

Tables Accessed

The documented table reference for this package is CE_PAYMENT_TRANSACTIONS, accessed through APPS synonyms. This table is the central transactional store for payments recorded in Cash Management. The rejection, completion, and voiding procedures logically read and update rows in CE_PAYMENT_TRANSACTIONS to reflect the changed state of the payment or document group supplied by the caller. No additional tables are documented in the ETRM metadata, and the specification indicates no direct references to other modules beyond what the underlying package body performs.

Usage Notes

This package is typically invoked programmatically rather than from a standard Oracle Forms user interface. Its callers are expected to be other EBS APIs, workflow activities, or custom code within the payments processing flow that must inform Cash Management of a completed, rejected, or voided payment event. Because the procedures use the standard EBS API signature — with p_api_version, p_init_msg_list, p_commit, and the x_return_status/x_msg_count/x_msg_data outputs — custom integrations should follow the usual EBS API conventions: initialize the message list when required, inspect x_return_status for success, and decide whether to commit within the call or manage the transaction externally. The ETRM metadata records that the package is referenced by zero other packages, indicating that it is a leaf-level callout rather than a shared internal library. The API classification of OTHER also means developers should confirm version-specific behavior against the installed package body before relying on it in a customization, particularly when migrating between 12.1.1 and 12.2.2.