Search Results ozf_resale_headers




Overview
Explore in AI Chat

Overview

OZF_TRACING_ORDER_PVT is a private PL/SQL package body in the APPS schema that supports the Oracle E-Business Suite Trade Management (formerly Oracle Channel Revenue Management) resale tracing workflow. Its role is to process and validate "tracing orders," which are resale transactions recorded against a distributor or reseller so that the manufacturer can trace sell-through activity and settle the associated claims, rebates, or accruals. The package is classified as a PVT (private) API, meaning it is not intended to be called directly by external integrations but instead functions as a helper layer beneath the public resale APIs.

The private designation is consistent with the package naming and dependency profile. OZF_TRACING_ORDER_PVT builds on the common infrastructure provided by OZF_RESALE_COMMON_PVT, OZF_SALES_TRANSACTIONS_PVT, and OZF_UTILITY_PVT, and it implements the Oracle Applications API programming standards through FND_API, FND_MESSAGE, and FND_MSG_PUB. It is referenced by two other database objects, indicating it is consumed by higher-level resale processing packages rather than being an entry point itself. In EBS 12.1.1 and 12.2.2 the package remains VALID, with no reported compilation errors.

Key Procedures and Functions

The ETRM metadata documents three procedures or functions within this package body:

  • VALIDATE_ORDER_RECORD — Performs validation on an inbound tracing order before it is processed. It checks the order structure and reference data, raising messages through FND_MSG_PUB so that calling code can inspect the API message stack. This procedure is the gatekeeper that prevents invalid records from reaching downstream resale batch and line processing.
  • PROCESS_ORDER — The core driver that applies a validated tracing order. It coordinates the movement of data through the resale batch, header, and line structures, invoking the common resale routines to persist the transaction and record processing activity in the resale logs.
  • INITIATE_PAYMENT — Handles the payment side of the tracing transaction, determining and initiating the settlement associated with the processed order. It uses system parameter and message infrastructure to resolve payment behavior and to report status back to the caller.

These three procedures together follow the standard pattern of validate, process, and settle that is typical of Trade Management resale APIs.

Tables Accessed

The package references the resale batch and line tables — OZF_RESALE_BATCHES, OZF_RESALE_BATCHES_ALL, OZF_RESALE_LINES, OZF_RESALE_LINES_INT, and OZF_RESALE_LINES_INT_ALL — which hold the transaction batches and interface rows used to stage and commit tracing order data. OZF_RESALE_HEADERS stores the order header, and because the user searched for "ozf_resale_headers," it is the central header object validated and processed by this package. Logging and audit output is written to OZF_RESALE_LOGS, OZF_RESALE_LOGS_ALL, and OZF_RESALE_LOGS_ALL_S (the sequence). OZF_SYS_PARAMETERS supplies system-level configuration values, and PLITBLM is the Oracle-supplied PL/SQL table and bulk-mapping utility used for in-memory collection handling. All references are made through APPS synonyms, so the package operates on the same schema objects used by the standard resale forms and concurrent programs.

Usage Notes

OZF_TRACING_ORDER_PVT is not referenced by any database object at the public layer, confirming its private nature; it is invoked by the two packages that call it, most likely the public resale API layer and any batch or concurrent processing that feeds tracing orders. Typical invocation paths include the Trade Management resale/tracing order forms, concurrent programs that load resale transactions from external files or interface tables, and custom extensions that wrap the public resale API. Because it uses FND_MSG_PUB, callers must initialize the message stack and check FND_MSG_PUB.Count_And_Get after each call. Custom code should never call this package directly; developers should use the documented public API that ultimately delegates to OZF_TRACING_ORDER_PVT, ensuring validation, logging, and payment logic remain intact across EBS 12.1.1 and 12.2.2.