Search Results get_dest_instance_id




Overview
Explore in AI Chat

Overview

CSI_PROCESS_TXN_PVT is a private PL/SQL package in the Oracle EBS Applications (APPS) schema that supports the processing of item instance transactions within the Enterprise Asset / Installed Base (CSI) module. Its principal responsibility is to validate and process transaction instances, subtypes, parties, and the relationships that link instances to one another. The package operates as an internal (PVT) API layer, meaning it is not intended for direct customer invocation but rather serves as the engine called by the public CSI processing packages and the higher-level transaction processing APIs.

The package encapsulates rules around item instance relationships, serial tagging, locator and lot control, and status transitions for instances. It centralizes the logic used to determine source and destination instances, item attribute resolution, and the break or expiration of existing relationships between instances when a new transaction affects them.

Key Procedures and Functions

  • GET_SUB_TYPE_REC — Retrieves the transaction subtype record for a given transaction type and subtype identifier.
  • SUB_TYPE_VALIDATIONS — Validates transaction instances and instance parties against the subtype definition, setting the return status accordingly.
  • VALIDATE_DEST_LOCATION_REC — Validates the destination location record supplied for a transaction, honoring the in/out direction flag.
  • GET_ITEM_ATTRIBUTES — Builds the item attribute record (serial, lot, locator, revision, IB trackable, shippable, stockable flags) for an inventory item in a given organization.
  • GET_SRC_INSTANCE_ID — Determines and returns the source item instance identifier for the transaction being processed.
  • GET_DEST_INSTANCE_ID — Resolves the destination instance identifier associated with the transaction.
  • GET_SERIAL_TAGGING_CONTROL — Determines serial tagging control behavior applicable to the transaction.
  • PROCESS_IB — Performs Installed Base processing for the transaction instance.
  • PROCESS_RELATION — Creates and processes the relationship between source and destination instances.
  • CHECK_AND_BREAK_RELATION — Inspects an existing instance relationship to determine whether it must be broken or is still valid, and breaks it when necessary. This is the procedure most commonly associated with searches for this package.
  • UNEXPIRE_INSTANCE — Reverses expiration on an instance, restoring its active status.

Tables Accessed

The package reads and writes a focused set of CSI and inventory tables. CSI_II_RELATIONSHIPS stores the relationships checked and broken by CHECK_AND_BREAK_RELATION; CSI_ITEM_INSTANCES and CSI_INSTANCE_STATUSES carry the instance identity and status lifecycle; CSI_ITEM_INSTANCE_LOCKS supports concurrency control during processing. CSI_I_PARTIES and CSI_I_ORG_ASSIGNMENTS provide party and organization context, while CSI_IP_ACCOUNTS and CSI_I_PRICING_ATTRIBS supply account and pricing attributes. CSI_T_TXN_LINE_DETAILS holds staging transaction-line detail. Inventory master data is drawn from MTL_SYSTEM_ITEMS and its key flexfield view MTL_SYSTEM_ITEMS_KFV, with MTL_PARAMETERS, MTL_SECONDARY_INVENTORIES, and MTL_MATERIAL_TRANSACTIONS supplying organization and stock locator context. PLITBLM is referenced for PL/SQL table support.

Usage Notes

CSI_PROCESS_TXN_PVT is classified as a PVT API and is referenced by approximately ten other packages. It is invoked indirectly through the public CSI transaction processing APIs when item instance transactions are created or updated — for example, during Installed Base instance creation, move, split, merge, or return operations. Oracle Forms in the CSI and Inventory modules and concurrent programs that process instance transactions reach this layer through the calling public APIs. Custom code should not call CSI_PROCESS_TXN_PVT directly; integrators requiring relationship processing should instead use the supported public API surface, relying on CHECK_AND_BREAK_RELATION only through those documented entry points. Because behavior is driven by transaction subtype configuration, any customization should be validated against the subtype setup before deployment.