Search Results get_reference_number

Overview

CS_INSTALLEDBASE_PUB is the public application programming interface of the Oracle E-Business Suite Installed Base module, residing in the APPS schema and classified as a PUB (public) API package. Its documented status is VALID in both Oracle EBS 12.1.1 and 12.2.2. The package body encapsulates the business logic that governs the lifecycle of installed base records — the customer-facing inventory of products, systems, configurations, and revisions that an enterprise tracks after shipment. Through this API, external callers and internal Oracle applications can create, modify, replace, and split installed base entities without directly manipulating the underlying base tables, thereby preserving data integrity, enforcing business rules, and maintaining audit consistency. The package body depends on FND_API, the standard Oracle Application Object Library PL/SQL API layer that supplies message handling, error stacking, and transaction control conventions, and on the SYS.STANDARD package.

Key Procedures and Functions

The ETRM metadata documents nineteen callable units. The core product lifecycle procedures are CREATE_BASE_PRODUCT, which registers a new installed base product instance; UPDATE_PRODUCT, which modifies attributes of an existing instance; and REPLACE_PRODUCT, which substitutes one product for another while preserving the installed base relationship. RECORD_SHIPMENT_INFO captures shipment and delivery details that establish or update the installed base record. Revision handling is provided by CREATE_REVISION and UPDATE_REVISION, supporting version tracking of installed products. Contact management is handled by SPECIFY_CONTACT, UPDATE_CONTACT, and DELETE_CONTACT, which associate, amend, and remove party or contact references on an installed base instance.

Several procedures manage product parameters: CREATE_PRODUCT_PARAMETERS, UPDATE_PRODUCT_PARAMETERS, and DELETE_PRODUCT_PARAMETERS maintain the parameter name-value collections attached to a product. Query functions include GET_CP_ID, which resolves a counter or product identifier; GET_REFERENCE_NUMBER, which retrieves the external reference number of a record; GET_CONFIGURATION, which returns configuration structure information; and GET_PRODUCTINFO, which returns product attribute details. SPLIT_PRODUCT decomposes an installed base product into constituent instances, typically used when a shipped system must be divided into separately tracked components.

Tables Accessed

The ETRM excerpt lists no explicit table names under the referenced-objects section; the dependency list is limited to APPS.CS_INSTALLEDBASE_PUB (self-reference within the package body), FND_API, and SYS.STANDARD. In practice the package body operates against the CS_INSTALLED_BASE family of tables — the installed base header, product, revision, parameter, and contact tables — through APPS synonyms. These tables hold the physical product instances, their configuration relationships, revision history, attached parameters, and party contacts. Because the API mediates all writes, the tables are not referenced directly by the packages that call this API.

Usage Notes

CS_INSTALLEDBASE_PUB is not referenced by any database object, according to the ETRM dependency report, but it is referenced by six other packages, indicating that it functions as a shared service layer consumed by sibling modules such as service, depot repair, and order management. It is typically invoked from Oracle Forms in the Installed Base and Service suites, from concurrent programs that mass-load or migrate installed base data, and from custom PL/SQL integration code performing bulk product registration or shipment recording. Callers should follow FND_API conventions: initialize the API context, check the returned execution status, and handle messages through the standard message stack. Because the package body is documented as a PUB API, customizations should call the public procedures rather than issuing DML against the underlying tables.