Search Results check_unique_action

Overview

OZF_REASON_PVT is a private PL/SQL package in the Oracle E-Business Suite Trade Management (formerly Oracle Trade Management / OZF) schema. It encapsulates the business logic governing reason codes — the configurable lookup values used throughout the OZF module to classify why a claim, deduction, or order-line adjustment was created. Typical implementations include reasons such as "Damaged Goods," "Short Shipment," "Pricing Discrepancy," and "Promotional Allowance." The package provides a centralized, FND_API-compliant interface for creating, updating, deleting, and validating these reason definitions so that all three activities pass through a single set of consistency rules and message-handling conventions.

The documented object is the package body; its companion specification exposes the public API. The API classification is PVT (private), indicating the package is intended for internal consumption by other OZF packages rather than for direct invocation by external integrators or forms. This is confirmed by the metadata note that it is referenced by only one other package, which supplies the public wrapper layer. The body was last substantially amended in 2005 (header version 120.2), and its evolution shows the gradual accumulation of reason attributes: ORDER_TYPE_ID, PARTNER_ACCESS_FLAG, and INVOICING_REASON_CODE were each added over successive releases.

Key Procedures and Functions

The package exposes nine documented program units, centered on the CRUD lifecycle of reason codes and their child actions.

• CREATE_REASON — Inserts a new reason definition. It follows the standard OZF API pattern: savepoint establishment, FND_API.Compatible_API_Call version check, optional message-list initialization, record-type input, and return of the new primary key. It is the entry point that ultimately produces the REASON_CODE_ID.
• UPDATE_REASON — Modifies an existing reason record, applying the same validation and message-handling discipline as the create operation.
• DELETE_REASON — Removes a reason definition, subject to the package's internal integrity checks.
• UPDATE_ACTIONS — Maintains the action rows associated with a reason, allowing the set of permissible follow-up actions to be revised.
• DELETE_ACTION — Removes an individual action linked to a reason.
• CHECK_UNIQUE_ACTION — A uniqueness guard ensuring that the same action is not associated with a given reason more than once before an insert or update is committed.
• VALIDATE_REASON_REC — Performs record-level validation on a reason record structure, checking field-level completeness and domain rules prior to persistence.
• VALIDATE_REASON — The procedure most frequently sought by developers searching for "validate_reason." It is the public validation entry point that callers invoke to test whether a reason code is valid before using it elsewhere, for example when attaching a reason to a claim. It orchestrates the record-level checks and raises or reports errors through the FND message stack.
• COMPLETE_REASON_REC — Populates defaulted or derived attributes on an incomplete reason record, ensuring mandatory columns are filled before the record is handed to the validation and persistence routines.

Tables Accessed

The package reads and writes the principal OZF reason-code tables through APPS synonyms:

• OZF_REASONS and OZF_REASONS_S — the base and translated (TL) reason tables holding the reason definition, including the ORDER_TYPE_ID, PARTNER_ACCESS_FLAG, and INVOICING_REASON_CODE attributes noted in the package history.
• OZF_REASON_CODES_ALL_B — the underlying reason-code base table from which REASON_CODE_ID values are derived.
• OZF_CLAIMS_ALL — referenced to enforce referential integrity, so that a reason in active use on a claim cannot be deleted or altered inconsistently.
• PLITBLM — the PL/SQL table used by the FND message-handling framework to buffer debug and error messages emitted by the API.

Usage Notes

Because OZF_REASON_PVT is a private package, it should not be called directly from custom forms, concurrent programs, or external integrations. Instead, callers should use the single public package that wraps it (the one documented reference), or the declarative reason-code setup UI, which routes through that public layer. When invoked, the package requires the standard OZF API calling convention: an API version number, an initialization flag, a commit flag, and a validation level, with return status, message count, and message data returned to the caller. The VALIDATE_REASON procedure is commonly reached indirectly — for example, when the Claim or Deduction forms validate a user-entered reason before saving — so developers investigating validation failures should trace the FND message stack rather than expecting a raised exception. All work is performed within a named savepoint, ensuring partial failures roll back cleanly.