Order Import in Oracle Order

Management
An Oracle White Paper
March 2004
 Order Import in Oracle Order Management

EXECUTIVE OVERVIEW 3
INTRODUCTION 3
BASIC FEATURES 3
DATA MODEL 16
ORDER IMPORT PROCESS 19
PROCESS FLOW 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. If ATP is available at request date of requisition: OK/ Order is created;
Scheduling is done
2. 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)
3. 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’.
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 API’s, 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. To Import Closed Orders oe_headers_iface_all table should have the
closed_flag as "Y" and the operation_code as ‘INSERT’
2. There is a difference between closing an existing order and importing
orders in "CLOSED" status the first time itself.
3. As orders were already closed in the old system, there will not be any
changes performed to the records, which means no defaulting.
4. 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

Orig_Sys_Customer_Ref ACCOUNT New Customer account
will get created

Order Import in Order Management Page 6

Orig_Ship_Address_Ref SHIP_TO ADDRESS New Ship to address will
get created
Orig_Bill_Address_Ref BILL_TO ADDRESS New Bill to address will
get created
Orig_Deliver_Address_Ref DELIVER_TO ADDRESS New Deliver to address
will get created
Sold_to_Contact_Ref SOLD_TO CONTACT New Sold to Contact will
get created
Ship_to_Contact_Ref SHIP_TO CONTACT New Ship to Contact will
get created
Bill_to_Contact_Ref BILL_TO CONTACT New Bill to Contact will
get created
Deliver_to_Contact_Ref DELIVER_TO CONTACT 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
table-
IS_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. Order, Returns -> Process Messages -> (Provide Request Id to Query)
ii. 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 System Action
provided Calculated
Price Price
N 100 NULL Accept
Customer Price
Y 100 100 Accept System
price.
(System =
Customer).

Y 100 80 Accept System

price but issue
warning.
(System <
Customer).

Y 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 LOOKUP_TYPE =
'CREDIT_MEMO_REASON'
AND 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 MATCH_AND_RESERVE none

configuration item for
an ATO model

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 multi–org 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 multi–org 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 and
OE_LOTSERIAL_IFACE_ALL tables then for each row in
OE_LINES_IFACE_ALL there can be one or more than one row in these two
tables. In OE_HEADERS_IFACE_ALL, there are two columns, which are
referenced from the same table, LINK_TO_LINE_REF and
TOP_MODEL_LINE_REF.

OE_LOTSERIAL_IFACE_ALL
This is a multi–org 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 multi–org 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 multi–org 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 multi–org 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 multi–org 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 Price Adj Table/ Price Attb Table/ Sales Credit Table
INSERT, CREATE INSERT, CREATE
UPDATE 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 REMARKS
SOLD_TO_ORG_ID
SALES_REP_ID
ORDERED_DATE
INVOICE_TO_ORG_ID
TAX_EXEMPT_FLAG
SHIP_TO_ORG_ID Not for RETURN Lines
PAYMENT_TERM_ID Not for RETURN Lines
AGREEMENT Based on the ORDER TYPE
CUSTOMER_PO_NUMBER Based on the ORDER TYPE
CONVERSION_TYPE_CODE If SOB currency is different from order

Order Import in Order Management Page 22

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

Line Validation

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 LOOKUP_TYPE = 'DEMAND_CLASS'
AND APPLICATION_ID = 700
AND ENABLED_FLAG = 'Y'
AND SYSDATE BETWEEN NVL (START_DATE_ACTIVE,
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 STATUS = 'A'
AND SYSDATE BETWEEN NVL(START_DATE_ACTIVE, SYSDATE)
AND NVL(END_DATE_ACTIVE, SYSDATE);

INVOICE TO ORG ID

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
, OE_RA_CONTACT_ROLES_V ROL
WHERE CON.CONTACT_ID = ‘&ship_to_contact_id’
AND CON.STATUS = 'A'

Order Import in Order Management Page 25

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

INVOICE TO CONTACT

SELECT 'VALID'
FROM OE_RA_CONTACTS_V CON
, OE_RA_CONTACT_ROLES_V ROL
WHERE CON.CONTACT_ID = ‘&invoice_to_contact_id’
AND CON.STATUS = 'A'
AND CON.CONTACT_ID = ROL.CONTACT_ID (+)
AND 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 LOOKUP_TYPE = 'SOURCE_TYPE'
AND ENABLED_FLAG = 'Y'
AND SYSDATE BETWEEN NVL (START_DATE_ACTIVE,
SYSDATE)
AND NVL (END_DATE_ACTIVE, SYSDATE);

PAYMENT TYPE

SELECT 'VALID'
FROM OE_LOOKUPS
WHERE LOOKUP_CODE = ‘&payment_type_code’
AND LOOKUP_TYPE = 'PAYMENT TYPE'
AND ENABLED_FLAG = 'Y'
AND SYSDATE BETWEEN NVL (START_DATE_ACTIVE,
SYSDATE)
AND NVL (END_DATE_ACTIVE, SYSDATE);

LINE FLOW STATUS

SELECT 'VALID'
FROM OE_LOOKUPS
WHERE LOOKUP_CODE = ‘&flow_status_code’
AND LOOKUP_TYPE = 'LINE_FLOW_STATUS'
AND 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 LOOKUP_TYPE = 'TAX_CONTROL_FLAG'
AND 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 CURRENCY_FLAG = 'Y'
AND 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

UPDATE
DELETE RECORDS
INTERFACE
FROM THE
TABLE ERROR
INTERFACE TABLES
FLAG

COMMIT OR COMMIT OR
ROLLBACK 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

CANCEL RECORD
No

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 UPDATE THE INSERT A NEW

EXISTING RECORD EXISTING RECORD REOCRD

EVALUATE HOLD
SOURCE
EVALUATE HOLD EVALUATE HOLD
SOURCE SOURCE

CREATE
WORKFLOW

MODIFY MODIFY
WORKFLOW 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.