Search Results ozf_claim_types_all_b_s

Overview

OZF_CLAIM_TYPE_PVT is the private application programming interface (API) packaging layer for Claim Type maintenance within the Oracle E-Business Suite Trade Management (formerly Oracle Trade Management, module prefix OZF) product family. Claim Types define the classification of deduction and claim records that trading partners and internal users raise against funds, promotions, and accruals. This package encapsulates the business logic, validation rules, and multi-row processing required to create, modify, and remove Claim Type definitions stored in the OZF_CLAIM_TYPES_ALL_B and OZF_CLAIM_TYPES_ALL_TL base tables. As the "PVT" suffix indicates, it is a private companion to the public Claim Type API surface, intended to be invoked only through the supported public interfaces (for example OZF_CLAIM_TYPES_ALL_PKG) rather than called directly by customers. It relies on the Oracle Application Object Library (FND_API for the standard API return-status contract, FND_MESSAGE and FND_MSG_PUB for message token handling, and FND_GLOBAL for session context), and on JTF_PLSQL_API and OZF_UTILITY_PVT for shared utility routines. The package is documented as a PVT-classified API and forms part of the broader deduction and claims settlement flow within Oracle EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented interface exposes eight procedures and functions:

• CREATE_CLAIM_TYPE — Creates a new Claim Type record, applying the package's standard validation logic before inserting into the base and translation tables.
• UPDATE_CLAIM_TYPE — Modifies the attributes of an existing Claim Type, preserving the API return-status contract used throughout the ETRM APIs.
• DELETE_CLAIM_TYPE — Removes or logically retires a Claim Type definition, subject to referential checks.
• VALIDATE_CLAIM_TYPE — Performs the core validation rules for a Claim Type (required attributes, uniqueness, and business constraints) and returns the outcome to callers.
• CHECK_CLAIM_TYPE_ITEMS — Checks dependent items or child associations tied to a Claim Type, ensuring integrity before a create, update, or delete operation proceeds.
• CHECK_CLAIM_TYPE_RECORD — Verifies that a specific Claim Type record exists and is eligible for the requested operation.
• INIT_CLAIM_TYPE_REC — Initializes the internal Claim Type record structure, establishing defaults and null-handling state prior to attribute population.
• COMPLETE_CLAIM_TYPE_REC — Finalizes the record structure, applying derived or defaulted values before persistence or return to the caller.

Tables Accessed

Through APPS-owned synonyms, the package reads and writes the following documented objects:

• OZF_CLAIM_TYPES_ALL_B_S — The base-table synonym for Claim Type definitions; the primary insert/update/delete target of the create, update, and delete routines. This is also the object referenced in the user's search term.
• OZF_CLAIMS — The claims transaction table; referenced for validation to determine whether a Claim Type is in use and therefore protected from deletion.
• AMS_APPROVAL_DETAILS — The marketing approvals detail table; consulted for approval-related checks relevant to Claim Type lifecycle actions.
• DUAL — Used for single-row expression evaluation within the package's PL/SQL logic.

The package additionally depends on the OZF_CLAIM_TYPES_ALL_PKG, OZF_CLAIM_TYPES_VL, OZF_FUNDS_UTILIZED_VL, and OE_TRANSACTION_TYPES_VL views for the wider Claim Type data model and order/transaction type cross-references.

Usage Notes

OZF_CLAIM_TYPE_PVT is not referenced by any other database object (per the documented dependency report), which confirms its status as an internal implementation package invoked conditionally by its public API counterparts. In practice it is exercised when a user maintains Claim Types through the Trade Management setup and administration forms, or when integration code calls the supported public Claim Type API, which then delegates to these private routines. Customizations should never call OZF_CLAIM_TYPE_PVT directly; doing so bypasses unsupported entry points and risks data-integrity issues, since the supported contract is exposed only through the public API layer. When troubleshooting Claim Type creation or deletion failures, review the FND_MSG_PUB message stack populated by VALIDATE_CLAIM_TYPE and CHECK_CLAIM_TYPE_ITEMS, as those routines provide the diagnostic detail behind rejected operations.