Search Results csi_order_fulfill_pub




Overview
Explore in AI Chat

Overview

CSI_ORDER_FULFILL_PUB is a public PL/SQL package in the APPS schema that supports Oracle E-Business Suite's order fulfillment and install-base tracking processes. It belongs to the CSI (Customer Support Install Base / ETRM) product family and is classified as a public API (PUB), meaning it is intended for invocation by other Oracle modules and, in limited cases, by customer extensions. Its central responsibility is to bridge order management and inventory fulfillment activity with the creation and maintenance of install-base item instances and their transactional relationships.

In EBS 12.1.1 and 12.2.2, the package processes order lines during fulfillment, resolves configuration and model relationships (including bills of material explosion and option dependencies), and records the resulting inventory and install-base transactions. It works in close cooperation with CSI_ORDER_SHIP_PUB, CSI_DATASTRUCTURES_PUB, and OE_ORDER_PUB, leveraging shared API conventions such as FND_API for error handling and savepoint management. Because the install base must reflect the exact physical and logical hierarchy of shipped goods, this package plays a critical role in maintaining data integrity between order management, WIP, and the install base.

Key Procedures and Functions

The package exposes sixteen documented procedures and functions. The primary entry point is ORDER_FULFILLMENT, which drives the overall fulfillment processing for order lines and coordinates the remaining routines. Several procedures focus on configuration and model handling: BUILD_OPTION_CHILD_LINE_TBL constructs the table of option child lines for a configured item; BUILD_CHILD_RELATION_LINES derives relationship lines between parent and child instances; GET_JOB_FOR_CONFIG_LINE retrieves the WIP job associated with a configuration line; and GET_PHANTOM_OPTION_EXPL_FLAG determines whether phantom option explosion applies.

Trackable instance resolution is handled by GET_IB_TRACKABLE_CHILDREN, GET_ALL_IB_TRACKABLE_CHILDREN, and GET_IB_TRACKABLE_PARENT, which navigate install-base item instance hierarchies to identify trackable parents and children. GET_WIP_INFO_FROM_TXN extracts Work in Process information from a transaction. CONSTRUCT_TXN_DTLS assembles the transaction detail structures required by downstream processing. PROCESS_OLD_ORDER_LINES handles legacy or previously processed order lines. UPDATE_PROFILE manages profile option values used to govern fulfillment behavior. FULFILL_WF supports the fulfillment workflow, while CZ_FULFILLMENT and LOGICAL_DROP_SHIP address configuration-specific fulfillment and logical drop-ship scenarios respectively. As with all documented CSI public APIs, parameter signatures should be taken directly from the package specification rather than inferred.

Tables Accessed

The package reads and writes a broad set of tables through APPS synonyms. Order data is sourced from OE_ORDER_LINES_ALL and BOM_CTO_ORDER_LINES, providing the order line and configure-to-order line details that drive fulfillment. Bill of material explosion data is read from BOM_EXPLOSION_TEMP_S and BOM_SMALL_EXPL_TEMP. Install-base records are created or updated in CSI_ITEM_INSTANCES, CSI_ITEM_INSTANCES_H, CSI_TRANSACTIONS, and CSI_I_PARTIES, while relationship and transaction detail data reside in CSI_II_RELATIONSHIPS, CSI_T_TRANSACTION_LINES, and CSI_T_TXN_LINE_DETAILS. Transaction type validation uses CSI_IB_TXN_TYPES and account information is taken from CSI_IP_ACCOUNTS. Profile and environment control values come from FND_PROFILE_OPTIONS and FND_PRODUCT_GROUPS.

Usage Notes

CSI_ORDER_FULFILL_PUB is typically invoked indirectly rather than called directly by end users. It is referenced by CSI_INTERFACE_PKG, CSI_INV_TXNSTUB_PKG, CSI_ORDER_SHIP_PUB, CSI_T_UTILITIES_PVT, and CSI_UTL_PKG, indicating that it is a foundational module within the CSI fulfillment and shipping stack. Standard order-to-install-base integration, shipping confirmation, and inventory transaction processing flows reach this package through those callers. Custom extensions should prefer the public wrapper procedures and must observe FND_API error handling conventions, including checking the returned API status and rolling back on failure. Because the package touches core order and install-base tables, testing in a cloned environment and careful management of concurrent processing are recommended before deployment in a 12.1.1 or 12.2.2 instance.