Search Results create_credit_receivers

Overview

PA_BILLING_SETUP_PVT is a private PL/SQL package in the Oracle Projects (PA) application, owned by the APPS schema. Its source header identifies it as PABLSTVS.pls, last updated in release 12.1.x lineage, and carries forward unchanged into 12.2.2 as a private (PVT) API classification. The package encapsulates the setup and maintenance logic for project billing and revenue configuration, including billing assignments — the rules that determine how a project distributes billing across employees, jobs, and organizations — and credit receivers, the parties designated to receive credit (cost credit, revenue credit) on a project. By centralizing this logic behind a private PL/SQL interface, the package allows Oracle Projects forms and internal processes to validate and persist billing setup data consistently, applying the standard Oracle EBS API conventions (FND_API.G_FALSE/G_TRUE commit and validation flags, message stack outputs x_return_status, x_msg_count, and x_msg_data).

Key Procedures and Functions

The ETRM documentation lists seven procedures, all of which follow the private API pattern of accepting a commit flag, a validate-only flag, and returning status information through OUT parameters. Parameter lists are not reproduced here; the source excerpt confirms the pattern for UPDATE_REVENUE_AND_BILLING.

• UPDATE_REVENUE_AND_BILLING — Updates the revenue and billing configuration for a project, including distribution rule, billing cycle, first bill offset, next billing date, output tax code, invoice comment, retention settings, and labor/non-labor identifiers. This is the only procedure whose full parameter documentation is present in the source excerpt.
• CREATE_CREDIT_RECEIVERS — Creates credit receiver records for a project, defining which parties receive credit and in what proportion. This procedure is directly relevant to the search term "create_credit_receivers".
• UPDATE_CREDIT_RECEIVERS — Modifies existing credit receiver assignments, including credit percentages and effective dates.
• DELETE_CREDIT_RECEIVERS — Removes credit receiver records from a project, typically when the credit split is being redefined or the receiver is no longer applicable.
• CREATE_BILLING_ASSIGNMENTS — Creates billing assignment rows that govern how billing amounts are allocated across project roles or resources.
• UPDATE_BILLING_ASSIGNMENTS — Updates existing billing assignment rows.
• DELETE_BILLING_ASSIGNMENTS — Deletes billing assignment rows.

Tables Accessed

The package reads and writes the following tables through APPS synonyms:

• PA_BILLING_ASSIGNMENTS_ALL / PA_BILLING_ASSIGNMENTS_S — The multi-org base table and its security (ROWID) shadow table, holding billing assignment definitions.
• PA_CREDIT_RECEIVERS / PA_CREDIT_RECEIVERS_S — The base and security tables storing credit receiver records created and maintained by the credit receiver procedures.
• PA_PROJECTS / PA_PROJECTS_ALL — The project master and multi-org tables, read to validate the project context and ownership of the billing setup data.
• PA_PROJECT_TYPES — Read to validate project type attributes that constrain which billing and revenue rules are permissible.
• DUAL — Used for lightweight validation and default-value queries.

Usage Notes

Because PA_BILLING_SETUP_PVT is a private package, it is not intended for direct invocation by external or customer-written code; Oracle supports only public APIs for extensions. The package is referenced by one other documented package, consistent with its role as an internal building block called by public billing and project setup APIs and by Oracle Projects forms such as the Billing Setup and Credit Receivers windows. Developers tracing "create_credit_receivers" should note that the supported public entry point for creating credit receivers lies outside this private package; PA_BILLING_SETUP_PVT supplies the underlying implementation. When validating changes, the validate-only flag (default FND_API.G_TRUE) permits dry-run validation without committing, and callers must inspect x_return_status before proceeding. In 12.1.1 and 12.2.2 the interface is functionally equivalent, though the 12.2.x multi-org architecture emphasizes the _ALL and _S table variants accessed here.