Search Results ozf_resale_pub




Overview
Explore in AI Chat

Overview

OZF_RESALE_PUB is a public (PUB-classified) PL/SQL package in the APPS schema that supports the Oracle Trade Management (formerly Oracle Channel Revenue Management) resale and indirect sales adjustment process. The package provides the programmatic entry points used to drive the resale utilization lifecycle: matching resale activity reported by channel partners against eligible offers and adjustments, creating the corresponding resale adjustment documents, initiating payment processing, and purging historical resale interface data. It is an API-layer object, meaning its procedures are intended to be called by Oracle's own forms, concurrent programs, and supported custom integrations rather than modified directly. The package is documented in ETRM at release levels 12.1.1 and 12.2.2 with STATUS = VALID, and it resides in the dependency tree beneath FND_API and the SYS.STANDARD package, confirming its use of the Oracle Application Object Library error-handling and message-stack conventions.

Key Procedures and Functions

The documented metadata identifies four public procedures/functions exposed by OZF_RESALE_PUB:

  • START_PROCESS_IFACE — Drives processing of the resale interface, reading staged resale and utilization records and resolving them against the appropriate offers, offer-qualification lines, and price list lines so that valid resale claims can be constructed.
  • START_PAYMENT — Initiates the payment step for approved resale adjustments, handing the qualifying adjustment records to the downstream payment flow associated with the trade management settlement process.
  • START_PURGE — Removes obsolete or already-processed resale interface records, keeping the resale staging and batch tables from growing unbounded in long-running environments.
  • CREATE_RESALE_UTILIZATION — Creates the resale utilization records that represent consumption of an offer's accrual against a specific resale claim, forming the linkage between an offer and the resale adjustment ultimately generated.

Parameter lists are intentionally omitted here; they are not part of the documented metadata, and callers should reference the deployed package specification for exact signatures.

Tables Accessed

The package operates across the core Trade Management resale data model. Offer definition data is read from OZF_OFFERS and OZF_OFFER_ADJ_RLTD_LINES, with qualification list data supplied from QP_LIST_LINES. Resale output is written to the resale adjustment and resale line tables — OZF_RESALE_ADJUSTMENTS, OZF_RESALE_ADJUSTMENTS_ALL, OZF_RESALE_LINES_ALL — and staged through OZF_RESALE_BATCHES_ALL and OZF_RESALE_BATCH_LINE_MAPS_ALL, which track batch headers and the mapping of batch lines. Source utilization data lives in the resale adjustment tables as well. OZF_SD_REQUEST_HEADERS_ALL_B supports the associated settlement/disbursement request headers, and FND_USER provides the application user identity used for auditing and security context.

Usage Notes

OZF_RESALE_PUB is normally invoked indirectly. In a standard EBS environment it is called by the Trade Management resale concurrent programs and by the Resale Adjustment and Resale Utilization forms, which submit processing, payment, and purge actions to the API rather than performing the DML themselves. Custom extensions should call the same public procedures to preserve the FND_API error-handling contract (message stack, exceptions) rather than inserting into the resale tables directly, since direct inserts bypass validation, batch mapping, and utilization accounting. Because the package is classified PUB and reports zero documented inbound package references outside itself, it is a stable integration surface: Oracle reserves the right to change private helper logic but maintains the published procedure names. Typical scheduling places START_PROCESS_IFACE and START_PAYMENT in a periodic resale processing cycle, with START_PURGE run less frequently to archive cleared interface rows. In 12.1.1 and 12.2.2 the object remains valid and unchanged in classification, so integrations developed against one release should generally function against the other without modification.