Search Results update_ctr_prop_reading




Overview
Explore in AI Chat

Overview

CS_CTR_CAPTURE_READING_PUB is a public PL/SQL API package in the Oracle E-Business Suite (EBS) Service/Field Service (CS) module, owned by the APPS schema and declared with AUTHID CURRENT_USER. Its stated purpose in the package header is "Capture Reading for Counters." Counters in EBS represent accumulators attached to customer products, assets, or serviceable items — such as meter readings, usage counts, or cycle counts — that drive preventive maintenance scheduling, warranty validation, and service billing. This package provides the programmatic interface through which counter reading values are created, adjusted, estimated, and enriched before being persisted to the counter value tables.

Because it is classified as a PUB (public) API, the package forms part of the supported integration surface: Oracle's own concurrent programs, forms, and customer extensions are expected to call it rather than writing directly to the underlying CSI counter tables. The package header defines strongly typed PL/SQL record structures — notably CTR_GRP_LOG_Rec_Type for counter group log entries and CTR_Rdg_Rec_Type for counter reading rows — initialised with the standard FND_API.G_MISS_* sentinel values. This conforms to the EBS API programming standard where missing attributes are detected by comparison against the G_MISS constants, allowing the API to apply defaults only to attributes the caller did not explicitly supply.

Key Procedures and Functions

The documented public interface exposes the following procedures and functions, each addressing a distinct stage of the counter reading lifecycle:

  • PRE_CAPTURE_CTR_READING — the pre-processing entry point, invoked to validate and prepare a counter reading prior to insertion. This is the routine most directly associated with the search term pre_capture_ctr_reading.
  • CAPTURE_COUNTER_READING — records a new counter reading for a counter, appending the value to the counter history.
  • UPDATE_COUNTER_READING — modifies an existing captured reading, typically to correct a previously entered value.
  • POST_CAPTURE_CTR_READING — post-processing logic executed after a reading is captured, allowing downstream side effects and derived values to be applied.
  • CAPTURE_CTR_PROP_READING — captures a reading against counter properties rather than the base counter, supporting property-level accumulation.
  • UPDATE_CTR_PROP_READING — the corresponding maintenance routine for counter property readings.
  • ESTIMATE_COUNTER_READING — derives an estimated reading, commonly used when no actual reading has been supplied for a period but usage must be projected.

Each routine returns standard EBS API status codes and message text through the conventional x_return_status and x_msg_data out parameters, and none of the parameter lists should be inferred beyond what the package specification declares.

Tables Accessed

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

  • CSI_COUNTER_ASSOCIATIONS — identifies which counters are associated with a given instance or party, used to resolve the correct counter for a capture request.
  • CSI_COUNTER_PROPERTIES_B — the base table holding counter property definitions, referenced when capturing or updating property-level readings.
  • CSI_TRANSACTIONS — records the transactional context of the operation, linking captured readings back to the source transaction.
  • PLITBLM — the standard EBS PL/SQL index-by table used for bulk processing and message handling within API execution.

Usage Notes

CS_CTR_CAPTURE_READING_PUB is typically invoked from Service/Field Service counter entry forms, from concurrent programs that batch-load meter or usage readings, and from custom PL/SQL extensions that need to register counter values programmatically. The ETRM metadata records that the package is referenced by ten other packages, confirming it as a shared dependency within the CS counter ecosystem. Because the API is public and follows FND_API conventions, callers must initialise the G_MISS record structures, populate only intended attributes, and honour the returned status codes. Direct DML against the CSI counter tables should be avoided in favour of this API so that validation, association resolution, and post-capture processing remain consistent.