Search Results csi_t_datastructures_grp




Overview
Explore in AI Chat

Overview

CSI_T_DATASTRUCTURES_GRP is a public PL/SQL specification package owned by the APPS schema in Oracle E-Business Suite, classified as a GRP (group/type definition) unit within the Customer Service Intelligence (CSI) product family, also known as the Enterprise Installation Standards (EIS) and TeleService foundation. The package does not itself expose business procedures; instead it is exclusively a container for record type definitions used across the CSI application programming interface layer. Its header revision ($Header: csigtdss.pls 120.4) indicates the file was last modified in 2006, meaning the specification has been carried forward unchanged through EBS 12.1.1 and 12.2.2. The package's principal purpose is to provide strongly typed record structures — most notably txn_system_rec — that describe a customer "system" (an installed asset or configuration item) as it flows through transactional APIs in Oracle TeleService, Install Base, and related service modules.

Key Procedures and Functions

The documented source specification contains no callable procedures or functions. The body of the package declares only a PL/SQL TYPE ... IS RECORD construct. The single documented type is txn_system_rec, described in the source comments as a "record to hold the values of systems." Every field in the record is initialized to the FND_API missing sentinel values (G_MISS_NUM, G_MISS_CHAR, G_MISS_DATE), which is the standard Oracle API convention that allows consuming APIs to distinguish an unchanged attribute from an explicitly supplied one during insert or update processing. Because the type is declared in a package specification rather than a standalone type, it can be referenced by any client procedure compiled against the CSI_T_DATASTRUCTURES_GRP package.

Tables Accessed

The ETRM metadata documents no table references for this package. This is consistent with its role as a pure type repository — a specification with no executable body cannot itself read from or write to database tables. The txn_system_rec structure nonetheless mirrors the column layout of the CSI installation/transaction staging tables (such as CSI_TXN_SYSTEMS and the related CSI_ITEM_INSTANCES columns) that the calling APIs consume. Field groups in the record correspond to: identity and numbering (TRANSACTION_SYSTEM_ID, TRANSACTION_LINE_ID, SYSTEM_NUMBER); descriptive attributes (SYSTEM_NAME, DESCRIPTION, SYSTEM_TYPE_CODE, CONFIG_SYSTEM_TYPE); party and contact references (CUSTOMER_ID and the bill-to, ship-to, technical, and service-admin contact IDs); site usage keys (SHIP_TO_SITE_USE_ID, BILL_TO_SITE_USE_ID, INSTALL_SITE_USE_ID); effective dating (START_DATE_ACTIVE, END_DATE_ACTIVE, COTERMINATE_DAY_MONTH); and the standard 15 DFF attribute columns keyed by CONTEXT. Downstream APIs map these fields onto the physical Install Base tables when committing a system transaction.

Usage Notes

CSI_T_DATASTRUCTURES_GRP is invoked implicitly rather than directly: any PL/SQL unit that declares a variable of type CSI_T_DATASTRUCTURES_GRP.txn_system_rec establishes a compile-time dependency on this specification. ETRM records 34 other packages that reference it, confirming its role as a shared contract between the CSI transaction APIs, the Install Base public APIs, and the TeleService forms layer. Typical invocation paths include:

  • Public CSI/Teleservice APIs that create or update customer systems from concurrent programs, such as interface and import routines that stage service data.
  • Oracle Forms and OAF pages in the Service/Install Base responsibility, where the form's PL/SQL library populates a local record of this type before calling the underlying API.
  • Custom extensions that need to pass a fully populated system structure to a CSI API; such code must reference the APPS synonym for the package and set only the fields being changed, leaving the rest at their G_MISS defaults.

Because the specification has remained at version 120.4 since 2006 and carries the "noship" build stamp, customizations should treat it as a stable, unsupported internal contract and avoid modifying the shipped specification. Upgrades between 12.1.1 and 12.2.2 do not alter the type definition, so custom code compiled against it remains portable across both releases.