Search Results average_main




Overview
Explore in AI Chat

Overview

The OKS_AVG_SET_PUB package is a public PL/SQL API within the Oracle E-Business Suite Service Contracts (OKS) module. Its purpose is to perform average-based processing and settlement calculations for a service contract. In the context of Service Contracts, "AVG" generally refers to averaging logic applied to billing or contract line amounts—commonly associated with contracts that use averaged billing, deferred revenue recognition, or period-based distribution of charges. The package exposes a single public entry point that accepts a contract identifier and drives the averaging computation across the associated contract structure.

The _PUB suffix confirms that this package is classified as a public API, meaning Oracle supports its invocation by external or custom code. This is significant because internal (private) Service Contracts logic may change between releases, whereas public APIs are governed by Oracle's API compatibility standards. The package owner is APPS, and its header indicates an original build date of 2005, placing it among the earlier Service Contracts APIs that have been carried forward into the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes one documented procedure:

  • AVERAGE_MAIN — The primary (and sole) public procedure of the package. It serves as the main driver for averaging logic applied to a specified service contract. Based on the package header excerpt, it returns two standard concurrent-program-style OUT parameters (ERRBUF for an error message and RETCODE for a numeric status code) alongside an IN parameter identifying the contract to be processed (P_CONTRACT_ID). The ERRBUF/RETCODE convention mirrors the structure used by Oracle concurrent program submission APIs, indicating the procedure is designed to be callable either directly or in a batch/concurrent context.

No functions are documented in the package metadata, and the metadata lists only this single procedure. No additional private or helper procedures should be assumed as part of the published interface.

Tables Accessed

The documented table references reveal the data model the package operates against. All tables are accessed through APPS synonyms:

  • OKC_K_HEADERS_B — The core contract headers table. It is the master record for a contract and supplies the header-level data required for averaging calculations tied to P_CONTRACT_ID.
  • OKS_K_LINES_B — The Service Contracts line table, holding the contract lines whose amounts or schedules are subject to averaging.
  • OKS_BILL_CONT_LINES — Billing lines associated with the contract, used to identify billable amounts that feed the averaging computation.
  • OKS_BILL_SUB_LINES — Sub-line records beneath the billing lines, providing the lower-level billing detail across which averaging is distributed.
  • OKS_BILL_SUB_LINE_DTLS — The most granular billing detail table, capturing individual period or amount records necessary for precise average allocation.

Read across these tables establishes the contract header, its lines, and the associated billing detail hierarchy, which together form the input set for the averaging routine.

Usage Notes

Because OKS_AVG_SET_PUB is a public API, it is typically invoked from the Service Contracts forms, from a concurrent program wrapper, or from custom PL/SQL that needs to trigger averaging for a specific contract. The ERRBUF/RETCODE OUT parameters strongly suggest the procedure is called through the standard concurrent program submission pattern, in which a thin package wrapper maps concurrent program parameters into AVERAGE_MAIN and checks the returned status code.

When calling this package from custom code, ensure the target contract is in an appropriate state and that its billing lines and sub-lines are fully populated; the averaging logic depends entirely on the presence of valid billing detail. The metadata notes that no other packages reference this package, so it is intended as a top-level consumer rather than a shared utility. Developers should always test in a non-production environment and rely on the ERRBUF value for diagnostics when RETCODE indicates failure.