Search Results get_target_price




Overview
Explore in AI Chat

Overview

APPS.POA_CUSTOMIZATION_PKG is a customization gateway package in the Oracle E-Business Suite procurement module (Oracle Purchasing / ETRM). It is classified in the ETRM repository as an "OTHER" API rather than a formal public interface, which signals that its primary design intent is to be extended or overridden by customers rather than consumed as a stable, versioned integration point. The package body header (poacustb.pls, version 120.0, dated 2005/06/01) indicates it has been carried forward largely unchanged from the 11i code line into Oracle EBS 12.1.1 and 12.2.2.

The package's business purpose is to centralize points of extensibility within the purchasing and receiving data model. Rather than forcing customers to modify seeded Oracle code, Oracle exposes stub logic inside this package where customers can insert their own classification, derivation, or pricing rules. The best-documented example is purchase classification, which allows an organization to tag purchasing entities—such as Production versus Non-Production items—using an extensible lookup. The package is referenced by four other packages, confirming that several downstream programs in the procurement stack call into it, so any customer modification affects a shared code path across multiple features.

Key Procedures and Functions

ETRM documents two callable units in this package:

  • PURCHASE_CLASSIFICATION_CODE — Returns a purchase classification code for a given procurement entity. It accepts a primary key value and a primary key type that together identify the base table entity (for example, a supplier performance line, a PO distribution, or a receiving transaction), and it looks up the corresponding code in the PO_LOOKUP_CODES table where the lookup type is the user-defined "Purchase Classification" lookup. Oracle seeds this lookup with Production and Non-Production codes, but customers may add their own lookup codes. The function body is intentionally empty by default, with a comment marking where customer logic belongs. It is invoked from Supplier Performance (against PO_LINE_LOCATIONS_ALL), PO Distributions (against PO_DISTRIBUTIONS_ALL), and Receiving (against RCV_TRANSACTIONS).
  • GET_TARGET_PRICE — The user's search term. GET_TARGET_PRICE is the second documented entry point and follows the same customization-gateway pattern: it provides a seeded stub where customers implement their own target-price derivation logic for procurement documents. ETRM does not publish a detailed parameter list for this function, so its signature should not be assumed; customers should query ALL_ARGUMENTS or open the package source in the EBS instance to confirm its interface before writing dependent code.

Tables Accessed

The ETRM metadata shows no directly documented table references via APPS synonyms, but the source excerpt confirms the package reads the lookup table PO_LOOKUP_CODES for classification codes. In practice, customer customizations of PURCHASE_CLASSIFICATION_CODE frequently join to the base tables named in the comments—PO_LINE_LOCATIONS_ALL, PO_DISTRIBUTIONS_ALL, and RCV_TRANSACTIONS—to resolve the entity being classified. GET_TARGET_PRICE implementations typically read pricing-related purchasing tables, but no specific table access is documented.

Usage Notes

This package is not typically invoked directly from a form or concurrent program by end users. Instead, it is called programmatically by the four referencing packages during purchasing, supplier performance, and receiving flows. Because the seeded function bodies are effectively placeholders, standard usage involves a customer extending the package body in a custom or cloned schema and deploying it as an APPS-owned override, a common but upgrade-risky practice in EBS. In 12.1.1 and 12.2.2, the AD "preserve customizations" behavior for package bodies is limited, so customized logic can be lost during patching. Organizations should therefore keep a version-controlled copy of their customized body, retest after every procurement patch or family pack, and validate results through the calling features rather than through direct invocation. Where the customization is purely classification, the supported alternative is to seed new lookup codes against "Purchase Classification" and avoid source modification altogether.