Search Results csi_ctr_upload_instances




Overview
Explore in AI Chat

Overview

The CSI_CTR_UPLOAD_INSTANCES table, owned by the CSI schema within the Oracle E-Business Suite Install Base module, serves as a staging and control structure for counter data that is pending instantiation against install base instances. Its documented purpose is to "hold the counter data to be instantiated," positioning it as an intermediate persistence layer through which externally sourced or bulk-loaded meter readings are validated and subsequently applied to the appropriate installed base asset records. The table is a standard transactional object in EBS 12.1.1 and 12.2.2 and carries a VALID status in the data dictionary.

From a Data Vault modeling perspective, the heuristic classification mined from the foreign key structure identifies this table as a standalone object. This classification should be treated as a modeling suggestion rather than a prescriptive design: the absence of inbound foreign keys from dependent tables indicates that CSI_CTR_UPLOAD_INSTANCES functions neither as a conventional hub of business entities nor as a link resolving many-to-many relationships among other hubs. In Data Vault terms it most closely resembles a staging or transient satellite, since its rows carry descriptive attributes, status flags, and audit columns describing the processing outcome of an upload attempt rather than serving as a durable reference entity.

Key Information Stored

The table comprises twelve documented columns. The surrogate primary key is UPLOAD_INSTANCE_ID, which uniquely identifies each staged counter row. Notably, the foreign key metadata records a reference from CSI_CTR_UPLOAD_INSTANCES.UPLOAD_INSTANCE_ID to CS_CTR_UPLOAD_INSTANCES, indicating that the identifier is shared with or derived from a parent upload-instance record in the CS schema — an important consideration when joining across schemas.

The principal business-key candidates and descriptive attributes include:

  • SOURCE_OBJECT_ID and SOURCE_OBJECT_CODE — identify the originating business object (for example, the counter or item context) from which the reading was sourced.
  • ITEM_ID — the inventory item to which the counter reading pertains.
  • ORG_ID — the operating unit or inventory organization context, supporting multi-org reporting.
  • STATUS — the processing state of the staged counter, distinguishing rows that are pending, successfully instantiated, or rejected.
  • ERROR_MESSAGE — diagnostic text captured when instantiation fails, supporting remediation workflows.

The remaining columns are standard EBS audit attributes: LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, and CREATED_BY. These support concurrency control, user attribution, and incremental extract strategies in downstream reporting.

Common Use Cases and Queries

Typical usage centers on monitoring the health of counter uploads and reconciling staged data against successfully instantiated counters. A monitoring query might filter on STATUS to surface failed rows:

  • SELECT UPLOAD_INSTANCE_ID, ITEM_ID, ORG_ID, ERROR_MESSAGE FROM CSI.CSI_CTR_UPLOAD_INSTANCES WHERE STATUS = 'ERROR';
  • Volume trending by organization: SELECT ORG_ID, COUNT(*) FROM CSI.CSI_CTR_UPLOAD_INSTANCES GROUP BY ORG_ID;
  • Attribution audit: SELECT CREATED_BY, LAST_UPDATED_BY FROM CSI.CSI_CTR_UPLOAD_INSTANCES WHERE CREATION_DATE > :p_start_date;

Reporting use cases include upload success-rate dashboards, error-message frequency analysis, and reconciliation of staged counter volumes against the parent CS_CTR_UPLOAD_INSTANCES batch record.

Related Objects

The most significant related object is CS_CTR_UPLOAD_INSTANCES, joined via UPLOAD_INSTANCE_ID, which represents the parent upload batch. Additional relevant objects within the CSI Install Base and CS counter-uploading domain include CS_CTR_UPLOAD_INSTANCES, the CSI_ITEM_INSTANCES table (the target of successful counter instantiation), and the counter definition and counter value tables within the CS schema that supply the semantic meaning of the staged readings. Integration points typically flow through the counter loading concurrent programs rather than direct DML.