Search Results check_project_template




Overview

PA_FUNDING_CORE is the central PL/SQL package within the Oracle EBS Project Accounting (PA) module responsible for validating, creating, maintaining, and summarizing project funding records. Funding records establish the link between a customer agreement and the projects or tasks that the agreement is permitted to finance, and they govern how revenue accrued or billed against a project is covered by allocated funds. The package is declared with AUTHID CURRENT_USER, meaning its SQL executes under the privileges of the calling user rather than the package owner, which is significant for installations that have customized funding-related responsibilities or grants.

The package encapsulates the bulk of the business rules that Oracle Projects enforces when users define or modify funding at the project, task, and agreement levels. These rules include ensuring that sufficient funds exist to cover amounts already accrued or billed, preventing level changes (project-level versus task-level funding) when contradictory events or revenue distributions exist, and validating that template projects conform to restrictive funding conventions. As an API-classified object of type OTHER, it is intended primarily for internal consumption by Oracle Projects forms, concurrent programs, and other PA packages rather than as a fully public integration surface.

Key Procedures and Functions

The documented interface comprises twenty-six procedures and functions. The validation routines include CHECK_FUND_ALLOCATED, which determines whether any funds have been allocated for a given agreement; CHECK_ACCRUED_BILLED_BASELINED, which enforces that total allocated funding is not less than the amount already accrued or billed; CHECK_VALID_PROJECT, which confirms that a project is valid for a given customer and agreement; CHECK_VALID_TASK, which verifies a task belongs to the appropriate project structure; and CHECK_PROJECT_TEMPLATE, which restricts funding of template projects to a single agreement with a one hundred percent customer bill split. Additional checks — CHECK_TASK_FUND_ALLOWED, CHECK_PROJECT_FUND_ALLOWED, CHECK_PROJECT_TYPE, CHECK_PROJ_AGR_FUND_OK, VALIDATE_LEVEL_CHANGE, CHECK_LEVEL_CHANGE, and the internal CHECK_PROJ_TASK_LVL_FUNDING — collectively govern whether funding may be established at a given level and whether level transitions are permissible.

The retrieval function GET_FUNDING_ID returns the funding identifier for a given funding reference. The maintenance routines CREATE_FUNDING, UPDATE_FUNDING, DELETE_FUNDING, and LOCK_FUNDING perform the corresponding DML and concurrency operations on funding records, with DELETE_FUNDING being the object most closely associated with the user's search term. The summary routines SUMMARY_FUNDING_INSERT_ROW and SUMMARY_FUNDING_UPDATE_ROW maintain the denormalized PA_SUMMARY_PROJECT_FUNDINGS table, which supports reporting and inquiry performance.

Tables Accessed

The package reads and writes PA_PROJECT_FUNDINGS, the base transaction table for funding records, and maintains PA_SUMMARY_PROJECT_FUNDINGS as its summarized counterpart. Agreement context is drawn from PA_AGREEMENTS and PA_AGREEMENTS_ALL, while project and task validation relies on PA_PROJECTS, PA_PROJECTS_ALL, and PA_PROJECT_TYPES with its _ALL variant. Accrual and billing comparisons referenced in the validation logic draw on PA_EVENTS and PA_EXPENDITURE_ITEMS. DUAL is used for single-row evaluations. All references are resolved through APPS synonyms.

Usage Notes

PA_FUNDING_CORE is invoked by the Oracle Projects funding forms, by concurrent processes that rebuild or reconcile funding summaries, and by five other PL/SQL packages within the application. Custom code should call the documented functions rather than issuing direct DML against PA_PROJECT_FUNDINGS, because the validation routines encapsulate constraints — particularly the accrued/billed coverage rule and the project-versus-task level restrictions — that direct manipulation would bypass. In 12.1.1 and 12.2.2 the package header signature is stable; note that CHECK_PROJ_TASK_LVL_FUNDING is defined twice, once commented out and once active, so only the current definition should be referenced.