Search Results validate_instance_id

Overview

APPS.CSI_T_VLDN_ROUTINES_PVT is a private (PVT) validation utility package in the Oracle E-Business Suite Install Base / Enterprise Asset Management (CSI) module. It centralizes the referential and business-rule validation logic used when processing transactional data for item instances — serialized items, tracked instances, and related party, account, and relationship records. The package name ("VLDN ROUTINES") reflects its role: providing a reusable library of validation routines that confirm identifiers, foreign keys, mandatory parameters, and cross-record integrity before transactional data is inserted, updated, or interfaced into the CSI schema.

Because it is classified as PVT, the package is not a public API for customer extension. It is intended to be called internally by other CSI packages and the Install Base transaction processing engine. The header revision string ($Header: csivtvls.pls 120.1 2005/06/17) indicates the code originated in Release 11i and was carried forward largely unchanged into 12.1.1 and 12.2.2, which is typical for foundational validation libraries. The validate_instance_id search term maps to the broader family of identifier-validation routines exposed here, which validate transaction, instance, party, account, and relationship identifiers.

Key Procedures and Functions

The package documents 47 procedures and functions. The principal categories are:

• Parameter checking: CHECK_REQD_PARAM is overloaded for NUMBER, VARCHAR2, and DATE to confirm that a mandatory parameter was supplied, raising a standard error if not.
• Transaction line validation: VALIDATE_TRANSACTION_LINE_ID resolves a transaction line identifier and returns the corresponding record structure; VALIDATE_TXN_LINE_DETAIL_ID (overloaded for the multi-multi scenario) validates transaction line detail identifiers.
• Detail identifier validation: VALIDATE_TXN_PARTY_DETAIL_ID, VALIDATE_TXN_ACCT_DETAIL_ID, VALIDATE_TXN_RELATIONSHIP_ID, VALIDATE_TXN_OU_ID, and VALIDATE_TXN_ATTRIB_DETAIL_ID each confirm that the supplied ID corresponds to a valid detail row within its respective table.
• Source and instance validation: VALIDATE_TXN_SOURCE_ID, VALIDATE_SUBJECT_ID, VALIDATE_OBJECT_ID, VALIDATE_INSTANCE_PARTY_ID, and VALIDATE_II_RLTNS_TYPE_CODE verify source names/IDs, subject and object references, instance-party associations, and relationship type codes.
• Integrity and utility checks: CHECK_IB_CREATION, CHECK_SOURCE_INTEGRITY, CHECK_PARTY_INTEGRITY, and CHECK_RLTNS_INTEGRITY enforce cross-record consistency; CONVERT_RLTNS_INDEX_TO_IDS translates relationship index positions back into primary keys; IS_VALID_OWNER_FOR_CREATE performs an ownership authorization check; and GET_TXN_LINE_DTL_REC retrieves a transaction line detail record.

Tables Accessed

The package operates against the core CSI transaction and instance tables via APPS synonyms. The primary tables include CSI_T_TRANSACTION_LINES and CSI_T_TXN_LINE_DETAILS, which hold the staging transaction data being validated; CSI_T_PARTY_DETAILS, CSI_T_PARTY_ACCOUNTS, CSI_T_ORG_ASSIGNMENTS, CSI_T_EXTEND_ATTRIBS, and CSI_T_II_RELATIONSHIPS for detail and relationship validation; and CSI_ITEM_INSTANCES, CSI_I_PARTIES, CSI_I_ORG_ASSIGNMENTS, CSI_I_EXTENDED_ATTRIBS, CSI_IP_ACCOUNTS, CSI_II_RELATIONSHIPS, and CSI_II_RELATION_TYPES as the corresponding instance-side master data. CSI_IEA_VALUES supplies extensible attribute value lookups. These are read primarily to confirm existence and referential integrity of the IDs passed in.

Usage Notes

CSI_T_VLDN_ROUTINES_PVT is invoked indirectly rather than from user-facing forms or concurrent programs. It is referenced by ten other packages, which call these routines during transaction processing, interface import, and instance creation flows. The typical invocation pattern is a parent package (for example, a transaction or relationship processing API) passing an ID and receiving an x_return_status (and often a record structure) to determine whether processing should proceed. The use of NOCOPY for OUT record parameters reduces overhead for the large data structures returned. Because the package is PVT, customizations should not call it directly; developers should locate the corresponding public API and allow the standard validation chain to execute. Given its stability across 12.1.1 and 12.2.2, behavior is consistent between both releases.