Search Results update_quota_account_spread

Overview

APPS.OZF_QUOTA_PUB is a public PL/SQL API package belonging to the Oracle E-Business Suite Trade Management (formerly Oracle Trade Management / OZF) module, released under the ETRM 12.2.2 and 12.1.1 code lines. The package encapsulates the business logic required to create, maintain, and publish quota records — the targets or ceilings assigned to sales organizations, resources, customers, and products for a defined accounting period. Quotas in ETRM drive accrual calculations, incentive compensation, and territory-level performance measurement, so the integrity of quota records is fundamental to downstream funds and settlement processing.

The package is classified as a PUB (public) API, meaning its procedures form a supported programming interface that Oracle and third-party integrators may call directly. It is built on the standard EBS API conventions: each procedure accepts p_api_version, p_init_msg_list, p_commit, and p_validation_level parameters, and returns x_return_status plus a message count and message data pair so callers can enumerate errors through FND_MSG_PUB. A package-level constant g_pkg_name and a debug flag driven by FND_MSG_PUB.check_msg_level provide standard diagnostic support.

Key Procedures and Functions

Seven public procedures are documented for this package:

• CREATE_QUOTA — Establishes a new quota header record, validating the quota context and inserting the base row into the quota tables.
• CREATE_QUOTA_PRODUCT_SPREAD — Distributes a quota amount across the products that fall within the quota's territory or eligibility scope. This is the procedure associated with the search term create_quota_product_spread. It relies on the internal generate_product_spread helper, which computes the apportionment, and on create_allocation and publish_allocation to persist and activate the resulting product allocation rows.
• CREATE_QUOTA_ACCOUNT_SPREAD — Performs the analogous distribution of quota amounts across customer accounts and account sites.
• UPDATE_QUOTA — Modifies an existing quota header, applying validation and message handling before persisting changes.
• UPDATE_QUOTA_PRODUCT_SPREAD — Recalculates or adjusts an existing product spread, typically after the quota amount or product eligibility list changes.
• UPDATE_QUOTA_ACCOUNT_SPREAD — Recalculates an existing account spread.
• DELETE_QUOTA — Removes a quota and its dependent allocation records.

Internal helper routines visible in the source — generate_product_spread, create_allocation, publish_allocation, and validate_time_period — support the public procedures. validate_time_period confirms that the supplied time identifier belongs to a valid period or quarter (p_period_type_id of 32 or 64) in OZF_TIME_ENT_PERIOD or OZF_TIME_ENT_QTR, raising OZF_QUOTA_INVALID_PERIOD when the check fails.

Tables Accessed

The package reads and writes the following documented tables via APPS synonyms:

• OZF_PRODUCT_ALLOCATIONS / _S and OZF_ACCOUNT_ALLOCATIONS / _S — the primary product and account spread records produced by the create and update spread procedures.
• OZF_TIME_ALLOCATIONS / _S — holds the time-period dimension of each allocation.
• OZF_FUNDS_ALL_B and OZF_THRESHOLDS_ALL_B — quota and threshold base tables referenced during allocation validation.
• OZF_TERR_LEVELS_ALL — territory hierarchy used to determine eligible products and accounts.
• AMS_ACT_PRODUCTS and OZF_ACT_METRICS_ALL — source product and metric definitions for spread generation.
• HZ_CUST_ACCT_SITES_ALL, HZ_CUST_SITE_USES_ALL, HZ_PARTY_SITES, and JTF_RS_RESOURCE_EXTNS — TCA customer site and resource information.
• OZF_TIME_ENT_PERIOD and OZF_TIME_ENT_QTR — validated by the internal period-check routine.

Usage Notes

OZF_QUOTA_PUB is invoked primarily from the Oracle Trade Management quota entry forms and from concurrent programs that mass-generate or publish quota spreads. Because it is a PUB API, customers and partners may call it from custom PL/SQL to load quotas through interfaces or to automate spread generation. Callers should always check x_return_status against FND_API.g_ret_sts_success and drain messages via FND_MSG_PUB.get. Transactions should be committed only when p_commit is passed as FND_API.g_true; otherwise the calling layer owns transaction control. No other EBS packages in the documented metadata reference this package, so it functions as an entry point rather than a dependency for other APIs.