Search Results qp_validate_seg




Overview
Explore in AI Chat

Overview

QP_VALIDATE_SEG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the Advanced Pricing (QP) module. Its business purpose is to enforce validation logic over pricing entities and their associated attributes — most notably pricing qualifiers, limits, and limit attributes — before those records are committed to the database. Advanced Pricing relies on a complex web of qualifier and attribute combinations to determine which price lists, modifiers, and formulas apply to a given transaction line. QP_VALIDATE_SEG acts as a guard: it verifies that attribute values and their relationships are internally consistent, and it supports deletion (cascade or cleanup) of dependent records.

The package is part of the public/private API layer around QP_ATTRIBUTES_PUB and QP_ATTRIBUTES_PVT. Its dependency list confirms it calls FND_API for the standard Oracle API error and message stack, and it is referenced by QP_ATTRIBUTES_PVT, which suggests it functions as a supporting validator invoked from the attributes public/private API stack rather than being called directly by end-user flows.

Key Procedures and Functions

  • ENTITY — Validates an entity (qualifier-level) record. Used to confirm that the qualifying entity for a pricing rule, limit, or context is structurally valid before it is stored or processed.
  • ATTRIBUTES — Validates attribute values tied to a qualifier or pricing entity. This is the core validation routine, checking that attribute definitions and their assigned values conform to expected constraints.
  • ENTITY_DELETE — Handles validation and cleanup logic when an entity is deleted, ensuring related attribute and limit records are not orphaned and that deletion is permitted by current data state.

All three are documented as procedures/functions but specific parameter signatures are not published in the ETRM metadata; they should be treated as internal API entry points. Typical convention (per FND_API standards) includes passing an p_init_msg_list flag and returning message/return-status outputs, but the actual signatures must be confirmed by inspecting the package specification in the target instance.

Tables Accessed

The package reads (and in delete paths, removes from) these tables through APPS synonyms:

  • QP_LIMITS — Pricing limit definitions; validated for consistency before activation or deletion.
  • QP_LIMIT_ATTRIBUTES — Attributes belonging to a limit; must be validated against limit rules, and cleaned up when a limit or entity is deleted.
  • QP_PRC_CONTEXTS_B — Pricing context definitions; the entity validator checks context associations used to qualify pricing rules.
  • QP_PRICING_ATTRIBUTES — Master definitions of pricing attributes; used to verify supplied attribute values map to valid, enabled attribute definitions.
  • QP_QUALIFIERS — Qualifier definitions (groups of attributes); validated as part of entity validation.

These tables form the metadata backbone of Advanced Pricing — qualifiers define which attribute combinations apply, contexts scope them, and limits restrict them. Validation here prevents inconsistent metadata from reaching pricing engine evaluation.

Usage Notes

QP_VALIDATE_SEG is not typically invoked directly by end users. It is called internally by the Advanced Pricing attribute API stack — specifically QP_ATTRIBUTES_PVT and the public QP_ATTRIBUTES_PUB layer — when qualifiers, attributes, or limits are created, updated, or deleted through the Pricing Administration forms and the corresponding APIs. It may also be reached from concurrent programs that mass-maintain or migrate pricing metadata, and from custom integrations that manipulate QP qualifier and limit records programmatically.

Because it depends on FND_API, callers should be prepared to read the standard FND message stack for errors when validation fails. Custom code should invoke the higher-level QP_ATTRIBUTES_PUB APIs rather than QP_VALIDATE_SEG directly, preserving Oracle-supplied validation and upgrade stability across both 12.1.1 and 12.2.2 releases. No differences in this package's documented behavior are recorded between those two versions in the ETRM metadata.