Search Results ozf_resale_batch_number_s




Overview
Explore in AI Chat

Overview

APPS.OZF_TP_ACCRUAL_PVT is a private PL/SQL package body within the Oracle E-Business Suite Trade Management (formerly Oracle Trade Management, module prefix OZF) schema. It implements the accrual processing engine for trade promotion and resale activity, providing the procedural logic that drives third-party (TP) accrual calculations, order validation, and resale processing. The package is classified as a PVT (private) API, meaning its entry points are intended to be invoked only by other Oracle Trade Management components and not directly by external or customer-written code. It carries a VALID status in the APPS schema, confirming it is a supported, compiled object in the ETRM 12.2.2 environment.

The package forms part of the broader accrual and resale subsystem that translates promotional offers, fund utilization records, and sales transactions into accrual entries and resale adjustments, and it orchestrates the interaction between pricing, order capture, and general ledger reference data.

Key Procedures and Functions

The documented package exposes five program units:

  • START_TP_ACCRUAL — Serves as the entry point that initiates the third-party accrual run, establishing the processing context and driving subsequent steps.
  • PROCESS_TP_ACCRUAL — Executes the core accrual processing logic, applying offer and fund utilization rules to determine accrued amounts.
  • VALIDATE_ORDER_RECORD — Validates order-related data prior to accrual or resale processing, ensuring the record is eligible for the downstream flow.
  • PROCESS_ORDER — Handles order-level processing, resolving order lines and related pricing information required for accrual and resale treatment.
  • PROCESS_RESALE — Performs resale processing, generating resale batches, adjustments, and associated log entries.

These units are designed to be chained: initiation, validation, accrual computation, order handling, and resale processing. No parameter signatures are documented here.

Tables Accessed

The package reads and writes a comprehensive set of OZF and shared tables through APPS synonyms. Resale-related access centres on OZF_RESALE_BATCHES, OZF_RESALE_BATCHES_ALL, OZF_RESALE_BATCHES_ALL_S, and OZF_RESALE_BATCH_NUMBER_S (the sequence used to generate batch numbers), together with OZF_RESALE_BATCH_LINE_MAPS_ALL, OZF_RESALE_ADJUSTMENTS, OZF_RESALE_ADJUSTMENTS_ALL, OZF_RESALE_DRAFT_LOGS_ALL, OZF_DRAFT_RUN_S, OZF_RESALE_LOGS/LOGS_ALL, and the OZF_RESALE_HEADERS and OZF_RESALE_LINES families including the interface tables (OZF_RESALE_LINES_INT, _INT_ALL, _INT_DRAFT_ALL, _INT_DRAFT_S). These support batch creation, line mapping, adjustment posting, and draft logging.

Accrual and fund logic draws on OZF_OFFERS, OZF_OFFER_ADJ_RLTD_LINES, OZF_FUNDS_UTILIZED_DRAFT_ALL, OZF_ACTBUDGETS_PVT, OZF_SYS_PARAMETERS, and OZF_LOOKUPS. Customer and party context is sourced from HZ_CUST_ACCOUNTS, HZ_CUST_ACCT_SITES, and HZ_PARTIES. Pricing and order data comes from QP_LIST_HEADERS_ALL, QP_LIST_LINES, QP_LDETS_V, QP_PREQ_GRP, QP_PREQ_PUB, and QP_PRICE_REQUEST_CONTEXT, plus OE_ORDER_PUB. Accounting context uses GL_SETS_OF_BOOKS, HR_OPERATING_UNITS, and MO_GLOBAL. Oracle Workflow (WF_EVENT, WF_PARAMETER_LIST_T) supports event propagation.

Usage Notes

OZF_TP_ACCRUAL_PVT is a private package. It is not intended to be called directly from forms or custom code; instead it is invoked internally by Oracle Trade Management concurrent programs, such as the accrual generation and resale draft processes, and by other OZF packages (three packages reference it). Interaction occurs through the published wrapper packages, including OZF_TP_ACCRUAL (public) and the resale and pre-process packages (OZF_RESALE_BATCHES_PKG, OZF_RESALE_COMMON_PVT, OZF_RESALE_LOGS_PKG, OZF_PRE_PROCESS_PVT, OZF_ORDER_PRICE_PVT, OZF_SALES_TRANSACTIONS_PVT, OZF_UTILITY_PVT, and OZF_VOLUME_CALCULATION_PUB).

Because it relies heavily on FND_API, FND_MSG_PUB, FND_FILE, FND_GLOBAL, and FND_PROFILE, error handling and logging follow standard EBS API conventions, with messages returned through the FND message stack. Customizations should never modify this private body; instead, use the public APIs or seeded concurrent programs that ultimately drive these procedures.