Order Import in Oracle Order Management

An Oracle White Paper March 2004

Order Import in Oracle Order Management

EXECUTIVE OVERVIEW INTRODUCTION BASIC FEATURES DATA MODEL ORDER IMPORT PROCESS PROCESS FLOW

3 3 3 16 19 27

Order Import in Order Management

Page 2

Order Import In Oracle Order Management

EXECUTIVE OVERVIEW

Order Import in Order Management allows import of Sales Orders from various sources (Internal and External) and of different statuses (Open, Closed). Some limitations of order import that were there in Order Entry (Release 11) have been corrected in Order Management (Release 11i). This white paper covers how Order Import Interface works in Order Management and serves as a functional and technical guide to the Order Import Interface. This paper covers the features available in OM Family pack H or below.
INTRODUCTION

Order Import is an Order Management Open Interface that consists of open interface tables and a set of APIs. Order Import can import changes for existing Sales Orders, new and completed sales orders or returns from various sources, both Oracle and Non Oracle, for example, legacy systems, EDI transactions that are processed by the Oracle e-Commerce Gateway, or internal orders created for internal requisitions developed in Oracle Purchasing or returns. Order Import features include validation and defaulting, processing constraint checks, applying and releasing of order holds, scheduling of shipments, and finally inserting, updating or deleting the orders in the base Order Management tables. Order Management checks all the data during the import process to ensure its validity within the module. Valid transactions are then converted into orders with lines, reservations, price adjustments, and sales credits in the base Order Management tables. It is to be noted here that Order Import does not populate any Shipping tables. If the order is imported as BOOKED then during the post booking process (when the Line status becomes AWAITING SHIPPING from BOOKED) will cause data to be written in the WSH_DELIVERY_DETAILS and WSH_DELIVERY_ASSIGNMENTS tables. Each time you run Order Import, Order Management produces a summary of information letting you know of the total number of orders that Order Import has evaluated, and if succeeded or failed.
BASIC FEATURES

This section gives a brief idea of the features available, the limitations and the Profile Options associated with Order Import in Release 11i.

Import Sources

Orders can be imported from different Import sources as long as the Import source is defined in the application and is enabled. This can consist of both Oracle and non-Oracle sources.
Order Import in Order Management Page 3

Status Of Orders

Orders can be imported as ENTERED, BOOKED or CLOSED. If an order is imported with an entry status of ENTERED (OE_HEADERS_IFACE_ALL.BOOKED_FLAG=N or NULL) then the result after import is that the line is BOOK_ORDER eligible. Order can be imported in Booked condition using one of the following methods: By populating the column BOOK_FLAG of the table OE_HEADERS_IFACE_ALL as Y. By passing the action request to the OE_ACTIONS_IFACE_ALL table, i.e. in the OE_HEADERS_IFACE_ALL do not pass the BOOK_FLAG and in the OE_ACTIONS_IFACE_ALL table put operation code as BOOK_ORDER. Order Import ensures that all required fields for entry or booking are validated appropriately as the orders are imported. It imports the order as Entered and attempts to book it. If any of the required fields for a booked order are not supplied, Order Management retains the order in the ENTERED status and notifies you of the error. Closed Order is treated differently than the open orders while importing. Importing order the first time in Closed status, means importing order from the legacy system where they were already Closed to Oracle OM system, they should pass Closed_Flag as "Y" and operation_code should be "INSERT". The Closed_Flag should be passed as "Y" to the oe_headers_iface_all table. As orders were already closed in the old system, there cannot be any changes performed to the records, which means no defaulting. For example, while importing open orders if the order_type is not passed and defaulting rule is set, the value of order_type can be generated and assigned to order_type column, however this part cannot be done for the Closed Order Import in which case all the mandatory columns such as Closed Order must go through the booking cycle. The validation for all the booking required columns could be done. The only difference being that the two columns Transactional currency code, and the line number are passed for importing closed orders which is not required for open orders.

WORKLOW

Order can be imported within any valid order workflow activity but this valid workflow has to be the initial activity of Entered, Booked, or Closed. Orders imported using Order Import cannot be in the middle of a workflow activity.
SCHEDULING

Order Import allows you to reserve orders as they are imported, using the same rules as online order entry. If the scheduling request is unsuccessful on an imported order, the order will still be imported, and the scheduling exceptions can be viewed in the Error Messages of the Order Import Corrections window. To unscheduled a line by order import the operation_code should be UPDATE and the request_date and scheduled_ship_date on OE_LINES_IFACE_ALL should be NULL However, before Patchset G, this order import will fail if scheduling fails with the message Unable to meet latest acceptable Date. One work around was to set up
Order Import in Order Management Page 4

the latest acceptable date to be larger than the infinite supply time horizon for the items. This ensures that scheduling never fails on the internal orders and they get into OM without a problem. Order import will also fail if SCHEDULE_SHIP_DATE is populated in the interface or is defaulted and scheduling fails. The following are the scenarios in detail. 1. 2. If ATP is available at request date of requisition: OK/ Order is created; Scheduling is done If ATP is not available at need_by_date (request_date) of requisition but ATP is available at (request_date + x days) and that (request_date + x days) <= Latest acceptable date then the order is imported and scheduled at date = (request_date + x days) If ATP is neither available at need_by_date (request_date) of requisition nor available at date < Latest acceptable date, then the order is not created and the import fails with the message Scheduling failed - Unable to meet the latest acceptable date.

3.

Another workaround is to use PDS (Planning Data Store) instead of ODS (Operation Data Store) as there is a change with MRP Patchset E whereby scheduling of Internal Orders always succeed when running in a PDS Planning mode.

Post Patchset G for internal Orders PO will only pass the request_date, which will be treated as schedule_arrival_date, and schedule_ship_date will be calculated by MRP APIs, which look at the shipping network setup to determine intransit and lead times.
For ATO and PTO items when the order is imported in booked status, the scheduling level for the order type and line type is set to all scheduling actions, It will reserve only the PTO components. ATO components will not be reserved when order is booked. ATO components will be reserved when the work order is opened.
Cancellation of Order using Order Import

If the entire order is to be cancelled, then the lines information should not be loaded into the interface table and the header interface table should have the cancelled_flag set to 'Y' and the CHANGE_REASON as a valid lookup code from CANCEL_CODE lookup type. If only the line is to be cancelled, then both the lines and the header tables should be populated in the interface table but should set the cancelled_flag to 'Y' only for the lines with the qty updated to zero. Also the operation code to be used for cancellation should be UPDATE . If the both the order and the line cancelled_flag is set to 'Y' then in such cases the program cancels the header along with the lines because the header cancelled_flag is 'Y'. Then since the line cancelled_flag is also 'Y' it tries to cancel the already cancelled line and errors out. So depending on whether the order or the line is to be cancelled, the cancelled flag and the header information or the line information should to be loaded.

Order Import in Order Management

Page 5

Updating Existing Orders using Order Import

While updating existing Sales Orders, the Operation_code should be UPDATE. When an existing order is updated, the header_id and other Order related details are queried based on the Order Source Id and the Orig Sys Document Ref number. For the Order Line, the Order_source_id ,Orig_sys_document_ref, and Orig_sys_line_ref are used to get the specific line for updation. Sales Order created using the Sales Order form can be updated using Order Import and the Order Import source is Online ( Order_source_id = 0). An Order cannot be updated to status closed as it is assumed that after importing the order, it will be processed in OM until closure.
Importing Closed Orders using Order Import

Closed Orders are treated differently from open orders 1. 2. 3. 4. To Import Closed Orders oe_headers_iface_all table should have the closed_flag as "Y" and the operation_code as INSERT There is a difference between closing an existing order and importing orders in "CLOSED" status the first time itself. As orders were already closed in the old system, there will not be any changes performed to the records, which means no defaulting. All the book required columns need to be passed for importing a Closed Order, as it goes through the booking cycle where validation for all the booking required columns are done.

Add Customer

Order Management provides the capability to add a new customer, the address and contacts using Order Import. The table OE_CUSTOMER_INFO_IFACE_ALL needs to be populated for this. Based on the data available in the OE_HEADERS_IFACE_ALL the data from the table OE_CUSTOMER_INFO_IFACE_ALL is processed to add a new customer. This table can also be used to import a new address only or contact information of an existing Customer. The link between the header interface record and the customer interface record is made through the column CUSTOMER_INFO_REF of the table OE_CUSTOMER_INFO_IFACE_ALL and any one of the columns mentioned below. The link depends on the CUSTOMER_INFO_TYPE_CODE. When the order import is used to create a new customer (new account/address/contact etc), the CUSTOMER_INFO_TYPE_CODE should be either ('ACCOUNT', 'ADDRESS', or 'CONTACT') to denote the type of information in the record. The following table explains the linkage between the various header interface table columns and the column CUSTOMER_INFO_TYPE_CODE and the usage of the combination.
OE_CUSTOMER_INFO_IFACE_ALL OE_HEADERS_IFACE_ALL

Usage

CUSTOMER_INFO_TYPE_CODE

Result New Customer account will get created

Orig_Sys_Customer_Ref

ACCOUNT

Order Import in Order Management

Page 6

Orig_Ship_Address_Ref Orig_Bill_Address_Ref Orig_Deliver_Address_Ref Sold_to_Contact_Ref Ship_to_Contact_Ref Bill_to_Contact_Ref Deliver_to_Contact_Ref

SHIP_TO BILL_TO DELIVER_TO SOLD_TO SHIP_TO BILL_TO DELIVER_TO

ADDRESS ADDRESS ADDRESS CONTACT CONTACT CONTACT CONTACT

New Ship to address will get created New Bill to address will get created New Deliver to address will get created New Sold to Contact will get created New Ship to Contact will get created New Bill to Contact will get created New Deliver to Contact will get created

The following profiles affect the add customer functionality. 1. OM: Add Customer (Order Import) This will decide whether the customer can be imported using order import. This must be set to ALL for importing new customer account and to Address and Contact only for importing addresses and contacts alone. The eligible values for the profile are as follows:

N = None P = Address and Contact only Y = All 2. OM: Email Required on New Customers This will decide whether the records in the oe_customer_info_iface_all should have the email or not. If the profile is set to Yes then you must enter a not null value in the field EMAIL_ADDRESS of the table OE_CUSTOMER_INFO_IFACE_ALL. 3. HZ: Generate Party Number = YES or NULL This will decide whether the records in the oe_customer_info_iface_all should have the party number or not. If the profile is set to Yes then you must enter a not null value in the field PARTY_NUMBER of the table OE_CUSTOMER_INFO_IFACE_ALL. 4. HZ: Generate Contact Number = YES or NULL. If this is set to N then Order Import program will generate the Contact Number. If this is set to YES or NULL then it will be generated later while creating the Contact. 5 HZ: Generate Party Site Number = YES or NULL. This will decide whether the records in the oe_customer_info_iface_all should have the site number or not. If the profile is set to Yes then you must enter a not null value in the field SITE_NUMBER of the table OE_CUSTOMER_INFO_IFACE_ALL.
Order Import in Order Management Page 7

The value of the profile option Automatic Customer Numbering and Automatic Site Numbering from the AR System Options are also important. If the flags are unchecked in the option, then the following fields of the table OE_CUSTOMER_INFO_IFACE_ALL must have a not null value. CUSTOMER_NUMBER if Automatic Customer Numbering is unchecked LOCATION_NUMBER if Automatic Site Numbering is unchecked Order Import will respect the setting of the OM System Parameter Customer Relationships (Setup=>Parameters) and create customer-to-customer relationships if needed and allowed. The parameter values will be interpreted as follows: Customer Relationships = Single Customer The Ship_To, Deliver_To and Bill_To addresses must belong to the Sold_To customer on the order. If an attempt is made to import an order with a Bill_To, Deliver_To or Ship_To from a different customer than the Sold_To, Order Import will raise an error and the order will not be imported. Customer Relationships = Related Customers If a new customer is added for a Ship_To, Bill_To, or Deliver_To address, the appropriate relationship will be created in the TCA (Trading Community Architecture) Customer Relationships = All Customers A new customer can be added, but no relationship creation occurs.

Importing an order using a new Customer information will require you to add and also to remove some data from the headers interface table depending on the kind of information being imported. For example if the customer account alone is to be imported then the Orig_Sys_Customer_Ref needs to be populated and the sold_to_org/sold_to_org_id should be populated as null. Some or all of the following data is to be populated in oe_headers_iface_all table,
Orig_Sys_Customer_Ref Orig_Ship_Address_Ref Orig_Bill_Address_Ref Orig_Deliver_Address_Ref Sold_to_Contact_Ref Ship_to_Contact_Ref Bill_to_Contact_Ref

Deliver_to_Contact_Ref And some or all of the following data needs to be removed from the oe_headers_iface_all tables depending upon the information being imported.
sold_to_org / sold_to_org_id invoice_to_org / invoice_to_org_id ship_to_org / ship_to_org_id

Order Import in Order Management

Page 8

Against this the oe_customer_info_iface_all table needs to be populated. The number of records being populated will depend on what is being imported. For example while importing only the customer account only one record will be populated and while importing account, address and contacts three or more records will be populated.

If the customer addresses are to be different for ship, bill, and deliver, then three different records need to be populated. Whether an address is for ship, bill, or deliver, is decided by the following columns of the oe_customer_info_iface_all tableIS_SHIP_TO_ADDRESS, IS_BILL_TO_ADDRESS, IS_DELIVER_TO_ADDRESS These take the values Y, N or null. So if the particular record needs to be only a bill to address, then the IS_BILL_TO_ADDRESS should be set as Y and the rest as N or null. If the same address needs to be Bill to, ship to and deliver to Address then the flag should be set as Y against all the three columns. The link between the Account record and the address or contact record is through the column PARENT_CUSTOMER_REF. This should be populated in the address or contact record with the CUSTOMER_INFO_REF of the account record. For example,
If the CUSTOMER_INFO_REF in the record with the CUSTOMER_INFO_TYPE_CODE as ACCOUNT is XXXX then the PARENT_CUSTOMER_REF for the record with the CUSTOMER_INFO_TYPE_CODE as ADDRESS or CONTACT should be XXXX. Importing Sales Credit

Both Quota and Non Quota Sales Credit can be imported. The table OE_CREDITS_IFACE_ALL has to be populated for this.
Importing Price Adjustments

Manual Price Adjustments can be imported using the tables OE_PRICE_ADJS_IFACE_ALL and OE_PRICE_ATTRS_IFACE_ALL. The table OE_PRICE_ADJS_IFACE_ALL is populated with the adjustment to be imported along with the line. This information is passed to the process order API, and the manual adjustment is applied on the line when the order is processed for import. The following columns can be passed as Y if price adjustment is not to be applied on the Order/ Line again by the pricing engine overriding all the changes done based on value populated in the OE_PRICE_ADJS_IFACE_ALL and OE_PRICE_ADJS_IFACE_ALL tables. In the OE_LINES_IFACE_ALL --- CALCULATE_PRICE_FLAG should be Y. When this flag is passed as Y the pricing engine calculates the selling price after applying the eligible automatic modifiers. In the OE_PRICE_ADJS_IFACE_ALL --- APPLIED_FLAG should be Y-UPDATED_FLAG should be Y.

Order Import in Order Management

Page 9

While trying to import pricing contexts and pricing attributes along with the line the table OE_PRICE_ATTS_IFACE_ALL needs to be populated. Some of the important fields should be populated with the below mentioned values, orig_sys_document_ref = same as in lines Iface all orig_sys_document_ref orig_sys_line_ref = same as in lines Iface all orig_sys_line_ref

orig_sys_shipment_ref = same as in lines Iface all orig_sys_shipment_ref Orig_sys_atts_ref = needs to have a not null value

flex_title = Title of the flexfield for example for pricing contexts it should be QP_ATTR_DEFNS_PRICING . The value field flex_title against the DFF Pricing Contexts can be found from the application itself. Navigation Application Developer --> Flexfield --> Descriptive --> Register, Here query the DFF and title of the DFF is the value which needs to be populated in the column flex_title.
Manual and Automatic Pricing

Users can indicate whether you want to manually enter prices for imported orders or allow Order Management to automatically price the order. You can use automatic pricing or manual pricing for your imported orders. Pricing in process order API is controlled using flag calculate_price_flag on order line record. When set to Y the process order API fetches the list price and applies adjustments and charges. When set to N, the process order API would fetch a list price if the list price is not passed and no adjustments would be applied. When set to P, all the modifiers that are associated with phases having override freeze flag set to Y are applied. That mainly includes freight charges. If you want to use automatic pricing, you should set the column OE_LINES_IFACE_ALL.CALCULATE_PRICE_ FLAG to Y, and define all your pricing setup including discounts, promotions, surcharges, free goods, etc. in Oracle Pricing and Order Management. For manual pricing, in the table OE_LINES_IFACE_ALL set the columns CALCULATE_PRICE_FLAG to N, the UNIT_LIST_PRICE and UNIT_SELLING_PRICE columns with not null values. In this case, you should define all your discounts as line level, overidable, and not automatic. When the value of the column CALCULATE_PRICE_FLAG is P then the selling price is recalculated and so the Pricing_quantity and the pricing_quantity_uom have to be populated. Order_quantity_uom and the pricing_quantity_uom have to be populated if the extended price is to be calculated later on changing the quantity on the SO. Note: Order Import does not support the importing of free goods, promotions, and other item discounts for manual pricing.
Price Comparison

Order Import performs a price comparison on imported orders. If a selling price has been provided and Calculate_price_flag is Y, Order Import warns of the
Order Import in Order Management Page 10

differences, if any, between the two prices as discrepancies. The warning can be viewed in the Error Message window of the Order Import Corrections window. i. ii. Order, Returns -> Process Messages -> (Provide Request Id to Query) Order, Returns -> Import Orders -> Corrections -> Query on some existing order (as successfully imported orders are deleted from the interface table) -> Use Error Button to go to the process message UI and query the request.

For this functionality to work, the customer_item_net_price column on the interface table should be populated. Only in that case, if the unit_selling_price calculated by system is different from the price passed by the customer (in customer_item_net_price), a warning message will be issued by Order Import. Order Import saves the customer-provided value for the selling price in a column on the order line table (CUSTOMER_ITEM_NET_PRICE), so you can have visibility to what your customer sent in. You cannot copy or interface an order line having a price list with a currency code different from the existing or newly created order header's currency code. An error message will be displayed in the Process Messages window Following is a table with examples of what would happen in different cases of the customer price and the system price. In addition, it shows how the Calculate Price Flag affects the process: Table : Example of Customer Price and the System Price Calculate_Price_flag Customer provided Price 100 100 System Calculated Price NULL 100 Action

N Y

Accept Customer Price

Accept System price. (System = Customer).

100

80

Accept System price but issue warning. (System < Customer).

100

120

Accept System price but issue warning (System > Customer).

Payment term comparison

Order Import performs payment term comparisons. If there is a difference between the payment terms used in the order import and the one defined in the system, Order Import raises a warning for this difference. Order Import saves the customer-provided value for payment terms in a column on the order line table
Order Import in Order Management Page 11

(CUSTOMER_PAYMENT_TERM_ID) so that what the customer has sent is visible.

Importing Returns

Returns can be imported like a regular sales order. Order Management utilizes workflow activities to import returns.
Creation of a non-referenced RMA

If you want to import a return order for a non-referenced return, you must populate all required attributes for creating a return order. Use an order category of RETURN or MIXED for the Order Header record. Populate all required attributes for creating a return order line. For Order Line Record, you cannot specify a value for the line category_code column. You need to populate the column ordered_quantity with a negative value. Line_type_id is optional, (provided a default line_type has been defined for the specified Order Type.). You will need to populate the column reason_code for all return lines. Valid values are those values defined for the Order Management QuickCode CREDIT_MEMO_REASON.
Creation of a Referenced RMA (If users want to return an existing outbound line)

If you create a referenced RMA, you should copy the Header Record for the return from the referenced Order header record, modifying the Order Type to category RETURN or MIXED (order_type_id from oe_transaction_types_all). For the Order Line record, populate the following attributes only: 1. line_category_code: RETURN

2. return_context: ORDER 3. return_attribute1: header_id from the referenced order. 4. return_attribute2: line_id from the referenced order line. 5. calculate_price_flag: Set it to P if you want to retain the original price, the flag to Y if you want to reprice the RMA line. Putting the flag to N will still import the freight charges from the referenced line. 6. line_type_id: Assign a line_type_id from RMA line. Line_type_id is optional, provided a default line_type has been defined for the specified Order Line Type. )

7. Return_reason_code: Populate a reason code from lookup_type

CREDIT_MEMO_REASON 8. For sales credit info, populate the header_level/line level sales credits details from the referenced order. Note: Before patchset H there is no validation done for the reason code while importing the Return Order. However, if the Reason Code is Invalid then after importing it will be shown in the sales order form as NULL. To get the Valid Reason Code, set the Org context using the following procedure: exec fnd_client_info.set_org_context(&org_id); then use the following query: SELECT LOOKUP_CODE FROM OE_AR_LOOKUPS_V
Order Import in Order Management Page 12

WHERE 'CREDIT_MEMO_REASON' AND

LOOKUP_TYPE = ENABLED_FLAG = 'Y'

AND SYSDATE BETWEEN NVL (START_DATE_ACTIVE, SYSDATE) AND NVL (END_DATE_ACTIVE, SYSDATE);
Credit Checking

Order Management performs credit checking on all imported orders, or changes according to the credit checking rules you have been defined in Order Management.
Holds and Releases

Order Management automatically applies all holds to imported orders and order lines that meet hold criteria. Order Import applies holds on imported orders for review, just as you would for orders entered through the Sales Orders window. Holds can be applied or released using OE_ACTIONS_IFACE_ALL. For applying HOLD using the actions table the operation_code for the header and the lines Interface table should have operation code as UPDATE and in OE_ACTIONS_IFACE_ALL, the Operation_Code should be APPLY_HOLD and the Hold_ID needs to be populated. For releasing the hold using OE_ACTIONS_IFACE_ALL, the operation_code for the header and the lines Interface table should have operation code as UPDATE and in the actions table the Operation_Code should be RELEASE_HOLD. The HOLD_ID and the RELEASE_REASON_CODE should also be populated.
Defaulting Rule and Processing Constraint

You can setup your defaulting rules that allow users to default columns in the same way as for orders entered online. You can pass the column value Null to Order Import if you want the defaulting rules to populate the column. However, if the column is defined as Not Null or Mandatory column and the defaulting rules fail to default the column for any reason, Order Import displays an error message without importing the order. To default the header or line level DFF, the attributes 1 - 15 need to be populated but one thing that needs to be ensured is that although the size of these columns is 240 in the interface tables and the OM tables, only 150 characters are passed to AR during Invoice Interface. If a descriptive flex field segment is defined as mandatory, but no default value is defined in the Application, then the user needs to populate a value for this segment in the interface table. Else Order Import will fail in flex field validation. Order Import checks the processing constraints defined in Order Management to assure that any operation such as insert, update, and delete are acceptable by the security standards. Order Import displays an error message if it encounters a processing constraint that has been violated.
Notes and Attachment

Order Management will apply the automatic attachments to imported orders that meet the automatic note criteria based on the setting of the OM: Apply Automatic
Order Import in Order Management Page 13

Attachments profile option or in the Actions table, the operation code can be put as AUTOMATIC_ATCHMT for Applying Automatic Attachments.
Configuration (ATO/PTO)

Order Management provides you with the ability to import ATO and PTO configurations. For EDI orders, you can import valid and invalid configurations, however, you will not be able to book orders with invalid configurations. In case of (Configurations) ATO models (also in case of PTO models), user has to send the optional components along with model. This is because although OM knows the BOM of the ATO model, it will not know what options user wants to select. User should not send the standard mandatory components. The following operation Code can be used in the actions table for the configurations. For both the operation codes, the Entity Id used is the Line_ID of the Top Model Line of the ATO Configuration. -- DELINK_CONFIG deletes the configuration item. -- MATCH_AND_RESERVE checks if an existing configuration item matches the configuration created by the user and if the configuration item is available, it reserves it. Table : Operation Code for Configuration
ACTION OPERATION_CODE OTHER DATA

Delink the Config Item

DELINK_CONFIG

none

Match and Reserve a configuration item for an ATO model

MATCH_AND_RESERVE

none

Line Sets

Unlike in Order Import in Order Entry (10.7 and 11) Line sets like arrival Set, Invoice Set and Fulfillment Set are allowed to be imported in 11i. You can import grouped order lines, called sets, for a new or existing orders. You can also add a line to an existing set. If that set already exists, the line will be included in the set. However, if the set does not already exist, a new set will be created and the line will be added to the set. In addition, if any line attribute which is also a set attribute, does not match with the set attribute value, the set attribute value will overwrite the line attribute. A line can be added to a new set by passing set name (ship_set_name/arrival_Set_name/fullfillment_set_name/invoice_set_name) on the line record (OE_LINES_IFACE_ALL). Or use the set id (ship_set_id/arrival_set_id/fulfillment_set_id/invoice_set_id) to add to an existing set.
Importing Service Lines

There are 3 different scenarios in which service lines can be imported

Order Import in Order Management

Page 14

1. When the service line is part of the same order. This is what can be called as immediate service. The Order will have 2 lines, one the line to be serviced and the second the service line itself. In this case the Service_Reference_Order will be the orig_sys_document_ref of the Order itself and the Service_Reference_Line will be the orig_sys_line_ref of the item line to be serviced. (That would be the first line) 2. This is what may be termed delayed service. In this scenario the service is a different Order itself. The orig_sys_document_ref on this Order will be a new one. The Service_Reference_Order will be the orig_sys_document_ref of the Order, which has the item for which Service is being ordered. Similarly the Service_Reference_Line will be the orig_sys_line_ref of the line for which Service is being ordered. 3. The third scenario is what may be called semi-delayed service. In this case you are trying to add the Service line to the original Order itself, which has the line, which needs service. In this case the orig_sys_document_ref should be the same as the Order to which you are adding the line. The operation_code on the header should be UPDATE. The Service_Reference_Order should be the same as the orig_sys_document_ref and the Service_Reference_Line should be the orig_sys_line_ref of the line for which service is being ordered.
Adding Lines to existing Orders

In Order Management, a new line can be added to an existing order or an existing line can be split into two or more lines. For this, the Operation Code at the header should be UPDATE and the operation code at the line level should be INSERT or CREATE. If the SPLIT_FROM_LINE_REF, is populated then the LINE_ID in the line table is taken as the SPLIT_FROM_LINE_ID and that line is SPLIT. In case it is not populated then a new line is added to the existing order.
Validation of data Before Importing

Unlike in Order Import in Rel 11, in 11i the Order Import process can be run in the validation-only mode. This mode allows the transaction to be validated against all the Order Management rules but does not allow it to pass valid transactions to the base Order Management tables. Users can run production transactions in validation-only mode for a preview of exceptions. Make necessary corrections to the transactions in the Order Import window, and then choose the Validate button to perform a validation check. The validation-only mode may also facilitate testing of transactions through Order Import even in a production environment to take advantage of all the setup in the production environment.
Viewing Orders that have failed

In Order Management Rel 11i, the orders that have failed in Order Import can be viewed in the Corrections summary window. These orders are highlighted in red in the window.
Viewing Errors

In Order Management, the error can also be viewed from the Application. The order that have failed in Order Import can be selected from the Corrections Form (OEXOIMPT) and the error can be seen using the Error Button. The error
Order Import in Order Management Page 15

messages stored are context sensitive. If you choose the Errors button from the Order Header region, all the errors for that order are displayed. If you choose the Errors button from the Lines region, all the errors are displayed for that line. If you encounter errors while importing orders, you can also fix these errors in the window and try importing the order again. You can navigate from the Errors window to the Order Headers or Lines region where the error has occurred. The error can also be seen in the Order Import Log file when importing using the Order Import concurrent request.
Correcting Errors from the Form

In Order Management, the failed orders can be modified from the Corrections form. The value in the fields of oe_headers_iface_all and oe_lines_iface_all tables can be inserted, updated, and deleted from the Summary form. One or multiple orders or lines can be updated at the same time through the Summary window. But multi selection of lines is not allowed. You can also mark an order or a line to be rejected by setting the REJECTED flag. Once the error is corrected, the ERROR flag is unchecked and the REQUEST_ID field cleared, the order can be resubmitted for Import from the Summary window.
Customer Item Number

Customer items numbers or UPC numbers can be used in Order Import in the same way as a manually entered Sales Order as long as all cross-reference data is defined before the Order Import process is run. Set the OE_LINES_IFACE_ALL. CUSTOMER_ITEM_NAME to the 'item ordered'. If you know what kind of item number it is (for example customer or inventory), you can set the inventory_item (It is optional but in that case customer_item_name should be unique in cross reference table) and the OE_LINES_IFACE_ALL.CUSTOMER_ITEM_ID_TYPE.
Gather Schema Statistics for Import Tables

The Concurrent request Order Import Gather should be run to gather statistics for the interface tables. The request should be run before running the Order Import program to improve Order Import programs performance.
DATA MODEL

This section graphically represents the tables that store imported order information and the relationships between them.

Order Import in Order Management

Page 16

Figure 1 ER Diagram

A summarization for each of the tables shown in the ER diagram has been done below.

OE_ORDER_SOURCES

All the Interface tables for validating the Order import source use this table. For every row in OE_ORDER_SOURCES, there can be one or more rows in the seven interface tables and the two base tables.
OE_HEADERS_IFACE_ALL

This is a multiorg table for sales order headers open interface. The table stores order header information that will be imported into the OM tables after successful running of Order Import. This is related to two other interface tables OE_CREDIT_IFACE_ALL and OE_LINES_IFACE_ALL. Corresponding to each record in this table, there can be one or more records in the OE_CREDIT_IFACE_ALL and OE_LINES_IFACE_ALL tables. In the OE_HEADERS_IFACE_ALL, the orig_sys_document_ref and order_source_id form the unique key and in case you have populated more than one record with the same orig_sys_document_ref and order_source_id, then only one will get imported and if you delete one from the corrections table, all will get deleted.
Order Import in Order Management Page 17

OE_LINES_IFACE_ALL This is a multiorg table for sales order lines open interface. The table stores order lines information that is imported into the OM tables. Each row in this table has at least one corresponding row in the OE_HEADERS_IFACE_ALL and OE_ORDER_SOURCES tables.

If there are rows in the OE_CREDITS_IFACE_ALL OE_LOTSERIAL_IFACE_ALL tables then for each row OE_LINES_IFACE_ALL there can be one or more than one row in these tables. In OE_HEADERS_IFACE_ALL, there are two columns, which referenced from the same table, LINK_TO_LINE_REF TOP_MODEL_LINE_REF.
OE_LOTSERIAL_IFACE_ALL

and in two are and

This is a multiorg table for return line lot serials open interface. The table stores return line lot serial information of records that are imported into Oracle Order Management using Order Import. The column LOT_NUMBER needs to be populated if the item is lot controlled, it can take both numeric and alphanumeric in the latest version of Order Management. The orig_sys_document_ref , the orig_sys_line_ref , the orig_sys_lotserial_ref and order_source_id are to be populated when using this table and the orig_sys_line_ref has to be populated with a not null value. Each record can be related to the OE_LINES_IFACE_ALL, ORDER_SOURCES_ALL and OE_ORDER_LINES_ALL.
OE_CREDIT_IFACE_ALL

This is a multiorg table for sales order/line credits open interface. This table stores sales credits information of records that are imported into Oracle Order Management using Order Import. Each record here is connected to a record in the OE_LINES_IFACE_ALL, OE_HEADERS_IFACE_ALL and ORDER_SOURCES_ALL tables. There can be more than one row in OE_CREDIT_IFACE_ALL table against each record in the OE_LINES_IFACE_ALL,
OE_HEADERS_IFACE_ALL and ORDER_SOURCES_ALL tables.
OE_RESERVTNS_IFACE_ALL

This is a multiorg table for inventory reservations open interface. This table stores reservation details of records that are imported into Oracle Order Management using Order Import. The records of this table are
connected to OE_LINES_IFACE_ALL via orig_sys_line_ref and orig_sys_shipment_ref. OE_PRICE_ADJS_IFACE_ALL This is a multiorg open interface table for sales order/line price adjustments. This table stores price adjustment information that is imported into Oracle Order Management using Order Import. The records of this table are connected to OE_HEADERS_IFACE_ALL via orig_sys_document_ref, and to OE_LINES_IFACE_ALL via orig_sys_line_ref and orig_sys_shipment_ref.

Order Import in Order Management

Page 18

OE_PRICE_ATTS_IFACE_ALL

This is a multiorg Interface table used to populate OE_ORDER_PRICE_ATTRIBS. This table stores pricing attribute information that is imported into Oracle Order Management using Order Import. The records of this table are connected to OE_LINES_IFACE_ALL via orig_sys_line_ref and orig_sys_shipment_ref
OE_CUSTOMER_INFO_IFACE_ALL

This is the multi-org open interface table for customer import. This table stores information required for creating a new customer using Order Import. This data of this table is linked to the table OE_HEADERS_IFACE_ALL through any one of the following columns Orig_Sys_Customer_Ref Orig_Ship_Address_Ref Orig_Bill_Address_Ref Orig_Deliver_Address_Ref Sold_to_Contact_Ref Ship_to_Contact_Ref Bill_to_Contact_Ref Deliver_to_Contact_Ref
This data of this table is linked to the table OE_LINES_IFACE_ALL through any one of the following columns

Orig_Ship_Address_Ref Orig_Bill_Address_Ref Orig_Deliver_Address_Ref Ship_to_Contact_Ref Bill_to_Contact_Ref Deliver_to_Contact_Ref

ORDER IMPORT PROCESS

This section explains the Order Import process, the tables involved and the means available to validate, run and correct the data if required. The requirement is to convert the existing data in the legacy system or that coming from the customer (Web Enabled) to data that can be understood by the Oracle Application. This conversion of data which enables the Application to understand and further process it, is done by the Open Interface APIs. For testing the data a single sample record can be populated onto the interface tables and the record can be validated by running the order import request with Parameter Validated as YES. Once the validation is successful, more records can be populated on to the interface tables and the Order Import batch processes can be run to import (either by running the Order import concurrent request or by importing directly from the Corrections form) to process the entered data and convert it to legitimate orders.
Order Import in Order Management Page 19

Methods for loading data onto the interface tables

A stored procedure can be written to extract data from an existing system and put it directly into these interface tables. If data is from a non-Oracle based system, loading can be done by first converting it to flat files and then using an Oracle utility called SQL*LOADER. This reads each position in the two dimensional flat file and converts it to a field value for the interface tables. Data in the interface tables is picked up by the concurrent managers, which validates it based on the arguments specified in the interface tables and converts it to orders by updating the concerned base tables. Records that fail validation have the Error Flag set to Y and remain in the Interface tables, and can be seen in the Corrections form (these lines will be highlighted in red). These failed records can be corrected in this window and re-imported from the Corrections window. There is no Process Exception Report in Order Management. Hence, a change in the functionality from the earlier versions of order imports. The difference between importing from the Corrections form and using the request is that in case of the concurrent request, a debug log file is generated (information depends on the OM Debug Level). Orders can be imported in any valid entry status, including Booked. It also allows completed orders to be imported. It also allows the transfer of requisitions for internally sourced products from Purchasing. Once the interface managers pick up the records in the interface tables, it validates them to see if orders need to be created, updated or deleted. Depending on the arguments specified, respective processes are triggered. The entities are processed in the following sequence: 1. Process Header Record

2. Process Header Adjustments. 3. Process Header Pricing Attributes 4. Process Header Adjustment Attributes 5. Process Header Adjustment Associations 6. Process Header Sales Credits 7. Check Entity context to make sure all lines belong to one header 8. Process Lines 9. Process Line Adjustments 10. Process Line Pricing Attributes 11. Process Line Adjustment Attributes 12. Process Line Adjustment Associations 13. Process Line Sales Credits 14. Process Line Lot Serial Numbers 15. Perform Cross Entity Logic for Sales Order business object

Order Import in Order Management

Page 20

VALIDATION

When the order is found in the interface tables, the first thing that is done is to insert the request_id into the interface tables. The value of the CLOSED_FLAG is checked. If CLOSED_FLAG = Y, the Order import procedure for closed orders (OE_CNCL_ORDER_IMPORT_PVT.Import_Order) is called. If CLOSED_FLAG = N, the Order Import Procedure for open Orders OE_ORDER_IMPORT_PVT.Import_Order is called. This will first give the validation of the case where CLOSED_FLAG = N. If the OPERATION_CODE is INSERT then it is changed to CREATE for all the interface tables. The Order Import Pre Processor is called. The validation starts. It is done in three steps: 1. Check for Required Attributes. Validate that all the required attributes have been specified on the entity and even if one required attribute is missing, raise an error and quit. For example, Inventory Item is a required field on the order line entity.

2. Check for Conditionally Required Attributes. Validate that all attributes that are required based on the status of the entity have been specified and if at least one is not specified, raise an error and quit. For example, for a booked line, ship to location is required. 3. Cross-Attribute Validation. Validate all those attributes that are dependent on the value of another attribute. At the end of the validation, if at least one attribute is not valid, then raise an error and quit. For example verify that the ship to is valid for the customer.
Header Validation

First the Order source and the Orig_sys_document_ref entered in the Header Interface table is validated for Not NULL values. At this stage, if the value for the sold_to_org is not there, then a new customer is created (call to Create_New_Cust_Info). The value for the BOOKED_FLAG is checked for the header interface table and if that is Y then OE_ACTIONS_IFACE_ALL is populated with Operation_Code of BOOK_ORDER. Then the order source and the operation code are checked. NOTE: The four Operation Codes supported are INSERT, CREATE, UPDATE and DELETE. The Header related Adjustment table is validated for a not null value of orig_sys_discount_ref, based on the combination of the operation code of the header table and the price adjustment table. Either the Order Price Adjustment Id or the count is retrieved. The following table shows the allowed combination of Operation code in Header interface table and Valid Operation Code in the Price Adjustment table/ Price attribute table / Sales Credit table. Table: Valid Operation Code relation Header Interface Table INSERT, CREATE UPDATE Price Adj Table/ Price Attb Table/ Sales Credit Table INSERT, CREATE INSERT, CREATE, UPDATE, DELETE
Order Import in Order Management Page 21

DELETE

DELETE

The Header related Price adjustment attributes are validated (if any) for a not null value of orig_sys_atts_ref. Based on the same combination of the operation code as in the case of Price adjustment table, the count or the order_price_atrib_id is retrieved. Then the Header related sales credit records are validated for not null value of orig_sys_credit_ref. Here also, based on the same Operation code combination, it either gets either the count or the sales_credit_id. After validating the above Header Level Attributes, the Process Order API is called. However, before calling this it is checked if the Validate Only Flag is Y or N. If Y, then the API Service Level passed to the Process Order API is Validate only. Inside Process_Order, first the Header is processed and then a loop over the line table is done for each Header. The following steps are done for the Header and the line respectively: Attribute Security: Check if the operation is allowed based on the Processing Constraints defined. Attribute level validation: Here the attribute level validation for header attributes and the line attributes are done. For example, Deliver_To_Contact, Conversion_Type etc. Default missing attributes: Here the missing attributes are defaulted. For example Org_id, Created_by etc. Validate Entity: The Entity level validation is done, For example , for Order_Type, if the BOOKED_FLAG is passed as Y, then the Book required attributes are also checked. Entity level security is checked again as some attributes may have changed due to defaulting. After this, the Write process to the database is done. Some of the values required for the BOOKING process are listed below, Table : Book Required attributes: ATTRIBUTE NAME SOLD_TO_ORG_ID SALES_REP_ID ORDERED_DATE INVOICE_TO_ORG_ID TAX_EXEMPT_FLAG SHIP_TO_ORG_ID PAYMENT_TERM_ID AGREEMENT CUSTOMER_PO_NUMBER CONVERSION_TYPE_CODE Not for RETURN Lines Not for RETURN Lines Based on the ORDER TYPE Based on the ORDER TYPE If SOB currency is different from order
Order Import in Order Management Page 22

REMARKS

currency CONVERSION_RATE CONVERSION_RATE_DATE PAYMENT_AMOUNT CHECK_NUMBER

Line Validation

IF conversion type is 'User' IF conversion type is 'User' Based on payment type attached to the order (should not be CREDIT CARD type) If payment type is CHECK (Cheque)

The Line validation starts with the processing of all the top-level parents (MODEL, KIT, STANDARD) before any of the child lines. This is because all the child lines refer to the parent lines using top_model_line_index, service_reference_line_index etc. The processing is done in the following order. 1. All the models and standard lines first 2. All the classes 3. All the options 4. All service lines (If any). This is irrespective of the operation on the lines. Once the Line processing starts, the processing constraints on the Line Attributes are checked (if this operation is allowed). For example, DELIVERY_LEAD_TIME,DELIVER_TO_ORG, EARLIEST_ACCEPTABLE _DATE, FREIGHT_TERMS, INVENTORY_ITEM, and DESCRIPTIVE FLEXFIELD ATTRIBUTES. If none of the attributes are constrained for this Operation then the Line attributes are validated. For example, INVOICE_TO_ORG, ITEM_TYPE, SHIP_FROM_ORG_ID, SOLD_TO_ORG, LINE FLEXFIELD ATTRIBUTES. After the attribute validation is done, the attribute defaulting is carried out. It is important for defaulting to work correctly, these fields must: A. Not be dependent on any other field (refer OEXUDEPB.pls for the list of dependencies) B. Not be enabled for security constraints, as there is no security check for these fields. After this the Entity level validation is done, First the required attributes e.g Line_id, Inventory_item_id etc. are validated and then the conditionally required attributes for the line e.g subinventory etc., are validated. If the Booked_flag is set to Y and the Cancelled_flag is not equal to Y then all the Attributes required for Booking the Line (Order) e.g. SOLD_TO_ORG_ID, INVOICE_TO_ORG_ID, ORDERED_QUANTITY etc are also validated. Note: Ship To and Payment Term are required on ORDER lines, NOT on RETURN lines. Warehouse and schedule date are required on RETURN lines. Tax code is required under following conditions, a. The tax handling is required at line level (i.e. Tax_exempt_flag = 'R'-Required.)

Order Import in Order Management

Page 23

b. The calculate tax flag on customer transaction type for this line type is set to Yes. Finally, before writing into the database (Delete, Update or Insert) the Processing Constraint for the Line Entities is also checked. After completing the Database write process the same set of validation (Attribute, entity etc.) for the Line Level Sales Credit and Lot Serial are done. Some of the SQL used for validation (Order /Line) are described below:
ORDER_TYPE

SELECT 'VALID' FROM OE_ORDER_TYPES_V

WHERE ORDER_TYPE_ID = &order_type_id AND SYSDATE BETWEEN NVL( START_DATE_ACTIVE, SYSDATE ) AND NVL( END_DATE_ACTIVE, SYSDATE );
DUPLICATE CUSTOMER PO NUMBER

SELECT 'Y' FROM DUAL WHERE EXISTS (SELECT 'Y' FROM OE_ORDER_HEADERS WHERE HEADER_ID <> &header_id AND SOLD_TO_ORG_ID = &sold_to_org_id AND CUST_PO_NUMBER = &cust_po_number ) OR EXISTS (SELECT 'Y' FROM OE_ORDER_LINES WHERE HEADER_ID <> &header_id AND SOLD_TO_ORG_ID = &sold_to_org_id AND CUST_PO_NUMBER = &cust_po_number );
DEMAND CLASS

SELECT 'VALID' FROM OE_FND_COMMON_LOOKUPS_V

WHERE LOOKUP_CODE = &demand_class_code AND AND AND LOOKUP_TYPE = 'DEMAND_CLASS' APPLICATION_ID = 700 ENABLED_FLAG = 'Y' BETWEEN NVL (START_DATE_ACTIVE,

AND SYSDATE SYSDATE)

AND NVL (END_DATE_ACTIVE, SYSDATE);

Order Import in Order Management

Page 24

PRICE LIST

SELECT 'VALID' FROM qp_list_headers_vl

WHERE list_header_id = &price_list_id and list_type_code in ('PRL', 'AGR') and nvl(active_flag,'Y') ='Y';

SOLD TO ORG or CUSTOMER

SELECT 'VALID' FROM OE_SOLD_TO_ORGS_V

WHERE ORGANIZATION_ID = &sold_to_org_id AND AND STATUS = 'A' SYSDATE BETWEEN NVL(START_DATE_ACTIVE, SYSDATE) AND
INVOICE TO ORG ID

NVL(END_DATE_ACTIVE, SYSDATE);

SELECT 'VALID' FROM OE_INVOICE_TO_ORGS_V INV

WHERE INV.ORGANIZATION_ID = &invoice_to_org_id AND INV.STATUS = 'A'

AND SYSDATE BETWEEN NVL(INV.START_DATE_ACTIVE, SYSDATE) AND NVL(INV.END_DATE_ACTIVE, SYSDATE);

DELIVER TO ORG ID

SELECT 'VALID' FROM OE_DELIVER_TO_ORGS_V DEL

WHERE DEL.ORGANIZATION_ID = &deliver_to_org_id AND DEL.STATUS = 'A'

AND SYSDATE BETWEEN NVL (DEL.START_DATE_ACTIVE, SYSDATE) AND NVL (DEL.END_DATE_ACTIVE, SYSDATE);

SHIP TO CONTACT

SELECT 'VALID' FROM OE_RA_CONTACTS_V CON ROL

, OE_RA_CONTACT_ROLES_V

WHERE CON.CONTACT_ID = &ship_to_contact_id AND CON.STATUS = 'A'

Order Import in Order Management Page 25

AND AND

CON.CONTACT_ID = ROL.CONTACT_ID (+) NVL (ROL.USAGE_CODE,'SHIP_TO')='SHIP_TO';

INVOICE TO CONTACT

SELECT 'VALID' FROM , OE_RA_CONTACTS_V CON ROL

OE_RA_CONTACT_ROLES_V

WHERE CON.CONTACT_ID = &invoice_to_contact_id AND AND AND CON.STATUS = 'A' CON.CONTACT_ID = ROL.CONTACT_ID (+) NVL (ROL.USAGE_CODE,'BILL_TO')='BILL_TO';

SOURCE TYPE (INTERNAL or EXTERNAL)

SELECT 'VALID' FROM OE_LOOKUPS

WHERE LOOKUP_CODE = &source_type_code AND AND LOOKUP_TYPE = 'SOURCE_TYPE' ENABLED_FLAG = 'Y' BETWEEN NVL (START_DATE_ACTIVE,

AND SYSDATE SYSDATE)

AND NVL (END_DATE_ACTIVE, SYSDATE);

PAYMENT TYPE

SELECT 'VALID' FROM OE_LOOKUPS

WHERE LOOKUP_CODE = &payment_type_code AND AND LOOKUP_TYPE = 'PAYMENT TYPE' ENABLED_FLAG = 'Y' BETWEEN NVL (START_DATE_ACTIVE,

AND SYSDATE SYSDATE)

AND NVL (END_DATE_ACTIVE, SYSDATE);

LINE FLOW STATUS

SELECT 'VALID' FROM OE_LOOKUPS

WHERE LOOKUP_CODE = &flow_status_code AND AND LOOKUP_TYPE = 'LINE_FLOW_STATUS' ENABLED_FLAG = 'Y'

AND SYSDATE BETWEEN NVL(START_DATE_ACTIVE, SYSDATE) AND NVL(END_DATE_ACTIVE, SYSDATE);

Order Import in Order Management Page 26

TAX CONTROL FLAG

SELECT 'VALID' FROM OE_AR_LOOKUPS_V

WHERE LOOKUP_CODE = p_tax_exempt_flag AND AND LOOKUP_TYPE = 'TAX_CONTROL_FLAG' ENABLED_FLAG = 'Y'

AND SYSDATE BETWEEN NVL (START_DATE_ACTIVE, SYSDATE) AND NVL (END_DATE_ACTIVE, SYSDATE);
TRANSACTIONAL CURRENCY

SELECT 'VALID' FROM OE_FND_CURRENCIES_V

WHERE CURRENCY_CODE = p_transactional_curr_code AND AND CURRENCY_FLAG = 'Y' ENABLED_FLAG = 'Y'

AND SYSDATE BETWEEN NVL (START_DATE_ACTIVE, SYSDATE) AND NVL (END_DATE_ACTIVE, SYSDATE);

PROCESS FLOW

The process flow of the records while Order Import is done is shown below. It has been divided into three parts; first the pre Process Order API part, second the Process Order API part and third the Post Process Order API part. The process flow of Header and Line processing by the process order API has been dealt with separately at the end.

The following Flow diagram shows the Process flow of the records from the time the Order Import starts till the Process Order API is called. Figure 1a The flow of Pre Process Order API

Order Import in Order Management

Page 27

Order Import in Order Management

Page 28

The following diagrams show the process flow from the point where Process Order API is called to the end of Processing by the Process Order API
Figure 1b The flow of Process Order API

There is a branching done at header and line processing to explain them in detail later.
Order Import in Order Management Page 29

Figure 1c The flow of Process Order API

APAPI
Order Import in Order Management Page 30

After the Process Order API has processed the records the post processor is called which actually does the price comparison etc. The flow is shown below,
Figure 1d The flow of Post Process Order API
CC

POST PROCESS ORDER

PRICE COMPARISON

PAYMENT TERM COMPARISON

RESERVATIONS

CHECK RETURN STATUS

DELETE RECORDS FROM THE INTERFACE TABLES

UPDATE INTERFACE TABLE ERROR FLAG

COMMIT OR ROLLBACK

COMMIT OR ROLLBACK

END OF ORDER IMPORT

Order Import in Oracle Order Management

Page 2

The following flow diagram shows the steps involved in the processing the Header record by the Process Order API

Order Import in Oracle Order Management

Page 3

The following flow diagram shows the steps involved in the processing the Line record by the Process Order API till it crosses the scheduling stage.

AL

CHECK PROCESSING CONSTRAINT

VALIDATE ATTRIBUTES

POPULATE DEFAULT ATTRIBUTE

VALIDATE ENTITY

CANCEL FLAG

Yes

No

CANCEL RECORD

CHECK SCHEDULE STATUS

NEEDS SCHEDULING

SCHEDULE THE LINE

SCHEDULED

AL+

Order Import in Oracle Order Management

Page 4

The steps involved in the processing the Line record by the Process Order API after it has crossed the scheduling stage till the end of is shown in the following flow diagram.

AL+

DELETE

OPERATION CODE

CREATE

UPDATE

DELETE THE EXISTING RECORD

UPDATE THE EXISTING RECORD

INSERT A NEW REOCRD

EVALUATE HOLD SOURCE

EVALUATE HOLD SOURCE

EVALUATE HOLD SOURCE

CREATE WORKFLOW

MODIFY WORKFLOW

MODIFY WORKFLOW

ASSIGN LINE NUMBER

END

Order Import in Oracle Order Management

Page 5

Order Import in Order Management March 2004 Author: Samik Kumar Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright 2004 Oracle Corporation All rights reserved.