Search Results manually_insert_detail

Overview

OE_LINE_DETAILS_PKG is a public PL/SQL package in the Oracle E-Business Suite Order Management (ONT) schema, declared with AUTHID CURRENT_USER and owned by the APPS schema. It operates on the line detail level of order entry data, the granular row structure that stores component and scheduling information belonging to a parent order line. This includes inventory item references, component codes, quantities, schedule dates, lot and revision information, subinventory and warehouse assignments, and the descriptive flexfield attribute columns associated with each detail record.

In Oracle EBS 12.1.1 and 12.2.2, the package sits beneath the Order Management forms and business logic that manipulate order line details. The API classification is OTHER, indicating it is a supporting package rather than a top-level documented public API such as OE_ORDER_PUB. Its primary value to technical implementers is that it exposes a stable insert interface for line detail rows and a validation routine for scheduling attributes, both of which can be leveraged by custom code or by the standard order entry forms.

Key Procedures and Functions

The ETRM metadata documents two procedures:

• MANUALLY_INSERT_DETAIL — This is the procedure associated with the user search term "manually_insert_detail." It performs a manual insert of a row into the order line detail structure. The signature is extensive, carrying parameters for the primary key (P_Line_Detail_Id), standard WHO audit columns (creation and last update dates, users, and login), the parent line reference (P_Line_Id), the inventory item and component identifiers (P_Inventory_Item_Id, P_Component_Sequence_Id, P_Component_Code), quantity and schedule date, lot, subinventory, warehouse, and revision. It also receives the Customer_Requested_Lot_Flag, schedule status code, the DFF context and Attribute1 through Attribute15 columns, item flags (Included_Item_Flag, Shippable_Flag, Transactable_Flag, Reservable_Flag, Released_Flag, Configuration_Item_Flag), demand class code, unit of measure code, component ratio, revenue flag, a set of surrogate ID parameters, delivery, update flag, an IN OUT result parameter (P_Result), and P_Dpw_Assigned_Flag defaulting to 'N'. Several parameters are declared IN OUT (dates, P_Required_For_Revenue_Flag, and P_Result), meaning the caller may receive modified audit timestamps and a status result.
• VALIDATE_SCHEDULING_ATTRIBUTES — A validation procedure that checks scheduling-related attributes before or during a detail operation. Its documented parameters include P_DB_RECORD_FLAG, and the database-side values P_DB_QUANTITY, P_DB_WAREHOUSE_ID, P_DB_SCHEDULE_DATE, P_DB_SUBINVENTORY, and P_DB_REVISION. This indicates the routine compares incoming or current scheduling values against stored database values and flags inconsistencies or invalid combinations.

Tables Accessed

The documented table references are SO_LINE_DETAILS and DUAL. SO_LINE_DETAILS is the base Order Management table that stores the line-level detail rows this package manipulates; MANUALLY_INSERT_DETAIL writes to it, and VALIDATE_SCHEDULING_ATTRIBUTES reads scheduling columns such as quantity, warehouse, schedule date, subinventory, and revision from it. DUAL is used for scalar evaluation common in PL/SQL validation and flag logic, consistent with the P_DB_RECORD_FLAG pattern of determining whether a corresponding database record already exists.

Usage Notes

OE_LINE_DETAILS_PKG is not a user-facing form API; it is invoked by Order Management internally and is available to custom code through the APPS synonyms. The ETRM metadata records that it is referenced by one other package, confirming that standard ONT logic depends on it. Customizations that need to create or validate order line detail records, especially component details and schedules, can call MANUALLY_INSERT_DETAIL directly, supplying the parent P_Line_Id and the complete detail payload, and should inspect the P_Result output parameter for success or failure. Direct inserts should be performed within the same transaction and concurrency control context as the calling order logic, and developers should obtain primary key values consistently with Order Management numbering conventions. Because the package is AUTHID CURRENT_USER, grants on SO_LINE_DETAILS and related objects must be in place for the invoking schema. Where possible, callers should prefer the documented public order APIs and use these lower-level routines only when a specific line detail requirement cannot be met otherwise.