Search Results submit_pdoi_conc_prog

Overview

CTO_AUTO_PROCURE_PK is an Oracle EBS Configure-to-Order (CTO) package that supports automatic procurement of components and subassemblies required to fulfill configured sales order lines. Within the Oracle E-Business Suite 12.1.1 and 12.2.2 codebase, the package resides in the APPS schema and is classified as a standard CTO utility package (API classification OTHER). Its central responsibility is to determine sourcing needs for CTO order lines, evaluate line eligibility, and generate purchasing requisitions or documents — including requisition interface records and purchase order creation — for items that are procured rather than manufactured. The package operates at the intersection of Order Management, Bills of Material (BOM), Inventory, and Purchasing, ensuring that long-lead or externally sourced configuration components are acquired in a timely manner to meet the request or need-by dates of the parent order.

Key Procedures and Functions

The ETRM metadata documents thirteen procedures and functions in the package body, each addressing a discrete step in the auto-procure flow:

• GET_NEED_BY_DATE — derives the need-by date for a component based on lead times and configuration requirements.
• AUTO_CREATE_PUR_REQ_CR — the principal driver that automatically creates purchasing requisitions for CTO components requiring procurement.
• POPULATE_REQ_INTERFACE — stages requisition data into the purchasing requisition interface for processing.
• GET_RESERVED_QTY — returns the quantity already reserved against an order line or item.
• GET_NEW_ORDER_QTY — returns the newly added order quantity used when evaluating sourcing.
• CHECK_ORDER_LINE_STATUS — validates the current status of a CTO order line to determine whether procurement is applicable.
• CREATE_PURCHASING_DOC — creates the purchasing document (e.g., a standard purchase order) for sourced items.
• ROLLUP_LIST_PRICE — rolls up list prices across the configured structure for cost and pricing purposes.
• ROLLUP_PURCHASE_PRICE — rolls up purchase prices for the configured components.
• ROLLUP_BLANKET_PRICE — rolls up blanket agreement prices, supporting sourcing against blanket purchase agreements.
• CREATE_PURCHASE_DOC_BATCH — performs purchasing document creation in batch across multiple lines.
• SUBMIT_PDOI_CONC_PROG — submits the Purchasing Documents Open Interface (PDOI) concurrent program to import staged data.
• IS_LINE_ELIGIBLE — determines whether a given order line qualifies for automatic procurement processing.

Tables Accessed

Access to application tables occurs through APPS synonyms. BOM_CTO_ORDER_LINES and its temporary and upgrade variants (BOM_CTO_ORDER_LINES_TEMP, BOM_CTO_ORDER_LINES_UPG) hold the CTO order line details that drive eligibility and quantity checks. MTL_SYSTEM_ITEMS, MTL_ITEM_CATEGORIES, and MTL_ITEM_REVISIONS supply item master attributes, category assignments, and revision information used to determine sourcing and eligibility. MRP_SOURCING_RULES, MRP_SR_ASSIGNMENTS, and MRP_SR_RECEIPT_ORG provide sourcing rule definitions and receipt organization assignments that identify the correct supplier and destination for procurement. BOM_CALENDAR_DATES and BOM_EXPLOSION_TEMP support date derivation and component explosion. FINANCIALS_SYSTEM_PARAMS_ALL, HR_ALL_ORGANIZATION_UNITS, and HR_LOCATIONS_ALL supply financial and organizational defaults, while FND_USER resolves user context. These tables are predominantly read; write activity is directed to the requisition interface used by PDOI.

Usage Notes

CTO_AUTO_PROCURE_PK is typically invoked indirectly rather than called directly by end users. The package is referenced by several other CTO packages — including CTO_CHANGE_ORDER_PK, CTO_MATCH_AND_RESERVE, CTO_SUBASSEMBLY_SUP_PK, CTO_WORKFLOW, and CTO_WORKFLOW_API_PK — indicating it is driven by CTO workflow processing, order changes, and subassembly supply logic. Automatic procurement is generally triggered from Order Management workflows when a configured line requires externally sourced components, from concurrent programs that batch-process procurement, or from scheduled processing that stages requisition data and submits the PDOI concurrent program. Because the package writes to the requisition interface and submits concurrent requests, customizations should invoke it only within a properly committed transaction context and with the appropriate organization and user session initialized. Customers extending CTO auto-procure behavior should treat these procedures as standard APIs and avoid direct modification of the package, instead leveraging supported extension points or wrapper logic.