Search Results determine_transfer_price

Overview

APPS.PA_CC_TP_CLIENT_EXTN is a client extension package body within the Oracle E-Business Suite Projects suite, specifically associated with the transfer price determination flow used by Project Costing and cross-charge processing. Its role is to provide a controlled extension point through which customers and implementers can influence how transfer prices are derived between a provider organization and a receiver organization for a given expenditure item. The package is structured around the two phases of the transfer pricing lifecycle: a pre-client extension and a post-client extension. The pre-client extension, implemented by the Determine_Transfer_Price procedure, is invoked before the standard transfer price logic executes, allowing the extension to supply or prime pricing values. The post-client extension, implemented by Override_Transfer_Price, is invoked after the standard logic, allowing an installation to override the values that the core process computed. In the delivered baseline the package is a stub: all output parameters are initialized to null or zero, so the standard transfer pricing engine behaves exactly as Oracle shipped it until a customer implements custom logic. The header comment indicates the source file PAPTPRCB.pls at version 120.1, with the standard "noship" designation used for non-shipped, customer-extensible objects.

Key Procedures and Functions

The package exposes two documented procedures, both classified as APIs (OTHER).

• Determine_Transfer_Price — The pre-client extension. It represents the hook executed before the standard transfer price calculation for an expenditure item. It accepts a comprehensive set of input parameters describing the transaction context, including the transaction type, provider and receiver organization identifiers, expenditure organization, expenditure item and its type and class, task, project, quantity, and the person incurring the cost. It returns the determined denominator transfer price, the denominator transfer price currency code, the transfer price bill rate, the transfer price bill markup percentage, together with an error message and a status indicator. In the shipped stub all outputs are set to null (and status to zero), meaning no value is contributed by the extension.
• Override_Transfer_Price — The post-client extension. It is invoked after the standard transfer price logic has executed, and is intended to let an installation override the calculated transfer price values. Its input parameter list mirrors the context supplied to the pre-extension procedure. In the documentation excerpt the parameter list is truncated, but its purpose is to modify the final pricing outcome rather than to seed initial values.

Tables Accessed

The ETRM metadata does not document any tables referenced directly by this package through APPS synonyms. Because the delivered package body is a stub containing only assignment statements and no SQL, it performs no direct reads or writes against project or cross-charge tables. Any data access occurs only when a customer implements custom logic inside the two extension procedures; such logic would typically query or update transfer price, expenditure, and organization-related tables, but none of this is part of the delivered object.

Usage Notes

PA_CC_TP_CLIENT_EXTN is not invoked directly by end users. It is called by the core transfer pricing engine during cross-charge and transfer price processing, which in turn can be triggered from expenditure processing flows, cost distribution, and related concurrent programs. The metadata records that the package is referenced by one other package, consistent with the core engine calling these hooks. Implementers customize behavior by editing the package body and inserting business logic into Determine_Transfer_Price and Override_Transfer_Price. Because the package is marked noship, it is expected to be regenerated or preserved across patches and upgrades, and any customizations placed in it must be re-applied or migrated carefully. The status and error message output parameters provide the standard mechanism for signaling failure back to the calling engine, so custom implementations should set them consistently to avoid silent processing errors.