Search Results ozf_claim_types_all_pkg




Overview
Explore in AI Chat

Overview

The APPS.OZF_CLAIM_TYPES_ALL_PKG package belongs to the Oracle E-Business Suite Trade Management (formerly Oracle Channel Revenue Management / OZF) product family. It provides the underlying database access layer for maintaining the definition of claim types, which are the master configuration records used by the Trade Management application to classify and process supplier and customer claims, deductions, and promotional settlements. A claim type determines the behaviour of a claim throughout its lifecycle, including validation rules, workflow routing, accounting treatment, and the allowable claim reasons and lines that may be attached to a claim.

The package is classified as an OTHER API in the documented metadata, meaning it is not a public, supported business API but rather an internal or generated package. It operates on the base tables OZF_CLAIM_TYPES_ALL_B (the base, language-independent columns) and OZF_CLAIM_TYPES_ALL_TL (the translatable columns such as name and description) in a standard EBS MLS (Multi-Lingual Support) two-table design, along with the FND_LANGUAGES reference table. Its procedures follow the conventional Oracle Forms / EBS pattern for insert, update, lock, delete, and translation handling.

Key Procedures and Functions

The documented metadata lists eight procedures and functions:

  • INSERT_ROW — Creates a new claim type record, inserting the base-language row into the required tables and establishing the primary key for the new definition.
  • UPDATE_ROW — Modifies the attributes of an existing claim type, applying changes to the base record and, where applicable, its translated rows.
  • LOCK_ROW — Obtains a row-level lock on a claim type record to enforce concurrency control before an update or delete is performed, preventing conflicting modifications by concurrent sessions.
  • DELETE_ROW — Removes a claim type definition and its associated translated rows from the underlying tables, subject to referential integrity constraints.
  • ADD_LANGUAGE — Inserts the translated (TL) row for a claim type in a specified language, supporting the multi-lingual architecture of the OZF tables.
  • TRANSLATE_ROW — Updates an existing translated row for a claim type, allowing language-specific attributes such as name and description to be maintained independently of the base definition.
  • LOAD_ROW — Loads (inserts or updates) a claim type record, typically used by data migration, seeding, or interface programs to populate the tables with a defined row.
  • LOAD_SEED_ROW — Loads seeded, out-of-the-box claim type data provided by Oracle, distinguishing system-delivered records from user-created records during setup or upgrade.

No parameter lists are documented in the metadata, and none are asserted here.

Tables Accessed

  • OZF_CLAIM_TYPES_ALL_B — The base table holding language-independent claim type attributes. Read and written by the insert, update, lock, delete, and load procedures.
  • OZF_CLAIM_TYPES_ALL_TL — The translatable table holding language-specific values (name, description). Accessed by INSERT_ROW, UPDATE_ROW, ADD_LANGUAGE, TRANSLATE_ROW, and the load procedures.
  • FND_LANGUAGES — The EBS installed-languages reference table, consulted to validate or enumerate the languages for which translated rows are created.

These tables are accessed through APPS synonyms, consistent with standard EBS schema design.

Usage Notes

This package is referenced by the companion package OZF_CLAIM_TYPE_PVT, which supplies the public business-layer API for claim types and delegates its base table maintenance to this package. Custom code should generally call the supported OZF_CLAIM_TYPE_PVT API rather than this package directly. The package is typically invoked indirectly from Oracle Forms (the claim type setup form), from concurrent programs that seed or migrate claim type data, and from the LOAD_ROW/LOAD_SEED_ROW routines during installation, patching, or upgrade of Trade Management. Because it is classified as an internal OTHER API, direct invocation should be limited to controlled setup, migration, and upgrade scenarios.