Search Results get_pa_step_status
Overview
APPS.GL_PA_AUTOALLOC_PKG is a PL/SQL package body in Oracle E-Business Suite that provides a thin wrapper layer over the internal PA_GL_AUTOALLOC_PKG package. Its principal purpose is to expose allocation-related services that bridge Oracle Projects (PA) and Oracle General Ledger (GL) during automated allocation processing. In the EBS architecture, allocations defined in Oracle Projects (via allocation rules and allocation sets) generate journal entries that must be passed to and processed within General Ledger. This package coordinates the submission of allocation requests, validates the run period against the allocation set, determines the applicable period type, and manages the status and history records associated with an allocation run.
The package is registered with an API classification of OTHER and is owned by the APPS schema. It is referenced by four other packages, indicating that it functions as a shared utility within the allocation processing flow rather than as an end-user entry point. The header comment ($Header: glalprjb.pls 120.2 ...) shows that the source has been stable since the 11i-era codebase, and it remains present in both 12.1.1 and 12.2.2. Notably, the version stored in the EBS 12.2.2 file system is delivered as part of the standard APPS code installation and is not expected to be customized.
Key Procedures and Functions
The package exposes five documented program units. Each delegates to the underlying PA_GL_AUTOALLOC_PKG, adding only argument marshalling and, in one case, a database update.
- GET_PERIOD_TYPE — A function that accepts an allocation set identifier and returns the period type (for example, a GL or PA period indicator) associated with that allocation set. It is used to determine whether the allocation runs on a GL period basis or a PA period basis.
- VALID_RUN_PERIOD — A function that validates whether a given allocation set can be run for the specified PA period and/or GL period. It returns a Boolean result and is typically called before submitting an allocation request to prevent invalid period combinations.
- SUBMIT_ALLOC_REQUEST — The central function of the package. It accepts a rule identifier, an expenditure item date, a PA period, and a GL period, and returns the concurrent request identifier of the submitted allocation request. This is the procedure users reach when they search for "submit_alloc_request," and it is the mechanism by which the allocation concurrent program is launched programmatically.
- GET_PA_STEP_STATUS — A procedure that retrieves the status of a particular step within an allocation run, given the request identifier, step number, and mode. It returns the status through an OUT parameter and allows callers to monitor multi-step allocation processing.
- UPD_GL_AUTOALLOC_BATCH_HIST — A procedure that updates GL_AUTO_ALLOC_BATCH_HISTORY, setting the PA allocation run identifier for a given request and step. It returns a return code indicating whether the target row was found and updated.
Tables Accessed
The only table directly referenced in the package body is GL_AUTO_ALLOC_BATCH_HISTORY, accessed through an APPS synonym. The package performs an UPDATE against this table in UPD_GL_AUTOALLOC_BATCH_HIST, matching on request_id and step_number and writing the pa_allocation_run_id value. This table stores the historical linkage between a GL allocation batch and its corresponding PA allocation run, and the update enables the allocation process to record or correct that linkage after a run has been submitted. Additional data access occurs indirectly through the delegated calls into PA_GL_AUTOALLOC_PKG, which manages the underlying allocation rules, sets, and period definitions.
Usage Notes
This package is normally invoked in one of three contexts. First, from Oracle Projects or Oracle General Ledger forms that initiate allocation processing, where SUBMIT_ALLOC_REQUEST launches the allocation concurrent program and returns the request ID for tracking. Second, from concurrent program logic that monitors allocation step status through GET_PA_STEP_STATUS and records run identifiers via UPD_GL_AUTOALLOC_BATCH_HIST. Third, from custom PL/SQL code that needs to automate allocation submissions, for example in a scheduled interface or extension. Because it wraps an internal package, customizations should call GL_PA_AUTOALLOC_PKG rather than PA_GL_AUTOALLOC_PKG directly, and any call to SUBMIT_ALLOC_REQUEST should be preceded by a VALID_RUN_PERIOD check to avoid submitting requests for invalid period combinations. As with all APPS-owned code, the package body should not be modified; extensions should be implemented in a separate custom package that invokes the documented entry points.
-
PACKAGE BODY: APPS.GL_PA_AUTOALLOC_PKG
12.2.2
-
PACKAGE BODY: APPS.GL_PA_AUTOALLOC_PKG
12.1.1
-
PACKAGE: APPS.GL_PA_AUTOALLOC_PKG
12.1.1
-
PACKAGE: APPS.GL_PA_AUTOALLOC_PKG
12.2.2
-
PACKAGE: APPS.PA_GL_AUTOALLOC_PKG
12.2.2
-
PACKAGE: APPS.PA_GL_AUTOALLOC_PKG
12.1.1
-
PACKAGE BODY: APPS.PA_GL_AUTOALLOC_PKG
12.1.1
-
PACKAGE BODY: APPS.PA_GL_AUTOALLOC_PKG
12.2.2
-
APPS.PA_GL_AUTOALLOC_PKG dependencies on PA_GL_AUTOALLOC_PKG
12.2.2
-
APPS.PA_GL_AUTOALLOC_PKG dependencies on PA_GL_AUTOALLOC_PKG
12.1.1