“What Do You Mean I Need a Warehouse Management System?

”
Juanita Logan
World Wide Technology, Inc.
Barry Brandt
World Wide Technology, Inc.

Company Overview
World Wide Technology, Inc. (WWT), a certified Sun Microsystems JAVA center and Oracle Service
Provider (OSP), is a rapidly growing company that provides Internet-based solutions and integration
services to customers in the federal government and commercial markets. These services include e-Business
solutions, integration of business applications and value-added distribution. The company and its majority
owned subsidiary, Telcobuy.com, LLC, manages over 400,000 square feet of warehouse space used for
light assembly, product kitting and finished goods distribution. WWT installed Oracle Applications in
March 1998, and upgraded to Release 11 in November 1999, to support the exponential growth in each of
their markets.

Introduction
The purpose of this presentation is to highlight the differences between inventory management and
warehouse management functions and then discuss how to integrate a third party or custom warehouse
management system with the Oracle suite of application modules.

Perhaps you have never thought about the differences between inventory management and warehouse
management functions at your company. Every company has unique and varying degrees of complexity in
the business processes required to manage the flow of their product related material, but on the whole, most
of these processes can be separated into one of these two functional areas.

Both inventory and warehouse management have the same goals of increasing customer satisfaction and
market share while reducing operating costs. Inventory management pursues these goals by managing
accurate, available material levels to satisfy customer demand. Inventory management also provides
visibility to the costs associated with the material used in a company’s operation. But if inventory
management is concerned with what is contained in the warehouse, warehouse management must focus on
how resources and overall capacity can be exploited to their maximum capability.

More specifically, warehouse management must effectively control all warehouse operations including
receiving processes, QA activities, locating material for storage and putting it away, satisfying requests for
replenishment, picking and staging material and then shipping the product to the customer. The two
functional areas are very tightly related; a speedy picking and shipping process is worthless if the product
isn’t available. But when the inventory management process is working properly, the additional benefits of
an efficiently run warehouse can be enormous.

No two warehouses operate in an identical manner. Product mixes, unique logistics requirements, skilled
labor availability and a myriad of other dynamic variables create distinctive warehouse management system
requirements. It would be impossible to compile a complete list of requirements that would represent each
company’s warehouse management needs. The following is an attempt to categorize common warehouse
management functions and provide details for some of the features that might be found in a warehouse
management system, above and beyond traditional inventory management functions. Assuming the
warehouse management system of choice supported the logic for these features, it is important to note that
extensive amounts of additional information would need to be collected and maintained about the materials,
facilities and resources involved in the warehouse management process; system integration efforts are
described later in this document.

Copyright © 2000 by World Wide Technology, Inc.

All Rights Reserved
A warehouse management system should make effective use of the warehouse space.

The warehouse management system may be able to help with put-a-way logic for material through use of
fixed, overflow and/or random location assignments, utilizing flexible rules based on the item’s attributes
and the current state of the warehouse locations. For example, the system could identify the storage medium
of the product, recognize hazardous or high dollar material requirements and could take into consideration
size and weight properties of the part when determining where it should be placed. Further it might utilize
logic in determining replenishment bins that need to be filled, secondary locations when primary racks are
full and available points which are geographically close to the shipping dock. On the simpler side, it might
be sufficient just to see a list of open locations when trying to determine where material should be placed.

Housekeeping features could also be included to optimize fragmented locations, prepare for a new product
line or account for changes to the warehouse layout. Advanced systems would recognize patterns of
historical traffic or forecasted requirements. In fact, one outcome of the system and the data required to
support it might be to aid in the planning of future facility requirements. Overall though, the business
objective of the system is to provide direction and visibility that will effectively increase the volume of
activity and material the current facility is capable of handling.

A warehouse management system should inherently improve the accuracy of transactions that take
place.

The use of barcode and other ID technologies may be incorporated as part numbers, revisions, quantities,
serial numbers, lot/batch numbers, order numbers, customers, suppliers and locations of all types to remove
errors caused during data entry. Time sensitive information could be captured for shelf life information and
FIFO type controls. Specifically, the system could print and utilize barcoded data along with other useful
information during vendor receipt, customer return, storage, packaging, vendor return and customer
shipping operations in the warehouse. The system could also translate supplier and customer unique part
numbers and information to data understood by the internal system. Also, Quality Control requirements
could be included in the receipt process to sample periodic shipments and collect quantifiable results during
testing/inspection processes.

It would be desirable to record each of these transactions via a radio frequency terminal at the location and
time where they took place; it is difficult to scan the barcode on a rack from a network terminal positioned
at the other side of the warehouse. Similarly, physical inventories, replenishment counts and periodic cycle
counts could be executed efficiently and accurately by the warehouse management system using terminals
like these.

This was a very condensed list of features and is probably one of the areas that vary most amongst
companies but the benefits can be enormous. Accurate transactions in warehouses can improve business
areas associated with asset management. Accounts payable and accounts receivable would benefit as well
through improved receiving and shipping information. Lastly, if a company could confidently assume their
inventory information is accurate, they could dedicate time and resources towards improving less
fundamental aspects of the warehouse management function.

The time management and efficient use of other resources within the warehouse need to be managed.

Work can be balanced between resources to insure optimal utilization. Performance of resources can be
measured against company standards to provide productivity reporting and help identify capacity issues.
The system could automatically prioritize activities, placing rush order and cross docking requirements
before normal “put-a-ways”. One example of this would be redirecting received material directly to the
shipping dock based on customer backorders or shortages improving customer satisfaction and saving
wasted stocking and picking transactions.

Wave picking, zone picking, order picking and many other strategies available to reduce the cycle time
required to retrieve material from the warehouse could be incorporated into warehouse system logic.
Special care should also be taken to insure new or temporary resources can be introduced to the warehouse
management system with limited training and “ramp up” time. Overall, resources could be directed by the
system to improve customer satisfaction, decrease order cycle time and allow managers opportunities to
improve the process even further.

There are also a variety of specialized requirements that may have to be handled by the warehouse
management system.

Many companies today use re-usable containers as a method of organizing and protecting material during
transportation and storage. These containers provide additional requirements when they need to be tracked
by quantity, owner, serial identifier and location. It can be even more complex when multi-part or nested
containers are involved. The warehouse management can help by tracking the receipt and storage of each
piece(s), plan for effective packing of the containers when the product is ready to ship and provide
instructions on how material should be packed.

Special documentation can be provided for country and government specific international shipments. The
system could also provide required documentation for transportation of hazardous and dangerous material.
Reports like these can be very time consuming to produce and errors may create costly delays in the
shipping process.

Automated material handling equipment exists in numerous functions and forms. Everything from
automated storage and retrieval systems to computer controlled conveyors and guided vehicles may have
requirements from the warehouse management system for routing, location and transaction information. At
times these automated system can place additional functional requirements on the warehouse management
system as well. Providing full case quantity pick lists on a conveyor and batching orders to represent the
number of stations at a carousel would be examples of this.

The current Oracle Application functionality must be supplemented.

It is important to note that the Oracle Application is not void of warehouse management functions. In fact
Oracle will soon unveil its own warehouse management solution covering many of the features mentioned
above. Until then, many companies have more advanced requirements than the standard application is
capable of providing. It is in these cases that companies plan to integrate custom or third party package
solutions to supplement the existing functionality.

The remainder of this paper will take you through a practical application of an Oracle application and
warehouse management system implementation. As you will see the interface design discussed here rely
heavily on Oracle open interfaces, which for the purpose of this presentation reflect the capabilities of the
Release 11 functionality.

Step One – Identify the key business requirements

Before you begin to develop the interface design, you must first identify your objectives. What are the key
business requirements driving the decision to integrate the Oracle applications to a warehouse management
system? The answer to this question can actually have a direct bearing on the design of the interface.

Oftentimes, the companies want to decrease the order cycle time in order to improve customer service. In
order to do this, released sales orders must be fulfilled many times throughout the day. This means pick
release may need to run every 30 minutes and ship confirmations may need to take place every hour. High
frequency and/or large batches can be very demanding and the chances of making this requirement a reality
will depend heavily on both the robustness of your hardware, network and the ability of the WMS to
operate as close to real time as possible.

Some businesses require fewer picking, packing and shipping errors. As discussed earlier, warehouse
management systems can automate these processes through conveyor belts, carrousels, etc., thus reducing
the chances of human error. Oracle’s role in this scenario is not to automate the pick, pack and ship process
but instead provide the WMS system with accurate information so that it may process the transactions most
efficiently.

Step Two – Identify the technology requirements

It is important to identify the type of database used by the WMS and what type of system it’s run on. This
will determine the best mechanism in which to pass data between Oracle and the WMS. It is a given that the
Oracle application uses the Oracle database and can run off a variety of platforms. If the WMS uses an
Oracle database, then transactions can be most efficiently passed through a database link. In other cases, the
WMS may utilize some unsupported platform or not use any particular type of relational database
management system at all. You would then need to investigate the use of file transfer protocol (FTP) to send
files between Oracle and the WMS.

Understanding the hardware and software the WMS runs on also may also shed light on the ease of
modifying the file layouts and WMS functions in the future.

Step Three – Identify the type of data that needs to be passed between the two systems

The diagram below describes examples of types of transaction data that could flow between Oracle and the
Warehouse Management System.

Items – INT01

Open Purchase Orders – INT02

ORACLE APPLICATION WAREHOUSE
Inventory MANAGMENT
Purchase Order Receipts – INT03
Order Entry SYSTEM
Purchasing (WMS)
Released Sales Orders – INT04

Ship Confirmations – INT05

Expected Returns – INT06

RMA Receipts – INT07

Inventory Adjustments – INT08

The following are examples of the minimum/required data Oracle may pass to the WMS or that WMS may
pass to Oracle for each of these potential interfaces. The table structures are based on R11 table structures
and should provide a good starting point for the type of information shared between the two systems.

INT01 - Item Export to WMS

Some warehouse management systems maintain a separate item master file. Therefore Oracle needs to
export its item master file to send to the WMS, at least daily.
oracle information oracle column
item master item
description
uom
serial number control
INT02 – Open Purchase Order Export to WMS
Open purchase orders are generally passed to the warehouse management system. Oracle would not pass
purchase orders that have been closed or lines that have been cancelled. Once the WMS gets the file with
the open purchase orders it could simply overlay that file on top of its most recent purchase order file.
oracle information oracle columns
purchase order header purchase order number

purchase order lines quantity

uom
item

INT03 – Purchase Order Receipts to Oracle

Purchase order receipts should come from the WMS. All receipts should be entered or scanned into the
WMS and interfaced back into Oracle using the receiving transactions open interfaces. In this instance, the
WMS should pass as much required information as possible to populate RCV_HEADERS_INTERFACE
and RCV_TRANSACTIONS_INTERFACE.
oracle table name oracle column name oracle data type
rcv_headers_interface header_interface_id number
group_id number
processing_status_code varchar2
receipt_source_code varchar2
transaction_type varchar2
last_update_date date
last_updated_by number
creation_date date
created_by number
vendor_name number
validation_flag varchar2
ship_to_organization_id number
employee_id number
auto_transact_code varchar2

rcv_transactions_interface interface_transaction_id number

group_id number
last_update_date date
last_updated_by number
creation_date date
created_by number
transaction_type varchar2
transaction_date date
processing_status_code varchar2
processing_mode_code varchar2
transaction_status_code varchar2
quantity number
unit_of_measure varchar2
item_id varchar2
auto_transact_code varchar2
receipt_source_code varchar2
source_document_code varchar2
document_number number
header_interface_id number
 oracle table name oracle column name oracle data type
validation_flag varchar2
subinventory varchar2

INT04 – Released Sales Orders Export to WMS

Throughout the day, depending on the volume of orders entered daily, the pick release process should be
performed. Those pick released orders should then get passed down to the WMS for fulfillment.
oracle information oracle columns
picking headers pick slip number

sales order header purchase order num

order number
shipping instructions
date ordered
customer name
customer address

picking lines item

quantity
uom

INT05 – Ship Confirmations to Oracle

Depending on how “real time” you want shipping information to be available to the customer will determine
how often this interface runs.
oracle table name oracle column name oracle data type
wsh_deliveries_interface transaction_id number
process_flag number
delivery_id number
organization_id number
ultimate_ship_to_id number
actions_code number
date_shipped date
waybill_num varchar2
created_by number
creation_date date
last_updated_by number
last_update_date date
last_update_login number

wsh_picking_details_interface transaction_id number

process_flag number
picking_line_detail_id number
source_code varchar2
source_header_id number
transaction_mode number
transaction_type_id number
inventory_item_id number
warehouse_id number
shipped_quantity number
transaction_uom varchar2
transaction_date date
created_by number
 oracle table name oracle column name oracle data type
creation_date date
last_updated_by date
last_update_date date
last_update_login number

INT06 – Expected Returns Export to WMS

The WMS needs to be made aware of returns coming back from customers. This allows them the ability to
receive against an Oracle RMA number.
oracle information oracle columns
sales order header rma number
expected receipt date
customer name
customer address

sales order lines item

quantity
uom

INT07 – RMA Receipt to Oracle

This is not an open interface in Oracle release 10.7 or release 11.0.

INT08 – Inventory Adjustments to Oracle

At a minimum, some form of inventory balance reconciliation must be done between both systems since to
provide data integrity for their on-hand quantity levels. Typically the WMS will initiate and execute the
cycle counts and physical inventories. Results should get passed back to Oracle so that both systems can
stay in “synch”.
oracle table name oracle column name oracle data type
mtl_transactions_interface source_code varchar2
source_line_id number
source_header_id number
process_flag number
transaction_mode number
lock_flag number
inventory_item_id number
organization_id number
subinventory_code varchar2
transaction_quantity number
transaction_uom varchar2
transaction_date date
transaction_source_name varchar2
transaction_type_id number
transcation_cost number
distribution_account_id number
last_update_date date
last_updated_by number
creation_date date
created_by number
Step Four – Design the technical architecture

The following methods describe the potential strategies for transferring and formatting information between
Oracle and the WMS. Certainly other options exist, but this should aid in identifying and developing the
specific steps required.

Method 1: Direct imports to Oracle using a database link

This method was designed on the basis that the interface data coming from the warehouse management
system could not be imported directly into the Oracle Open Interface tables. Manipulation of the data needs
to occur during the import. To accomplish this a DB Link and PL/SQL program would need to be used. The
steps are outlined below.
1. Oracle custom table populated by WMS. A custom table, residing within Oracle, with the required
data needed for the Oracle import process would be populated by WMS on a scheduled basis. A
DB Link would be used between the WMS and Oracle databases to allow for communication between
each system’s database.

2. Execution of “PL/SQL” concurrent program. A concurrent program is setup within Oracle Apps to
allow for the execution of the PL/SQL. An executable and a concurrent program definition need to be
setup in Oracle Apps (in that order). The executable is setup to execute a PL/SQL program owned by the
System Administration module. The concurrent program definition is setup to allow Oracle Apps to run
the executable and schedule it. Anyone with the System Administrator responsibility would be able to
run the interface process.

Once all the data from WMS has been populated to the custom tables, PL/SQL is executed to take that
data, manipulate it as needed, and import it to the Oracle Open Interface tables. If no errors are found in
the custom table, the PL/SQL completes with a successful return code, and the user then needs to
proceed to step (3). If there are errors residing in the custom table, the PL/SQL completes with a failure
return code. The data residing in the custom table that is flagged as not processed needs to be fixed and
the execution of the PL/SQL concurrent program needs to be re-submitted.

3. Execution of Oracle Open Interface concurrent program. Once the data is successfully imported to
the Oracle Open Interface tables, the concurrent program for the specific interface you are running needs
to be executed. For more specific information on how these work, refer to the Oracle Open Interface or
User manual. In general, these concurrent programs import the data from the Open Interface tables into
the actual Oracle Apps tables. Specific validation is done on the data during this process and any errors
are reported in either the output or log files.

Method 2: Exports from Oracle using a database link

This method was designed to meet the export requirements Oracle Apps had to fulfill to the warehouse
management system. To accomplish this a DB Link and PL/SQL program would need to be used. The steps
are outlined below.
1. Execution of “PL/SQL” concurrent program. A concurrent program is setup within Oracle Apps to
allow for the execution of the PL/SQL. An executable and a concurrent program definition need to be
setup in Oracle Apps (in that order). The executable is setup to execute a PL/SQL program owned by the
System Administration module. The concurrent program definition is setup to allow Oracle Apps to run
the executable and schedule it. Anyone with the System Administrator responsibility would be able to
run the interface process.

PL/SQL is executed to take the data required by the WMS from the Oracle Apps tables, manipulate it as
needed, and populate the custom tables. If no errors are encountered during the processing, then the
PL/SQL completes with a successful return code. If there are errors encountered, then the PL/SQL
completes with a failure return code. The errors reported should then be investigated and any fixes
needed performed. The execution of the PL/SQL concurrent program then needs to be re-submitted.
 2. WMS execution of “PL/SQL”. Upon successful population of the custom table by Oracle, WMS could
then extract the data as needed for processing in their system. WMS would flag each record in the
custom table as either successfully processed or not in order for proper auditing to occur when errors are
encountered. A DB Link would be used between the WMS and Oracle databases to allow for
communication between each system’s database.

Method 3: Direct imports to Oracle utilizing FTP

This method was designed on the basis that the interface data coming from the warehouse management
system could be imported directly into the Oracle Open Interface tables. No manipulation of the data occurs
during the import. To accomplish this, FTP and SQL*Loader would need to be used. The processing steps
are outlined below. A graphic flow is included in Appendix A.
1. WMS legacy data file placed in the “Inbox” via FTP. During this step, WMS would transfer the flat
file via FTP from the WMS legacy system to the “Inbox” located on the computer hosting the Oracle
Apps system. The file names given to each legacy interface file are unique to allow for distinction
between multiple files in the “Inbox” at the same time; utilizing a time/date stamp as part of the file name
would be a potential technique.

2. Execution of “SQL*Loader” concurrent program. A concurrent program is setup within Oracle Apps
to allow for the execution of the SQL*Loader script. An executable and a concurrent program definition
need to be setup in Oracle Apps (in that order). The executable is setup to execute a SQL*Loader script
owned by the System Administration module. The concurrent program definition is setup to allow Oracle
Apps to run the executable and schedule it. Anyone with the System Administrator responsibility would
be able to run the interface process.

SQL*Loader is used to take the data from the flat file and import it to the Oracle Open Interface tables.
To do this, a control file is setup for each interface that maps the data from the flat file to a column in
Oracle. During this import, the only validation on the data in the flat file is a check to make sure it is of
the same data type as defined in Oracle. Any records that fail this validation are not imported to the
Oracle Open Interface tables and are written to a “bad” file (*.bad). Check the log files for specific
information as to why it returned an error, fix the problem, and re-run the concurrent program again. If all
data imported successfully, the user then needs to proceed to step (3).

3. Execution of Oracle Open Interface concurrent program. Once the data is successfully imported to
the Oracle Open Interface tables, the concurrent program for the specific interface you are running needs
to be executed. For more specific information on how these work, refer to the Oracle Open Interface or
User manual. In general, these concurrent programs import the data from the Open Interface tables into
the actual Oracle Apps tables. Specific validation is done on the data during this process and any errors
are reported in either the Output or Log files.

Method 4: Non-direct imports to Oracle using FTP

This method was designed on the basis that the interface data coming from the WMS legacy system could
not be imported directly into the Oracle Open Interface tables. Manipulation of the data needs to occur
during the import. To accomplish this, FTP, SQL*Loader, and PL/SQL programs will need to be used.
Again, the processing steps are outlined below. A graphic flow is included in Appendix B.
1. WMS legacy data file placed in the “Inbox” via FTP. During this step, WMS would transfer the flat
file via FTP from the WMS legacy system to the “Inbox” located on the computer hosting the Oracle
Apps system. The file names given to each legacy interface file are unique to allow for distinction
between multiple files in the “Inbox” at the same time.

2. Execution of “SQL*Loader” concurrent program. A concurrent program is setup within Oracle Apps
to allow for the execution of the SQL*Loader script. An executable and a concurrent program definition
will need be setup in Oracle Apps (in that order). The executable is setup to execute a SQL*Loader script
owned by the System Administration module. The concurrent program definition is setup to allow Oracle
Apps to run the executable and schedule it. Anyone with the System Administrator responsibility would
be able to run the interface process.
 SQL*Loader is used to take the data from the flat file and import it to the Oracle Open Interface tables.
To do this, a control file is setup for each interface that maps the data from the flat file to a column in
Oracle. During this import, the only validation on the data in the flat file is a check to make sure it is of
the same data type as defined in Oracle. Any records that fail this validation are not imported to the
Oracle Open Interface tables and are written to a “bad” file (*.bad). Check the log files for specific
information as to why it returned an error, fix the problem, and re-run the concurrent program again. If all
data imported successfully, the user then needs to proceed to step (3).

3. Execution of “PL/SQL” concurrent program. Once all the data from the flat file is imported to the
custom tables, PL/SQL is executed to take that data, manipulate it as needed, and import it to the Oracle
Open Interface tables. If no errors are found in the custom table, the PL/SQL completes with a successful
return code, and the user then needs to proceeds to step (4). If there are errors residing in the custom
table, the PL/SQL completes with a failure return code. The data residing in the custom table that is
flagged as not processed needs to be fixed and the execution of the PL/SQL concurrent program needs to
be re-submitted.

4. Execution of Oracle Open Interface concurrent program. Once the data is successfully imported to
the Oracle Open Interface tables, the concurrent program for the specific interface you are running needs
to be executed. For more specific information on how these work, refer to the Oracle Open Interface or
User manual. In general, these concurrent programs import the data from the Open Interface tables into
the actual Oracle Apps tables. Specific validation is done on the data during this process and any errors
are reported in either the Output or Log files.

Method 5: Exports from Oracle using FTP

This method was designed to meet the export requirements Oracle Apps had to fulfill to the WMS legacy
system. To accomplish this, FTP, and PL/SQL will need to be used. Steps outlined below. A graphic flow is
included in Appendix C.
1. Execution of “PL/SQL” concurrent program. Based on the WMS legacy system requirements,
custom PL/SQL procedures are executed and the data gathered is written to a custom table.

2. Execution of “SQL*Plus” concurrent program. A SQL*Plus script is executed, with the spool option
on, that selects the appropriate data from the custom table and writes it to the Oracle Apps output file.

3. Execution of “Unix Host Script” concurrent program to FTP “Output” file. The output file
generated in step (2) above is transferred to the WMS legacy host “Inbox” location using FTP. The FTP
commands will be setup in a Unix host script. Any log files generated by the FTP process are analyzed
for errors.

4. Execution of “Unix Host Script” concurrent program to FTP “Trigger” file. This trigger will kick
off the WMS interface process to accept the Oracle transactions.

Keep in mind that the methods described above are just an example of the way data can be manipulated, exported
out of and imported into Oracle. As you can see though, the technical requirements for a successful transaction can
be non-trivial.

Step Five – Determine the frequency of each interface run

Interface scheduling should be based upon the function that particular transaction performs. For example, if
large volumes of product is received throughout the day you may want that interface to run that many times
per day so that Oracle can release those sales orders that truly have quantity to pick from. You may also
want to take in consideration the nightly back-up schedule. Mapping this out ahead of time may help
prevent bottlenecks and provide insight on the true load you will be placing on your processing hardware.
Below is an example of an interface schedule:

• INT01: Item Export

Once a day – 8:00 p.m.
• INT02: Open Purchase Order Export
Once a day – 6:00 p.m.
• INT03: Purchase Order Receipts
7 times a day - 5:40 a.m., 7:40 a.m., 10:00 a.m., 12:30 p.m., 3:30 p.m., 5:00 p.m. and 11:55 p.m.
• INT04: Released Sales Orders
5 times a day – 9:00 a.m., 10:30 a.m., 1:00 p.m., 4:00 p.m. and 7:00 p.m.
• INT05: Ship Confirmations
Once a day – 10:00 p.m.
• INT06: Expected Returns
5 times a day – 9:00 a.m., 10:30 a.m., 1:00 p.m., 4:00 p.m. and 7:00 p.m.
• INT07: RMA Receipt
7 times a day – same as INT 03

• INT 08: Inventory Adjustments to Oracle

Once a day – 1:00 a.m.

Step Six – Test until you are blue in the face

This cannot be understated. The permutations of data values, transaction types and data transmission failure
scenarios warrant a well laid out plan with a wide variety of test scenarios to execute. Sometimes, half the
battle is in trying to determine if the problem exists in the Oracle application, the WMS or the interface
software in-between.

Other Helpful hints

The following is a list of other helpful ideas to consider when embarking on a WMS integration project:

• Map out a clear and concise escalation plan. What is the process and procedure for fixing those
interfaces that fail? You should document the types of failures; the points of failure; the error
reports; how exceptions are handled and reprocessed for each interface.
• In order to maintain item number integrity you should use the same part number if two separate
item files are needed; otherwise cross-reference tables will be required.
• If integration implementation is aggressive, you may want to start with double entry of certain
information into the WMS and into Oracle and gradually build up to true integration. This can also
help identify transaction scenarios you might otherwise overlook until after “go-live”.
• Remember to consider reporting when designing the interfaces. Data may need to come from more
than just Oracle, therefore a reporting tool will be needed that can pull data together to form one
report. Oracle’s Discover and Business Objects may be two such options.
• Create request sets that can be scheduled to run for each interface program. For example, the
purchase order receipt interface (INT2) request set would contain a) the SQL load program that
brings the data into the interface tables, b) the receiving open interface program that does all the
validation of the data and c) the receiving interface errors report.
• Utilize the new Oracle WMS module or other integrated third party packages like BPA and
eliminate the need for any interface development. BPA communicates directly with the Oracle
tables real time and does not require duplicate information to be maintained. The Oracle
warehouse management system is a component of Oracle’s integrated Supply Chain Execution &
 Logistics solution. Its release 1 promises much of the functionality mentioned in the beginning of
this paper.

Conclusion
Warehouse management functions and processes are distinctly different from those of inventory
management and it is hoped that this presentation has helped clarify the unique features of what a
warehouse management system might contain. If the requirements of your company require integration of a
third party warehouse management system, or if you are in the process of creating your own customizations
to meet these requirements, this paper should additionally provide insight as to how information might be
passed between the two systems. Considering the system’s cost and importance to health of the company, it
can be a daunting task to undertake. The good news is that it’s absolutely achievable and ultimately, new
warehouse management functionality from Oracle is on the way.
Appendix A
Appendix B
Appendix C