Search Results gen_cost_based_revenue

Overview

PA_FP_REV_GEN_PUB is a public PL/SQL package in the APPS schema that supports Oracle Projects financial plan revenue generation. In the Oracle E-Business Suite 12.1.1 and 12.2.2 releases, the package is classified as a published (PUB) API, meaning the procedures it exposes are intended for supported, direct invocation rather than as private internal utilities. Its core business function is to derive and generate revenue plan amounts for projects and tasks based on cost, and to synchronize resource schedule data into the budget line infrastructure used by financial plans. The package therefore sits at the intersection of project financial planning, budgeting, and revenue recognition, providing the programmatic logic that converts resource-level cost or assignment information into the revenue figures displayed in revenue plans.

The package body is currently VALID in the APPS schema. It is referenced by two other database objects, but is not itself referenced by any database object, which is consistent with its role as a top-level entry point invoked by concurrent programs, forms, or custom extensions rather than as a low-level dependency called from other packages.

Key Procedures and Functions

Two documented program units are exposed by this package:

• GEN_COST_BASED_REVENUE — Generates revenue for a financial plan on a cost basis. This procedure applies revenue generation rules to cost data, producing the revenue amounts associated with a project's financial plan. It relies on supporting utilities such as PA_FP_GEN_AMOUNT_UTILS and PA_FP_GEN_BILLING_AMOUNTS to calculate amounts, and interacts with currency and resource assignment infrastructure to convert and align cost values to the revenue plan.
• PUSH_RES_SCH_DATA_TO_BL — Pushes resource schedule data into budget line records. This procedure transfers resource assignment and schedule information into the budget line tables, ensuring that the revenue plan's underlying budget lines reflect the current resource schedule. This is essential when resource assignments change and the revenue plan must be regenerated consistently.

Parameter lists are intentionally not reproduced here; callers should consult the package specification and the Oracle Projects API documentation for exact signatures.

Tables Accessed

The package reads and writes a range of Oracle Projects tables through APPS synonyms. Budget-related data is held in PA_BUDGET_VERSIONS, PA_BUDGET_LINES, and PA_BUDGET_LINES_S (the shadow table for the budget lines). Financial plan type configuration is drawn from PA_FIN_PLAN_TYPES_B and PA_PROJ_FP_OPTIONS. Project and task reference data comes from PA_PROJECTS_ALL, PA_TASKS, and PA_PROJECT_OPP_ATTRS. Resource assignment and currency information is sourced from PA_RESOURCE_ASSIGNMENTS, PA_RESOURCE_ASGN_CURR, and the temporary table PA_RESOURCE_ASGN_CURR_TMP. Working or intermediate rollup data is staged in PA_FP_ROLLUP_TMP, and PLITBLM is used in the generation of revenue line items. Together these tables supply the project, task, resource, currency, and plan configuration inputs needed to compute and persist cost-based revenue.

Usage Notes

PA_FP_REV_GEN_PUB is typically invoked in the context of Oracle Projects financial planning operations, either from a form that manages revenue plans or from a concurrent program that regenerates plan amounts. Custom code that must reproduce or extend the standard cost-based revenue generation logic can call GEN_COST_BASED_REVENUE directly, provided the standard validation and initialization conventions of Oracle's PUB APIs are followed. Because the package depends on FND_API, FND_MSG_PUB, FND_GLOBAL, and FND_PROFILE, calling sessions should be initialized with the correct application, responsibility, and user context before invocation, and should inspect the standard message stack for errors. PUSH_RES_SCH_DATA_TO_BL is used when resource schedule changes must be reflected in budget lines before revenue is regenerated. As with any Oracle EBS public API, direct updates to the underlying tables should be avoided in favor of these documented entry points to preserve data integrity and upgrade compatibility.