Search Results ctr_group




Overview
Explore in AI Chat

Overview

CSI_ITEM_INSTANCE_GRP is a grouping (GRP) package in the Oracle E-Business Suite Applications (APPS) schema, delivered as part of the Complex Maintenance, Repair, and Overhaul (cMRO) and Enterprise Asset Management item instance infrastructure. Its role is to provide a consolidated, transaction-safe entry point for creating, maintaining, and retiring item instances — the unique serialized records that represent individual tracked assets, components, and configurations within Oracle EBS. The package body source header, csigiib.pls version 120.37.12020000.5, dates to November 2012 and is shipped with both release 12.1.1 and 12.2.2.

The group layer wraps the lower-level public APIs in CSI_DATASTRUCTURES_PUB and related packages, exposing a smaller set of business-oriented operations that forms, concurrent programs, and custom integrations can call without managing the full item instance data structure directly. The user search term "ctr_group" aligns with the Counter (CTR) related supporting tables that this package touches, notably CSI_CTR_ITEM_ASSOCIATIONS and CSI_CTR_UPLOAD_INSTANCES, reflecting its use in counter-based meter and reading upload flows.

Key Procedures and Functions

The documented package exposes eight procedures and functions:

  • CREATE_ITEM_INSTANCE — Inserts a new item instance record, populating the base and history tables and validating the instance against the item master and instance status.
  • UPDATE_ITEM_INSTANCE — Modifies attributes of an existing item instance, driving the corresponding history rows to preserve auditability.
  • EXPIRE_ITEM_INSTANCE — Retires or ends the effective life of an instance, typically setting status and end-dating logic on the instance and relationship records.
  • LOCK_ITEM_INSTANCES / UNLOCK_ITEM_INSTANCES / CHECK_ITEM_INSTANCE_LOCK — Provide concurrency control. LOCK_ITEM_INSTANCES acquires a lock so that competing transactions cannot modify the same instance concurrently; CHECK_ITEM_INSTANCE_LOCK reports whether a lock is currently held; UNLOCK_ITEM_INSTANCES releases it.
  • GET_ALL_PARENTS — Returns the full upward hierarchy of parent instances for a given instance by traversing CSI_II_RELATIONSHIPS.
  • EXPLODE_BOM — Explodes the bill of material structure associated with an item instance, enumerating its component instances for configuration and maintenance processing.

In addition, the source excerpt shows internal helpers such as UPDATE_INTERFACE_TABLE, which writes error text and processing status back into interface tables, and VALID_LOT_NUMBER, which validates lot-controlled instances. These are supporting utilities rather than part of the published API surface.

Tables Accessed

The package reads and writes a defined set of CSI tables through APPS synonyms. CSI_ITEM_INSTANCES, CSI_ITEM_INSTANCES_H, and CSI_ITEM_INSTANCES_H_S hold the current instance data, its history, and the history shadow record respectively. CSI_INSTANCE_STATUSES supplies valid lifecycle statuses. CSI_II_RELATIONSHIPS stores parent-child instance links used by GET_ALL_PARENTS and hierarchy validation. CSI_IP_ACCOUNTS and its history tables (CSI_IP_ACCOUNTS_H, _H_S) hold instance accounting distributions. CSI_IEA_VALUES and its history tables (CSI_IEA_VALUES_H, _H_S) store instance extended attribute values. CSI_CTR_ITEM_ASSOCIATIONS links items to counters, and CSI_CTR_UPLOAD_INSTANCES plus CSI_CTR_UPLOAD_INSTANCES_S serve as the counter reading upload interface. Interface error updates are applied dynamically to whichever interface table is passed to UPDATE_INTERFACE_TABLE.

Usage Notes

CSI_ITEM_INSTANCE_GRP is typically invoked from Oracle cMRO and Asset Management forms, from concurrent programs that process instance uploads and counter readings, and from custom PL/SQL integrations that create or maintain tracked assets. Because the package is classified as a GRP API and is referenced by fourteen other packages, it is considered a supported integration point; callers should invoke the documented procedures rather than manipulating the underlying tables directly, so that history rows, locks, and interface status are maintained consistently. LOCK and UNLOCK calls should bracket any multi-step transaction that modifies a shared instance to avoid concurrent update conflicts.