Search Results reopen_batch

Overview

The APPS.GME_REOPEN_BATCH_PVT package is a private PL/SQL API within the Oracle E-Business Suite Process Manufacturing (OPM) module. Its primary business function is to allow a previously closed or posted production batch to be reopened so that corrections, adjustments, or additional transactions can be applied to it. This is a controlled administrative operation because reopening a batch reverses the normal accounting and inventory assumptions that follow from batch closure. The package was authored by Olivier Daboval of OPM Development on 31 May 2001, with subsequent modification in August 2001 to support the phantom implementation, as reflected in the header comment of GMEVROBS.pls (version 120.2). As a PVT-classified API, it is intended for internal use by Oracle Process Manufacturing components and is not published as a public integration interface, though it can be called from custom code with appropriate care. The package encapsulates the validation logic required to determine whether a batch may be reopened, which is the central governance point for the operation.

Key Procedures and Functions

The package specification documents three callable program units:

• REOPEN_BATCH — The main procedure that performs the reopen operation. It accepts a batch header record as input, along with an option controlling whether batch steps are also reopened, and returns the updated batch header record and a return status. It is the entry point that executes the state change on the batch.
• IS_BATCH_POSTED — A function that determines whether a batch, or a specific material detail line within a batch, has already been posted. This is a prerequisite check, since a posted batch has accounting and inventory implications that must be considered before reopening.
• IS_PERIOD_OPEN — A boolean function that accepts a batch identifier and reports whether the accounting period associated with that batch is currently open. This is the function most directly relevant to users searching on "is_period_open," because reopening a batch is only meaningful when the relevant period permits the corresponding transactions and cost adjustments.

A fourth function, CREATE_HISTORY, appears in the header comment but is commented out in the specification and is therefore not part of the callable interface.

Tables Accessed

The package operates against a defined set of OPM tables accessed through APPS synonyms. GME_BATCH_HEADER holds the batch master record that is read and updated during reopening. GME_MATERIAL_DETAILS stores the material transaction lines associated with the batch and supports the posting check used by IS_BATCH_POSTED. GMF_PERIOD_STATUSES is the source of period open/closed state used by IS_PERIOD_OPEN. Costing data is read from CM_ACST_LED and CM_CMPT_DTL, which carry the actual cost ledger and component detail required to evaluate the accounting impact of the change. GME_BATCH_HISTORY and GME_BATCH_STEP_ITEMS record the audit trail and the step-level structure of the batch, supporting the optional reopen of steps and historical traceability. PLITBLM is an OPM utility table used in the supporting logic.

Usage Notes

GME_REOPEN_BATCH_PVT is a private package referenced by two other packages within the OPM application, which indicates it is invoked indirectly from higher-level batch management flows rather than directly from standard forms or concurrent programs. In practice it is reached during batch correction scenarios, such as when a closed batch must be adjusted because of a production or costing error. Custom deployments that need to reopen a batch should treat the package as unsupported for direct invocation and should instead use supported batch-management functionality where available. When IS_PERIOD_OPEN is called directly, the returned boolean is typically used as a gate before attempting a reopen, ensuring that the target accounting period is open and that postings will not fail or misstate the ledger. Because the package is compiled with the 120.2 header and predates later releases, its behavior should be validated against the specific 12.1.1 or 12.2.2 instance before reliance in production customizations.