Search Results cs_inst_detail_pub




Overview
Explore in AI Chat

Overview

CS_INST_DETAIL_PUB is a public PL/SQL package body owned by APPS within the Oracle E-Business Suite Customer Support (CS) and Enterprise Territory/TeleService (ETRM) product family. It serves as the primary programmatic interface for managing installation details associated with installed base line items — the positional records that describe how a specific product, component, or configuration element is installed at a customer site. The package encapsulates the create, read, update, and delete lifecycle for these installation detail records and exposes them to other modules through a documented public API surface.

The package body carries the RCS header marker $Header: cspinsdb.pls 120.0 2005/08/29 ... epajaril noship $, indicating it originated in the 11i-era codebase and remains shipped as a non-customized (noship) object through Oracle EBS 12.1.1 and 12.2.2. The global constant G_PKG_NAME is set to 'CS_INST_DETAIL_PUB' and is used for error message registration and returns through the standard FND_API error-handling stack.

Key Procedures and Functions

The ETRM repository documents seven public procedures and functions. Their purposes are as follows:

  • GET_LINE_INST_DETAILS — The procedure referenced by the search term get_line_inst_details. It retrieves a single installation detail record and its associated descriptive flexfield structure. It accepts a line installation detail identifier and returns the populated Line_Inst_Dtl_Rec_Type record along with a CS_InstalledBase_PUB.DFF_Rec_Type DFF record, following the standard FND_API calling convention with API version, initialization flag, commit flag, and return-status/ message outputs.
  • GET_RMA_LINE_INST_DETAILS — Retrieves installation detail information in the context of a Return Material Authorization (RMA) line, used during return and receipt processing.
  • CREATE_INSTALLATION_DETAILS — Inserts a new installation detail record for a line item, validating and persisting the core attributes and any descriptive flexfield values.
  • UPDATE_INSTALLATION_DETAILS — Modifies an existing installation detail record, applying the supplied record against the currently stored values.
  • DELETE_INSTALLATION_DETAILS — Removes an installation detail record, typically invoked when a line or instance is removed from the installed base.
  • UPDATE_INST_DETAILS_RMA_RCPT — Updates installation detail information during RMA receipt processing, keeping installed base records synchronized with return transactions.

The body also defines two private helper procedures, Initialize_Line_Inst_Rec and Init_Line_Inst_Rec_For_Upd, which are declared outside the package specification and prepare record and DFF structures for insert and update operations respectively. These helpers are implementation detail and are not part of the published API.

Tables Accessed

The ETRM metadata for this object does not enumerate specific base tables through APPS synonyms. Based on the procedure semantics, the package operates against the installation detail entities within the Customer Support installed base schema — chiefly the installation detail and line-installation tables that back the Line_Inst_Dtl_Rec_Type record. The DFF columns are handled through the CS_InstalledBase_PUB.DFF_Rec_Type structure. Direct table names should be confirmed from the packaged source in the target instance, as the supplied metadata records no explicit table references.

Usage Notes

CS_INST_DETAIL_PUB is invoked as a standard FND_API- compliant PL/SQL API. Callers pass p_api_version, p_init_msg_list, and p_commit, and must inspect x_return_status, x_msg_count, and x_msg_data to determine success or failure. The metadata shows the package is referenced by one other package, indicating it is consumed primarily by higher-level Customer Support APIs rather than directly by forms. Typical callers include installed base maintenance forms, order and RMA processing flows, and custom integration code that needs to read or maintain installation details for a service line. Because the package ships as a non-customized APPS object, customizations should wrap rather than modify it, and all access should respect the documented public procedure signatures.