2829 Order Import in OM

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

Order Import in Order Management Page 2

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


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


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.


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


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.


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


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’.


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


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 provided Price

System Calculated Price

Action

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


(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


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


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


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


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.

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.



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.


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




Sold_to_Contact_Ref

Ship_to_Contact_Ref

Bill_to_Contact_Ref


This data of this table is linked to the table OE_LINES_IFACE_ALL through any one of the following columns




Ship_to_Contact_Ref

Bill_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.


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


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


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


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.)


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 SYSDATE BETWEEN NVL (START_DATE_ACTIVE, SYSDATE)



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'


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'




PAYMENT TYPE

SELECT 'VALID'

FROM OE_LOOKUPS

WHERE LOOKUP_CODE = ‘&payment_type_code’

AND LOOKUP_TYPE = 'PAYMENT TYPE'




LINE FLOW STATUS

SELECT 'VALID'

FROM OE_LOOKUPS

WHERE LOOKUP_CODE = ‘&flow_status_code’

AND LOOKUP_TYPE = 'LINE_FLOW_STATUS'


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


TAX CONTROL FLAG

SELECT 'VALID'

FROM OE_AR_LOOKUPS_V

WHERE LOOKUP_CODE = p_tax_exempt_flag

AND LOOKUP_TYPE = 'TAX_CONTROL_FLAG'


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 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


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.


Figure 1c The flow of Process Order API

APAPI


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

PRICE COMPARISON

POST PROCESS ORDER

PAYMENT TERM COMPARISON

RESERVATIONS

CHECK RETURN STATUS

DELETE RECORDSFROM THE

INTERFACE TABLES

COMMIT ORROLLBACK

UPDATEINTERFACE

TABLE ERRORFLAG

COMMIT ORROLLBACK

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


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 PROCESSINGCONSTRAINT

VALIDATE ATTRIBUTES

POPULATE DEFAULTATTRIBUTE

VALIDATE ENTITY

CANCEL FLAG

CANCEL RECORD

Yes

No

CHECK SCHEDULESTATUS

SCHEDULED

NEEDSSCHEDULING

SCHEDULE THELINE

AL+


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.

UPDATE THEEXISTING RECORD

DELETE THEEXISTING RECORD

INSERT A NEWREOCRD

OPERATION CODEDELETE CREATE

UPDATE

EVALUATE HOLDSOURCE

CREATEWORKFLOW

EVALUATE HOLDSOURCE

EVALUATE HOLDSOURCE

MODIFYWORKFLOW

MODIFYWORKFLOW

END

ASSIGN LINENUMBER

AL+


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.

Documents

2829 Order Import in OM