Search Results scredit_rec_type

Overview

APPS.OE_BULK_ORDER_PVT is an internal (private) PL/SQL package within the Oracle Order Management module of Oracle E-Business Suite. It provides the core processing engine used by higher-level public APIs and concurrent programs to import, validate, and transform bulk order data staged in the Order Management open interface tables. Its primary business purpose is to support high-volume order creation and update scenarios, where large batches of sales order headers and lines are loaded and then processed through a single bulk operation rather than one record at a time. The package is therefore central to performance-sensitive integrations — such as EDI order feeds, legacy migrations, and external system handoffs — that depend on the open interface rather than direct table inserts.

A distinguishing characteristic of the package is its use of strongly typed collection and record definitions. The HEADER_REC_TYPE record and its companion table types define the structure of header-level interface data, including IDs such as accounting_rule_id, agreement_id, and the full complement of descriptive flexfield attribute columns (attribute1 through attribute20). The header comment explicitly notes that the data type definitions were moved into OE_WSH_BULK_GRP, indicating that shared type definitions reside in that grouping package while OE_BULK_ORDER_PVT consumes them.

Key Procedures and Functions

The ETRM metadata documents three procedures and functions within this private API:

• PROCESS_BATCH — The principal driver of the package. It orchestrates the bulk processing of a batch of staged order interface records, coordinating validation, flexfield resolution, pricing, and the writing of order data into the production order tables. This is the entry point through which bulk order requests flow.
• GET_FLEX_ENABLED_FLAG — A utility function that determines whether a given descriptive flexfield is enabled. It is used during interface processing to decide whether flexfield attribute values supplied in the interface record should be validated, defaulted, or ignored.
• MARK_HEADER_ERROR — A diagnostic procedure that flags a header record as failed and records the associated error condition, allowing the originating interface record to be identified and corrected or reprocessed.

Because this is a private (PVT) package, these routines are not intended for direct invocation by customer code; they are called by the public bulk order APIs that wrap them.

Tables Accessed

The package reads and writes a specific set of interface, base, and control tables:

• OE_HEADERS_IFACE_ALL and OE_LINES_IFACE_ALL — the open interface staging tables holding incoming header and line data.
• OE_ORDER_HEADERS and OE_ORDER_LINES — the production sales order tables into which validated data is ultimately written.
• OE_ORDER_HOLDS — used to apply and track holds on orders generated from the batch.
• OE_SALES_CREDITS, OE_PRICE_ADJUSTMENTS, and OE_PRICE_ADJS_INTERFACE — sales credit and pricing adjustment data, both staged and applied.
• FND_DESCR_FLEX_COLUMN_USAGES — consulted by GET_FLEX_ENABLED_FLAG to resolve flexfield enablement.
• PLITBLM — the PL/SQL character table used for array processing and bulk operations.
• ONT_DBI_CHANGE_LOG — the Order Management change log, used to record modifications for downstream propagation.
• V$TIMER — referenced for timing and performance measurement of batch execution.

Usage Notes

OE_BULK_ORDER_PVT is invoked indirectly. It is called by 23 other packages in the Order Management schema and is typically reached through the bulk order processing concurrent program or the public API layer that presents interface data to it. Developers integrating with Order Management should populate OE_HEADERS_IFACE_ALL and OE_LINES_IFACE_ALL and then invoke the supported public entry point, allowing this package to perform validation and transformation. Direct calls to its procedures are unsupported, and because the package contains the $Header signature and is marked private, its interface may change across patches; custom code should target the public APIs instead. A recurring search term such as scredit_rec_type likely reflects a sales credit record type associated with the sales credit interface structures referenced here.