Search Results get_list_price

Overview

APPS.CTO_CUSTOM_LIST_PRICE_PK is a configuration-to-order (CTO) pricing hook package in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its business purpose is to determine the list price that should be applied to a configured item (the "config item") before that configuration item has actually been created in inventory. Because the config item does not yet exist at the time pricing is evaluated, the package resolves pricing from the model item and the options selected on the sales order line rather than from the finished configuration. The package is delivered by Oracle as a stub — its sole documented function returns NULL — and is intended explicitly as a customization extension point. Oracle's own header comment states that the function "can be replaced by custom code that will calculate the price list for this configuration." This design allows implementers to inject customer-specific pricing logic into the CTO order flow without modifying seeded pricing APIs.

The package is classified in the ETRM metadata as an OTHER API, owner APPS, and is referenced by one other package in the EBS code base, indicating it is invoked by the standard CTO/pricing integration rather than called directly by end users.

Key Procedures and Functions

The package exposes exactly one documented function:

• GET_LIST_PRICE — Accepts a model line identifier from OE_ORDER_LINES_ALL, an inventory item identifier, and an organization identifier, and returns a numeric list price value. The organization identifier exists because price lists in Oracle Advanced Pricing may be organization-dependent. The function is expected to return NULL when no custom logic applies; in that case Oracle defaults the model's list price to the configuration item as well. As shipped, the body immediately returns NULL, effectively disabling the hook and deferring to standard pricing behavior.

No other procedures or functions are documented in the package specification or body. Parameter lists are intentionally not reproduced here; the documented signature consists of the three inbound identifiers and a single numeric return.

Tables Accessed

The ETRM metadata lists no tables referenced through APPS synonyms by this package body. In its shipped form the function contains no SQL at all — it simply returns NULL. Any table access would therefore be entirely a function of customer-supplied replacement logic. A custom implementation would typically query OE_ORDER_LINES_ALL (to read the model line and its associated option lines) and Oracle Advanced Pricing structures such as QP_LIST_HEADERS and QP_LIST_LINES, along with organization and item attribute data, in order to derive a price. Because these accesses are not part of the delivered package, they carry no seeded dependency footprint and must be validated independently during upgrades.

Usage Notes

GET_LIST_PRICE is invoked during CTO order entry, specifically at the point where configuration pricing is being determined and before the configuration item is instantiated. It is called internally by another EBS package rather than from a form or concurrent program directly, so the integration point is the seeded call site, not a user interface element.

Implementers use this package as a supported customization seam: the delivered stub is replaced (via a custom version of the package body) with logic that computes a configuration-specific list price. Typical drivers include configuration-dependent surcharges, customer-specific price list selection, or attribute-based pricing that the standard pricing engine cannot resolve for an uncreated item.

Key cautions when customizing: returning NULL preserves standard behavior, so existing implementations should be preserved on upgrade; the package body carries a version header ($Header: CTOCULPB.pls 115.3), and Oracle EBS 12.1.1 and 12.2.2 online patching places customized package bodies in the standard custom-schema discipline. Because the function runs inside the pricing call path, performance and exception safety matter — unhandled errors or excessive queries can slow or fail order entry. Any custom logic should be regression-tested after pricing or CTO patches, since a single referencing package depends on this hook.