Search Results submit_postbatch_parallel

Overview

AR_POSTBATCH_PARALLEL is a public PL/SQL package in the APPS schema that drives the parallel processing of Automatic Receipt batch posting in Oracle Receivables. Its principal responsibility is to decompose a single large PostBatch operation into a set of smaller, independently executable child requests, distribute those requests across a configurable number of concurrent workers, wait for their completion, and then reconcile the batch status once all workers have finished. The package was introduced to address the performance limitations of single-threaded batch posting, allowing high-volume receipt batches — particularly those originating from Lockbox transmissions — to be applied more rapidly by leveraging multiple concurrent managers simultaneously.

The package supports both forward processing and recovery. Where a child request fails, the batch is returned to a waiting state so that it may be retried at a later time without manual data repair. This makes the package central to the resiliency of the receipt posting pipeline.

Key Procedures and Functions

• SUBMIT_POSTBATCH_PARALLEL — The controlling entry point. It submits the child PostBatch requests using the internal submit_subrequest mechanism, based on an organization identifier, a batch identifier, a Lockbox transmission identifier, and a caller-supplied worker count. After dispatch it invokes update_batch_after_process to set the final batch status once all child requests have completed, using FND_REQUEST.wait_for_request to synchronise on their return. It exposes standard concurrent-program OUT parameters for error buffer and return code.
• UPDATE_BATCH_FOR_RERUN — The recovery procedure. When an error is encountered during the PostBatch run, this procedure resets the batch_applied_status of the identified batch to POSTBATCH_WAITING, so that the batch is re-queued for processing at a later time.

The literal value POSTBATCH_WAITING is of particular interest to users who search for "postbatch_waiting". It is the applied status assigned by UPDATE_BATCH_FOR_RERUN and represents a batch that has been released back to the queue following an unsuccessful posting attempt. A batch left in this state will be picked up by a subsequent PostBatch run; a persistent POSTBATCH_WAITING status typically indicates a recurring error condition within the child posting requests.

Tables Accessed

• AR_BATCHES and AR_BATCH_SOURCES — the batch header and its source definition; the applied status updated by UPDATE_BATCH_FOR_RERUN resides on AR_BATCHES.
• AR_CASH_RECEIPTS, AR_CASH_RECEIPT_HISTORY and AR_INTERIM_CASH_RECEIPTS — the receipt records created and updated as the batch is applied.
• AR_PAYMENTS_INTERFACE — the interface rows that are consumed during posting.
• AR_TRANSMISSIONS — the Lockbox transmission referenced by the p_transmission_id argument.
• AR_SYSTEM_PARAMETERS — Receivables system options that govern posting behaviour.
• CE_BANK_ACCOUNTS and CE_BANK_ACCT_USES_ALL — the bank account and account-use definitions associated with the receipts.

Usage Notes

The package is invoked indirectly rather than directly by end users. In a standard Oracle EBS 12.1.1 or 12.2.2 environment it is called by the PostBatch concurrent program (and by the Automatic Receipt Processing flow) when parallel posting is enabled, with the worker count derived from system configuration or program parameters. It is classified in the ETRM as OTHER rather than as a formal public API, and no other documented packages reference it, so custom code should not depend on its signature. Administrators investigating batches stuck in POSTBATCH_WAITING would typically review the concurrent request log for the parent PostBatch program, identify the failing child request, and resubmit. Parameter lists should always be confirmed against the installed ARPBMPS.pls source, as the argument set was modified after the package's original creation.