Search Results previous_period

Overview

CN_PERIOD_QUOTAS_PKG is an APPS-owned PL/SQL package within the Oracle E-Business Suite incentive compensation (Channel Revenue Management / Trade Management) schema. It encapsulates the business logic that manages period-level quota records stored in the CN_PERIOD_QUOTAS table. In the ETRM data model, a quota represents a sales target assigned to a resource over a defined calendar period; the period quota record breaks that quota down across periods and stores the cumulative performance measures used to compute attainment, payment, and goal tracking.

The package header carries a header comment dated 20-JUL-99 by S. Kumar, noting a redesign, and a revision reference of cnprdqos.pls 120.2. It is classified in the ETRM metadata as an OTHER API, meaning it is a supporting internal package rather than a published, externally versioned open interface. It exposes nine documented procedures that collectively support the insertion, maintenance, distribution, and synchronization of period quota rows, including the recalculation of inception-to-date (ITD) values.

Key Procedures and Functions

• BEGIN_RECORD — Initializes a period quota record. It accepts an operation indicator and the full set of period quota attributes, including period and quota identifiers, period and ITD targets, period and ITD payment amounts, quarter and year, audit columns, period type code, and performance goal. The period quota identifier is passed as an IN OUT parameter so a new key can be returned.
• INSERT_RECORD — Overloaded procedure that inserts period quota rows. One form takes a quota identifier; the second form takes the complete column set and returns the generated period quota identifier through an IN OUT parameter.
• UPDATE_RECORD — Updates an existing period quota row. In addition to keys and the period target, payment, and performance goal, it returns the recalculated ITD target, ITD payment amount, ITD performance amount, and the object version number through OUT parameters.
• DELETE_RECORD — Deletes period quota records associated with the supplied quota identifier.
• DISTRIBUTE_TARGET — Spreads a quota target across the applicable periods using the calendar-to-period interval type mapping, producing the per-period target rows.
• SYNC_ITD_VALUES — Synchronizes inception-to-date target, payment, and performance values for a quota so that the cumulative figures on period quota rows remain consistent with the underlying period amounts.
• POPULATE_ITD_VALUES — Populates ITD values on period quota records, forming the base calculation used during quota setup and maintenance.
• PREVIOUS_PERIOD — Resolves the prior period in the quota calendar, supporting rolling comparisons and carry-forward of cumulative balances.

Tables Accessed

• CN_PERIOD_QUOTAS — Primary table; holds the period-level quota rows this package inserts, updates, deletes, and reads.
• CN_PERIOD_QUOTAS_S — The corresponding audit/shadow table (commonly the _S audit table used for Oracle Forms-based change tracking) maintained alongside the base table.
• CN_QUOTAS — Stores the parent quota definition, providing the target and identifier the period rows derive from.
• CN_SRP_QUOTA_ASSIGNS — Quota assignment records linking sales resources to quotas, used to determine which quotas require period distribution and synchronization.
• CN_CAL_PER_INT_TYPES — Maps calendar periods to interval types, used by DISTRIBUTE_TARGET and PREVIOUS_PERIOD.
• DUAL — Used for single-row PL/SQL and SQL computations.

Usage Notes

CN_PERIOD_QUOTAS_PKG is a supporting internal API invoked by higher-level quota processing. It is commonly called from Oracle Forms-based quota maintenance screens, from concurrent programs that distribute quota targets across periods or recalculate ITD figures, and from other PL/SQL packages — the metadata records seven packages referencing it. Custom extensions should invoke procedures such as DISTRIBUTE_TARGET, SYNC_ITD_VALUES, and POPULATE_ITD_VALUES rather than writing directly to CN_PERIOD_QUOTAS, so that ITD targets, payments, performance amounts, and object version numbers remain synchronized. Because it is not a versioned public API, signatures may change between releases; all calls should be revalidated when upgrading between EBS 12.1.1 and 12.2.2.