Search Results get_sub_type_rec




Overview

APPS.CSI_PROCESS_TXN_PVT is a private (PVT) PL/SQL package within the Oracle E-Business Suite Installed Base (CSI) product family. It provides the internal processing engine that validates and executes transactional changes against item instances and their relationships — the foundational records that represent assets, equipment, serialized goods, and their associations in Oracle Installed Base.

The package is the implementation layer behind the public CSI transaction APIs. It encapsulates the business rules that determine whether a given transaction type and sub-type may be applied to an instance, whether source and destination instance identifiers can be resolved, whether the inventory item attributes permit the requested movement, and whether inbound or relational transactions are legal. The header comment (csivptxs.pls 120.0.12000000.1, dated January 2007) indicates the package is a long-standing, stable component carried forward through EBS 12.1.1 and 12.2.2. The user search for get_sub_type_rec targets one of the eleven documented procedures, which retrieves the transaction sub-type definition record for a given transaction type and sub-type pair.

Key Procedures and Functions

The package exposes eleven documented procedures. Each is intended for internal invocation by other CSI packages and public APIs rather than direct customer use.

  • GET_SUB_TYPE_REC — Returns the row from CSI_TXN_SUB_TYPES that corresponds to a supplied transaction type identifier and sub-type identifier. This is the entry point for resolving the controlling rules (direction, allowed item attributes, required validations) that govern a requested transaction.
  • SUB_TYPE_VALIDATIONS — Applies the business rules associated with a sub-type record against the incoming transaction instances and instance parties collections, returning a status indicating whether the transaction is permissible.
  • VALIDATE_DEST_LOCATION_REC — Validates a destination location record in the context of an inbound or outbound movement, ensuring the specified destination organization, subinventory, or locator is consistent with the transaction.
  • GET_ITEM_ATTRIBUTES — Derives the control flags for an inventory item in a specific organization, populating the item_attr_rec structure with serial, lot, locator, revision, trackable, shippable, BOM item type, and stockable indicators.
  • GET_SRC_INSTANCE_ID — Resolves the source instance identifier for a transaction, using the sub-type record, the source instance record, destination location, item attributes, and the transaction record.
  • GET_DEST_INSTANCE_ID — Resolves the destination instance identifier for a transaction using the analogous inputs.
  • GET_SERIAL_TAGGING_CONTROL — Determines serial tagging behavior required for the transaction.
  • PROCESS_IB — Performs the core Installed Base processing of the transaction, updating instance and relationship data.
  • PROCESS_RELATION — Creates or updates instance relationships as directed by the transaction.
  • CHECK_AND_BREAK_RELATION — Tests whether an existing relationship must be broken and, if so, terminates it.
  • UNEXPIRE_INSTANCE — Reactivates a previously expired instance as part of the transaction flow.

Tables Accessed

The package reads and writes several CSI and Oracle Inventory tables through APPS synonyms.

Usage Notes

CSI_PROCESS_TXN_PVT is a private package and is not intended for direct customer calls. It is invoked indirectly by the public Installed Base transaction APIs and by Oracle forms and concurrent programs that create, move, or retire item instances — for example, shipping confirmations, RMA receipts, service transactions, and asset movement flows.

The package is referenced by ten other packages, confirming its role as a shared internal utility. Developers extending Installed Base functionality should call the supported public APIs rather than CSI_PROCESS_TXN_PVT directly, since the signature is not guaranteed across releases. The search term get_sub_type_rec most often appears when tracing a validation error back through the call stack to the sub-type lookup, which is the first step of most transaction flows. The package behaves consistently across EBS 12.1.1 and 12.2.2, with no documented signature changes between those releases.