Search Results build_shtd_table

Overview

CSI_ORDER_SHIP_PUB is a public PL/SQL API within the Oracle E-Business Suite Install Base (CSI) module. Its API name, exposed through the package-level variable g_api_name, is order_shipment, which is the string most commonly used when searching for this object. The package is owned by APPS and classified as a PUB (public) API, meaning Oracle supports its invocation from external code such as Oracle Order Management, Oracle Work in Process, and custom extensions.

The primary business function of CSI_ORDER_SHIP_PUB is to record and maintain Install Base transactions that arise from shipping order lines. When order management ships a shippable item, the transaction must be reflected in Install Base so that assets, item instances, and their relationships are created or updated. This package performs that synchronization: it matches material shipping transactions to Install Base transactions, builds the shipment detail structures, updates installation records, and writes the transaction, transaction-line, and line-detail rows required by the CSI schema.

Key Procedures and Functions

• ORDER_SHIPMENT — the main entry point. It accepts shipment / order line context and drives creation of the Install Base transaction resulting from an order shipment.
• GET_ORDER_SHIPMENT_REC — retrieves the order shipment record used as the basis for processing.
• BUILD_SHTD_TABLE — constructs the shipment table (SHTD, shipment transaction detail) that the API processes.
• CONSTRUCT_FOR_TXN_EXISTS — determines whether a transaction already exists, supporting idempotent processing and avoiding duplicate Install Base records.
• VALIDATE_TXN_TBL — validates the transaction table contents before insertion.
• MATCH_TXN_WITH_SHIP — matches an incoming material transaction to the corresponding shipment record, ensuring the correct source line and header references are used.
• PROCESS_TXN_DTL — processes transaction detail rows, writing the line and line-detail records in the CSI tables.
• PROCESS_OPTION_ITEM — handles option items (for example, configured items or their children) within the shipment processing flow.
• REBUILD_SHIPPING_TBL — regenerates the shipping table when re-processing is required.
• UPDATE_INSTALL_BASE — applies the shipment to Install Base, updating item instance and asset records.
• OKE_SHIPMENT — integrates shipment information with Oracle Contracts (OKE) for contracted items.
• GET_COMP_INSTANCES_FROM_WIP — retrieves component instances from Oracle Work in Process, supporting WIP-driven shipments.
• DECODE_MESSAGE — translates internal message codes into user-readable messages for error handling.

Tables Accessed

The package reads and writes a range of Install Base tables. CSI_TRANSACTIONS, CSI_T_TRANSACTION_LINES, and CSI_T_TXN_LINE_DETAILS store the transaction header, lines, and detail rows produced by order shipping. CSI_ITEM_INSTANCES and CSI_I_ASSETS hold the item instance and asset records that are created or updated. CSI_II_RELATIONSHIPS and CSI_T_II_RELATIONSHIPS maintain instance-to-instance relationships, while CSI_I_PARTIES and CSI_T_PARTY_DETAILS_S hold party associations. Set-up tables including CSI_IB_TXN_TYPES, CSI_IEA_VALUES, and CSI_IP_ACCOUNTS supply transaction type, attribute value, and accounting information. CSI_I_ORG_ASSIGNMENTS and HR_ALL_ORGANIZATION_UNITS resolve organization context, and CSI_I_PRICING_ATTRIBS supplies pricing attributes where relevant.

Usage Notes

CSI_ORDER_SHIP_PUB is normally invoked by Oracle Order Management and Oracle Shipping Execution when order lines are confirmed as shipped, and by related Install Base processes. It is referenced by seven other packages, indicating it is called internally by other CSI APIs rather than being triggered solely by user interface actions. Installation scripts and upgrade drivers may also call it during data migration or reconciliation, and custom code can invoke ORDER_SHIPMENT to integrate external shipping feeds into Install Base.

The package relies on the standard EBS API conventions visible in its type declarations — FND_API.G_MISS_NUM, G_MISS_CHAR, and G_MISS_DATE sentinels, and record/table structures such as model_inst_rec, MTL_TXN_REC, and item_control_rec — so callers should expect the usual attribute-tolerance semantics and standard p_return_status output. Because the API writes multiple Install Base tables in one logical transaction, custom callers should invoke it within a controlled transaction boundary and handle error messages via the standard message stack. The header stubs indicate it has been maintained across EBS 11i and R12 releases, including 12.1.1 and 12.2.2.