Search Results counter_values
Overview
OKS_BILL_REC_PUB is a public PL/SQL package in the APPS schema that supports subscription and service contract billing within Oracle E-Business Suite Releases 12.1.1 and 12.2.2. It belongs to the Oracle Knowledge Solutions (OKS) service contracts family and functions primarily as a billing-record construction and maintenance utility. The package assembles the billing records (BCL) and billing sub-lines (BSL) that drive recurring invoice generation for service contracts, subscription lines, and usage-based agreements. It also provides the termination, counter-value, and negotiated-price adjustment logic that downstream billing processes consume.
Its API classification is PUB, indicating it is intended for supported external invocation rather than internal-only use. In the documented dependency graph, OKS_BILL_REC_PUB references OKC_API and base views such as OKC_K_HEADERS_B, OKC_K_LINES_B, and OKX_PARTIES_V, and is in turn referenced by ten or more sibling packages, including OKS_BILLING_PUB, OKS_ARFEEDER_PUB, OKS_BILL_UTIL_PUB, OKS_USAGE_SETTLE_PUB, OKS_AVG_SET_PUB, and OKS_MASS_UPDATE_PVT. This confirms its central role in the billing pipeline rather than a peripheral one.
Key Procedures and Functions
The package exposes roughly thirty documented procedures and functions. The principal groups are summarized below; parameter lists are intentionally omitted.
- Billing record maintenance: INSERT_BCL and INSERT_ALL_SUBLINE create billing records and their associated sub-lines; UPDATE_BCL and UPDATE_BSL maintain those records; SET_TOP_LINE and SET_SUB_LINE establish the top-line and sub-line relationships used during invoice assembly.
- Identifier and sequence handling: GET_SEQ_ID returns sequence identifiers for billing records, while GET_BCL_ID retrieves an existing billing record identifier.
- Termination logic: PRE_TERMINATE calculates the effects of early termination, TERMINATE_SUBSCRIBTION_LINE terminates a subscription line, PRE_TERMINATE_SERVICE evaluates pre-termination impact on service lines, and PRE_TERMINATE_AMOUNT derives the pre-termination financial amount.
- Rating and pricing: GET_BILL_AMOUNT_PERIOD computes the billing amount for a given period; ADJUST_NEGOTIATED_PRICE applies negotiated-price adjustments; COUNTER_VALUES interfaces with contract counter values; TRUE_VALUE performs the truth-value evaluation used by billing rules.
- Rule and profile maintenance: CRE_UPD_CCR_RULE creates or updates commitment/credit rule records; GET_BILL_PROFILE returns the billing profile for a contract.
- Financial setup: CREATE_BANK_ACCOUNT supports bank-account creation used in billing and receivables contexts.
- Messaging: GET_MESSAGE returns the message text associated with a billing processing outcome.
Tables Accessed
Access is performed through APPS synonyms. The core contract tables are OKC_K_HEADERS_B and OKC_K_LINES_B for contract headers and lines, OKC_K_ITEMS for contract items, and OKC_RULES_B and OKC_RULE_GROUPS_B for rule definitions. OKC_ASSENTS, OKC_K_REL_OBJS, and OKC_STATUSES_B support contract relationships and status validation. Counter and usage data come from CS_CTR_COUNTER_VALUES_V. Product and unit-of-measure data are read from MTL_SYSTEM_ITEMS, MTL_SYSTEM_ITEMS_B, and MTL_UNITS_OF_MEASURE_TL. Order-line information is drawn from OE_ORDER_LINES_ALL, incident data from CS_INCIDENTS_ALL_B, and billing record storage from OKS_BCL_PR and related billing tables.
Usage Notes
The package is normally invoked indirectly by concurrent programs and forms rather than by end users directly. Standard callers include the billing generation concurrent programs accessed through OKS_BILLING_PUB, the receivables feeder through OKS_ARFEEDER_PUB, usage settlement through OKS_USAGE_SETTLE_PUB, and mass-update processing through OKS_MASS_UPDATE_PVT. Custom integrations that need to construct, modify, or pre-evaluate billing records for service contracts should call the published procedures rather than inserting directly into the underlying tables, because the package enforces rule, counter, and profile consistency. As with all PUB APIs, calls should be made inside a savepoint so business errors surfaced by GET_MESSAGE can be handled and rolled back cleanly.