Search Results alloc_errors

Overview

PA_ALLOC_RUN is the core PL/SQL package body in Oracle Projects responsible for executing allocation rules that redistribute expenditures, raw costs, and burdened amounts across projects, tasks, and general ledger accounts. In Oracle EBS 12.1.1 and 12.2.2, allocations are a standard costing mechanism used to spread shared costs—such as overhead, indirect labor, or pooled expenses—from a source or basis to one or more target projects and tasks according to user-defined rule definitions maintained in PA_ALLOC_RULES_ALL. The package encapsulates the full allocation lifecycle: validating the selected rule, building the run's source and target populations, computing basis and target amounts, generating target and offset transactions, and recording exceptions and errors when data conditions prevent successful processing.

Because the object is a package body, its procedures are invoked internally through the package specification or by other Projects modules rather than directly by end users. The package is heavily dependent on the current run context—rule identifier, run identifier, request identifier, organization, and currency conversion setup—which are cached in package-level global variables and database session state.

Key Procedures and Functions

The package exposes 50 documented procedures and functions. The primary driver, ALLOCATION_RUN, orchestrates the entire allocation process. Supporting procedures manage the run lifecycle: CHECK_LAST_RUN_STATUS verifies that a prior run is not still processing, INSERT_ALLOC_RUNS and INSERT_ALLOC_RUN_SOURCES create the run header and source records, while POPULATE_RUN_SOURCES and POPULATE_RUN_TARGETS build the sets of source and target projects/tasks participating in the run. INSERT_ALLOC_RUN_TARGETS persists these resolved targets.

Calculation logic is handled through CALCULATE_SRC_GL_AMOUNTS, INSERT_ALLOC_RUN_GL_DET, GET_TRG_LINE_PROJ_TASK_COUNT, GET_SUNK_COST, and GET_PREVIOUS_ALLOC_AMNT, which collectively derive basis amounts, prior allocations, and denominator values used to apportion costs. Transaction generation is performed by CREATE_TARGET_TXNS, CREATE_OFFSET_TXNS, INSERT_ALLOC_TXN_DETAILS, and ALLOCATE_REMNANT, which writes the resulting distribution entries and handles any residual or rounding amounts. VALIDATE_RULE confirms that the allocation rule definition is complete and internally consistent before processing begins.

The procedures most relevant to the search term "alloc_errors" are ALLOC_ERRORS and INS_ALLOC_EXCEPTIONS, which capture and log problems encountered during a run—missing costs, invalid targets, zero denominators, or unmatched basis setup—so that they can be reviewed and corrected.

Tables Accessed

The package reads and writes a broad set of Projects and General Ledger tables through APPS synonyms. PA_ALLOC_RULES_ALL holds the rule definitions that drive processing. PA_ALLOC_RUNS, PA_ALLOC_RUNS_ALL, and PA_ALLOC_RUNS_S store the run headers and their statuses. Basis and result detail are persisted in PA_ALLOC_RESOURCES, PA_ALLOC_RUN_SOURCES, PA_ALLOC_RUN_BASIS_DET, PA_ALLOC_RUN_RESOURCE_DET, PA_ALLOC_RUN_GL_DET, PA_ALLOC_GL_LINES, and PA_ALLOC_RUN_TARGETS.

Exception handling writes to PA_ALLOC_EXCEPTIONS and PA_ALLOC_MISSING_COSTS. GL integration relies on GL_BALANCES, GL_PERIODS, and GL_PERIOD_STATUSES to determine valid open periods and account balances for allocation basis calculations.

Usage Notes

PA_ALLOC_RUN is normally invoked by the Projects allocation concurrent programs, such as the PRC: Generate Allocations process, and by related forms in Oracle Projects. It is referenced by four other packages, confirming it serves as a shared internal engine rather than a standalone API. Custom code should not call the package body directly; supported extension is achieved through the allocation rules configuration and standard concurrent requests. When troubleshooting, the "alloc_errors" search term points to ALLOC_ERRORS and INS_ALLOC_EXCEPTIONS, and the resulting rows in PA_ALLOC_EXCEPTIONS and PA_ALLOC_MISSING_COSTS should be reviewed alongside the concurrent request log to identify the failing rule, run, and data condition.