Search Results ozf_cstl




Overview
Explore in AI Chat

Overview

OZF_CLAIM_SETTLEMENT_WF_PVT is a private PL/SQL package body in the Oracle E-Business Suite Trade Management (formerly Oracle Trade Relationship Management / ETRM) module. It provides the workflow-supporting business logic used by the Oracle Claims Settlement workflow, which governs the settlement of trade promotion claims raised in the Oracle Trade Management application. Settlement is the final stage of the trade claim lifecycle, during which approved claim amounts are reconciled against accruals, offsets, and customer balances. The package encapsulates the low-level operations that the OZF_CSTL item type workflow invokes through its function activities, shielding the workflow definition from direct database manipulation.

The package is classified as PVT (private). It is not a public, supported API, meaning it is intended solely for internal consumption by the Claims Settlement workflow and its associated infrastructure. As the metadata confirms, no other packages reference it, which reflects its tightly scoped role. Because it was shipped under the OZF module schema (file ozfvcwfb.pls, version 120.2, last updated 2006), it has remained stable across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes three documented units:

  • PREPARE_DOCS — A workflow function activity that prepares the documentation and data required before the claim settlement process proceeds. It conforms to the standard Oracle Workflow PL/SQL API signature, accepting the item type, item key, activity ID, and function mode (Run/Cancel/Timeout) as inputs and returning a completion result. This is the procedure referenced by the user search term and is the primary entry point used by the OZF_CSTL workflow to stage settlement documentation.
  • CHECK_ADHOC_SETL_AUTOMATION — Determines whether ad hoc settlement automation is enabled for the claim under processing. The workflow uses its result to decide whether the settlement should proceed automatically or require manual intervention.
  • FETCH_ADHOC_SETL_DOC — Retrieves the ad hoc settlement document (or its identifying attributes) referenced by the claim, supplying the workflow with the data needed to process a manually created settlement.

An additional internal helper, GET_USER_ROLE, resolves a resource ID to a workflow role name by joining the resource directory to person records and calling WF_DIRECTORY.GET_ROLENAME; it is not one of the documented public-facing units but supports notification routing within the workflow.

Tables Accessed

The package reads from three tables, accessed through APPS synonyms:

  • RA_CUSTOMER_TRX — The receivables transaction header table. It supplies the credit memo or invoice transaction associated with a claim settlement document.
  • AR_PAYMENT_SCHEDULES — The receivables payment schedule table, used to identify open balances and apply settlement amounts against the correct customer account entries.
  • JTF_RS_RESOURCE_EXTNS — The resource extension table in the CRM resource directory, joined to PER_PEOPLE_F in GET_USER_ROLE to validate that a user ID corresponds to an active employee resource and to derive the role used for workflow notification.

Usage Notes

OZF_CLAIM_SETTLEMENT_WF_PVT is invoked exclusively through the Oracle Workflow engine as part of the OZF_CSTL item type. The Claims Settlement workflow definition calls PREPARE_DOCS, CHECK_ADHOC_SETL_AUTOMATION, and FETCH_ADHOC_SETL_DOC as function activities during claim processing; the procedures are therefore executed when a claim settlement is submitted from the Trade Management claim settlement page or when the workflow background engine processes a deferred activity.

Because the package is private and listed as referenced by no other packages, customers and integrators should not call it directly from custom code. Any extension to settlement behavior should be implemented through Oracle's supported public APIs or by extending the workflow definition rather than by modifying or invoking this package. Its stability across 12.1.1 and 12.2.2 means existing workflow configurations will continue to function without change after an upgrade.