Copyright © 2000 by World Wide Technology, Inc.All Rights Reserved

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

Juanita LoganWorld Wide Technology, Inc.Barry BrandtWorld Wide Technology, Inc.

Company Overview

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

Introduction

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

Perhaps you have never thought about the differences between inventory management and warehousemanagement functions at your company. Every company has unique and varying degrees of complexity inthe business processes required to manage the flow of their product related material, but on the whole, mostof 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 andmarket share while reducing operating costs. Inventory management pursues these goals by managingaccurate, available material levels to satisfy customer demand. Inventory management also providesvisibility to the costs associated with the material used in a company’s operation. But if inventorymanagement is concerned with what is contained in the warehouse, warehouse management must focus onhow resources and overall capacity can be exploited to their maximum capability.

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

No two warehouses operate in an identical manner. Product mixes, unique logistics requirements, skilledlabor availability and a myriad of other dynamic variables create distinctive warehouse management systemrequirements. It would be impossible to compile a complete list of requirements that would represent eachcompany’s warehouse management needs. The following is an attempt to categorize common warehousemanagement functions and provide details for some of the features that might be found in a warehousemanagement system, above and beyond traditional inventory management functions. Assuming thewarehouse management system of choice supported the logic for these features, it is important to note thatextensive 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 aredescribed later in this document.

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 offixed, overflow and/or random location assignments, utilizing flexible rules based on the item’s attributesand the current state of the warehouse locations. For example, the system could identify the storage mediumof the product, recognize hazardous or high dollar material requirements and could take into considerationsize and weight properties of the part when determining where it should be placed. Further it might utilizelogic in determining replenishment bins that need to be filled, secondary locations when primary racks arefull and available points which are geographically close to the shipping dock. On the simpler side, it mightbe 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 productline or account for changes to the warehouse layout. Advanced systems would recognize patterns ofhistorical traffic or forecasted requirements. In fact, one outcome of the system and the data required tosupport it might be to aid in the planning of future facility requirements. Overall though, the businessobjective of the system is to provide direction and visibility that will effectively increase the volume ofactivity and material the current facility is capable of handling.

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

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 removeerrors caused during data entry. Time sensitive information could be captured for shelf life information andFIFO type controls. Specifically, the system could print and utilize barcoded data along with other usefulinformation during vendor receipt, customer return, storage, packaging, vendor return and customershipping operations in the warehouse. The system could also translate supplier and customer unique partnumbers and information to data understood by the internal system. Also, Quality Control requirementscould be included in the receipt process to sample periodic shipments and collect quantifiable results duringtesting/inspection processes.

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

This was a very condensed list of features and is probably one of the areas that vary most amongstcompanies but the benefits can be enormous. Accurate transactions in warehouses can improve businessareas associated with asset management. Accounts payable and accounts receivable would benefit as wellthrough improved receiving and shipping information. Lastly, if a company could confidently assume theirinventory information is accurate, they could dedicate time and resources towards improving lessfundamental 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 bemeasured against company standards to provide productivity reporting and help identify capacity issues.The system could automatically prioritize activities, placing rush order and cross docking requirementsbefore normal “put-a-ways”. One example of this would be redirecting received material directly to theshipping dock based on customer backorders or shortages improving customer satisfaction and savingwasted stocking and picking transactions.

Wave picking, zone picking, order picking and many other strategies available to reduce the cycle timerequired 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 warehousemanagement system with limited training and “ramp up” time. Overall, resources could be directed by thesystem to improve customer satisfaction, decrease order cycle time and allow managers opportunities toimprove the process even further.

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

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

Special documentation can be provided for country and government specific international shipments. Thesystem 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 theshipping process.

Automated material handling equipment exists in numerous functions and forms. Everything fromautomated storage and retrieval systems to computer controlled conveyors and guided vehicles may haverequirements from the warehouse management system for routing, location and transaction information. Attimes these automated system can place additional functional requirements on the warehouse managementsystem as well. Providing full case quantity pick lists on a conveyor and batching orders to represent thenumber 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 factOracle will soon unveil its own warehouse management solution covering many of the features mentionedabove. Until then, many companies have more advanced requirements than the standard application iscapable of providing. It is in these cases that companies plan to integrate custom or third party packagesolutions to supplement the existing functionality.

The remainder of this paper will take you through a practical application of an Oracle application andwarehouse management system implementation. As you will see the interface design discussed here relyheavily on Oracle open interfaces, which for the purpose of this presentation reflect the capabilities of theRelease 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 keybusiness requirements driving the decision to integrate the Oracle applications to a warehouse managementsystem? 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. Inorder to do this, released sales orders must be fulfilled many times throughout the day. This means pickrelease may need to run every 30 minutes and ship confirmations may need to take place every hour. Highfrequency and/or large batches can be very demanding and the chances of making this requirement a realitywill depend heavily on both the robustness of your hardware, network and the ability of the WMS tooperate as close to real time as possible.

Some businesses require fewer picking, packing and shipping errors. As discussed earlier, warehousemanagement 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 processbut instead provide the WMS system with accurate information so that it may process the transactions mostefficiently.

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. Thiswill determine the best mechanism in which to pass data between Oracle and the WMS. It is a given that theOracle application uses the Oracle database and can run off a variety of platforms. If the WMS uses anOracle database, then transactions can be most efficiently passed through a database link. In other cases, theWMS may utilize some unsupported platform or not use any particular type of relational databasemanagement system at all. You would then need to investigate the use of file transfer protocol (FTP) to sendfiles between Oracle and the WMS.

Understanding the hardware and software the WMS runs on also may also shed light on the ease ofmodifying 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 theWarehouse Management System.

Items – INT01

Open Purchase Orders – INT02

Purchase Order Receipts – INT03

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 maypass to Oracle for each of these potential interfaces. The table structures are based on R11 table structuresand should provide a good starting point for the type of information shared between the two systems.

INT01 - Item Export to WMSSome warehouse management systems maintain a separate item master file. Therefore Oracle needs toexport its item master file to send to the WMS, at least daily.

oracle information oracle columnitem master item

descriptionuomserial number control

ORACLE APPLICATIONInventory

Order EntryPurchasing

WAREHOUSEMANAGMENT

SYSTEM(WMS)

INT02 – Open Purchase Order Export to WMSOpen purchase orders are generally passed to the warehouse management system. Oracle would not passpurchase orders that have been closed or lines that have been cancelled. Once the WMS gets the file withthe open purchase orders it could simply overlay that file on top of its most recent purchase order file.

oracle information oracle columnspurchase order header purchase order number

purchase order lines quantityuomitem

INT03 – Purchase Order Receipts to OraclePurchase order receipts should come from the WMS. All receipts should be entered or scanned into theWMS and interfaced back into Oracle using the receiving transactions open interfaces. In this instance, theWMS should pass as much required information as possible to populate RCV_HEADERS_INTERFACEand RCV_TRANSACTIONS_INTERFACE.

oracle table name oracle column name oracle data typercv_headers_interface header_interface_id number

group_id numberprocessing_status_code varchar2receipt_source_code varchar2transaction_type varchar2last_update_date datelast_updated_by numbercreation_date datecreated_by numbervendor_name numbervalidation_flag varchar2ship_to_organization_id numberemployee_id numberauto_transact_code varchar2

rcv_transactions_interface interface_transaction_id numbergroup_id numberlast_update_date datelast_updated_by numbercreation_date datecreated_by numbertransaction_type varchar2transaction_date dateprocessing_status_code varchar2processing_mode_code varchar2transaction_status_code varchar2quantity numberunit_of_measure varchar2item_id varchar2auto_transact_code varchar2receipt_source_code varchar2source_document_code varchar2document_number numberheader_interface_id number

oracle table name oracle column name oracle data typevalidation_flag varchar2subinventory varchar2

INT04 – Released Sales Orders Export to WMSThroughout the day, depending on the volume of orders entered daily, the pick release process should beperformed. Those pick released orders should then get passed down to the WMS for fulfillment.

oracle information oracle columnspicking headers pick slip number

sales order header purchase order numorder numbershipping instructionsdate orderedcustomer namecustomer address

picking lines itemquantityuom

INT05 – Ship Confirmations to OracleDepending on how “real time” you want shipping information to be available to the customer will determinehow often this interface runs.

oracle table name oracle column name oracle data typewsh_deliveries_interface transaction_id number

process_flag numberdelivery_id numberorganization_id numberultimate_ship_to_id numberactions_code numberdate_shipped datewaybill_num varchar2created_by numbercreation_date datelast_updated_by numberlast_update_date datelast_update_login number

wsh_picking_details_interface transaction_id numberprocess_flag numberpicking_line_detail_id numbersource_code varchar2source_header_id numbertransaction_mode numbertransaction_type_id numberinventory_item_id numberwarehouse_id numbershipped_quantity numbertransaction_uom varchar2transaction_date datecreated_by number

oracle table name oracle column name oracle data typecreation_date datelast_updated_by datelast_update_date datelast_update_login number

INT06 – Expected Returns Export to WMSThe WMS needs to be made aware of returns coming back from customers. This allows them the ability toreceive against an Oracle RMA number.

oracle information oracle columnssales order header rma number

expected receipt datecustomer namecustomer address

sales order lines itemquantityuom

INT07 – RMA Receipt to OracleThis is not an open interface in Oracle release 10.7 or release 11.0.

INT08 – Inventory Adjustments to OracleAt a minimum, some form of inventory balance reconciliation must be done between both systems since toprovide data integrity for their on-hand quantity levels. Typically the WMS will initiate and execute thecycle counts and physical inventories. Results should get passed back to Oracle so that both systems canstay in “synch”.

oracle table name oracle column name oracle data typemtl_transactions_interface source_code varchar2

source_line_id numbersource_header_id numberprocess_flag numbertransaction_mode numberlock_flag numberinventory_item_id numberorganization_id numbersubinventory_code varchar2transaction_quantity numbertransaction_uom varchar2transaction_date datetransaction_source_name varchar2transaction_type_id numbertranscation_cost numberdistribution_account_id numberlast_update_date datelast_updated_by numbercreation_date datecreated_by number

Step Four – Design the technical architecture

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

Method 1: Direct imports to Oracle using a database linkThis method was designed on the basis that the interface data coming from the warehouse managementsystem could not be imported directly into the Oracle Open Interface tables. Manipulation of the data needsto occur during the import. To accomplish this a DB Link and PL/SQL program would need to be used. Thesteps are outlined below.

1. Oracle custom table populated by WMS. A custom table, residing within Oracle, with the requireddata needed for the Oracle import process would be populated by WMS on a scheduled basis. ADB Link would be used between the WMS and Oracle databases to allow for communication betweeneach system’s database.

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

Once all the data from WMS has been populated to the custom tables, PL/SQL is executed to take thatdata, manipulate it as needed, and import it to the Oracle Open Interface tables. If no errors are found inthe custom table, the PL/SQL completes with a successful return code, and the user then needs toproceed to step (3). If there are errors residing in the custom table, the PL/SQL completes with a failurereturn code. The data residing in the custom table that is flagged as not processed needs to be fixed andthe 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 tothe Oracle Open Interface tables, the concurrent program for the specific interface you are running needsto be executed. For more specific information on how these work, refer to the Oracle Open Interface orUser manual. In general, these concurrent programs import the data from the Open Interface tables intothe actual Oracle Apps tables. Specific validation is done on the data during this process and any errorsare reported in either the output or log files.

Method 2: Exports from Oracle using a database linkThis method was designed to meet the export requirements Oracle Apps had to fulfill to the warehousemanagement system. To accomplish this a DB Link and PL/SQL program would need to be used. The stepsare outlined below.

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

PL/SQL is executed to take the data required by the WMS from the Oracle Apps tables, manipulate it asneeded, and populate the custom tables. If no errors are encountered during the processing, then thePL/SQL completes with a successful return code. If there are errors encountered, then the PL/SQLcompletes with a failure return code. The errors reported should then be investigated and any fixesneeded 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 couldthen extract the data as needed for processing in their system. WMS would flag each record in thecustom table as either successfully processed or not in order for proper auditing to occur when errors areencountered. A DB Link would be used between the WMS and Oracle databases to allow forcommunication between each system’s database.

Method 3: Direct imports to Oracle utilizing FTPThis method was designed on the basis that the interface data coming from the warehouse managementsystem could be imported directly into the Oracle Open Interface tables. No manipulation of the data occursduring the import. To accomplish this, FTP and SQL*Loader would need to be used. The processing stepsare 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 flatfile via FTP from the WMS legacy system to the “Inbox” located on the computer hosting the OracleApps system. The file names given to each legacy interface file are unique to allow for distinctionbetween multiple files in the “Inbox” at the same time; utilizing a time/date stamp as part of the file namewould be a potential technique.

2. Execution of “SQL*Loader” concurrent program. A concurrent program is setup within Oracle Appsto allow for the execution of the SQL*Loader script. An executable and a concurrent program definitionneed to be setup in Oracle Apps (in that order). The executable is setup to execute a SQL*Loader scriptowned by the System Administration module. The concurrent program definition is setup to allow OracleApps to run the executable and schedule it. Anyone with the System Administrator responsibility wouldbe 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 inOracle. During this import, the only validation on the data in the flat file is a check to make sure it is ofthe same data type as defined in Oracle. Any records that fail this validation are not imported to theOracle Open Interface tables and are written to a “bad” file (*.bad). Check the log files for specificinformation as to why it returned an error, fix the problem, and re-run the concurrent program again. If alldata 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 tothe Oracle Open Interface tables, the concurrent program for the specific interface you are running needsto be executed. For more specific information on how these work, refer to the Oracle Open Interface orUser manual. In general, these concurrent programs import the data from the Open Interface tables intothe actual Oracle Apps tables. Specific validation is done on the data during this process and any errorsare reported in either the Output or Log files.

Method 4: Non-direct imports to Oracle using FTPThis method was designed on the basis that the interface data coming from the WMS legacy system couldnot be imported directly into the Oracle Open Interface tables. Manipulation of the data needs to occurduring 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 flatfile via FTP from the WMS legacy system to the “Inbox” located on the computer hosting the OracleApps system. The file names given to each legacy interface file are unique to allow for distinctionbetween multiple files in the “Inbox” at the same time.

2. Execution of “SQL*Loader” concurrent program. A concurrent program is setup within Oracle Appsto allow for the execution of the SQL*Loader script. An executable and a concurrent program definitionwill need be setup in Oracle Apps (in that order). The executable is setup to execute a SQL*Loader scriptowned by the System Administration module. The concurrent program definition is setup to allow OracleApps to run the executable and schedule it. Anyone with the System Administrator responsibility wouldbe 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 inOracle. During this import, the only validation on the data in the flat file is a check to make sure it is ofthe same data type as defined in Oracle. Any records that fail this validation are not imported to theOracle Open Interface tables and are written to a “bad” file (*.bad). Check the log files for specificinformation as to why it returned an error, fix the problem, and re-run the concurrent program again. If alldata 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 thecustom tables, PL/SQL is executed to take that data, manipulate it as needed, and import it to the OracleOpen Interface tables. If no errors are found in the custom table, the PL/SQL completes with a successfulreturn code, and the user then needs to proceeds to step (4). If there are errors residing in the customtable, the PL/SQL completes with a failure return code. The data residing in the custom table that isflagged as not processed needs to be fixed and the execution of the PL/SQL concurrent program needs tobe re-submitted.

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

Method 5: Exports from Oracle using FTPThis method was designed to meet the export requirements Oracle Apps had to fulfill to the WMS legacysystem. To accomplish this, FTP, and PL/SQL will need to be used. Steps outlined below. A graphic flow isincluded 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 optionon, 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 filegenerated in step (2) above is transferred to the WMS legacy host “Inbox” location using FTP. The FTPcommands will be setup in a Unix host script. Any log files generated by the FTP process are analyzedfor errors.

4. Execution of “Unix Host Script” concurrent program to FTP “Trigger” file. This trigger will kickoff 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, exportedout of and imported into Oracle. As you can see though, the technical requirements for a successful transaction canbe 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, iflarge volumes of product is received throughout the day you may want that interface to run that many timesper day so that Oracle can release those sales orders that truly have quantity to pick from. You may alsowant to take in consideration the nightly back-up schedule. Mapping this out ahead of time may helpprevent 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 ExportOnce a day – 8:00 p.m.

• INT02: Open Purchase Order ExportOnce a day – 6:00 p.m.

• INT03: Purchase Order Receipts7 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 Orders5 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 ConfirmationsOnce a day – 10:00 p.m.

• INT06: Expected Returns5 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 Receipt7 times a day – same as INT 03

• INT 08: Inventory Adjustments to OracleOnce 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 failurescenarios warrant a well laid out plan with a wide variety of test scenarios to execute. Sometimes, half thebattle is in trying to determine if the problem exists in the Oracle application, the WMS or the interfacesoftware 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 thoseinterfaces that fail? You should document the types of failures; the points of failure; the errorreports; 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 separateitem files are needed; otherwise cross-reference tables will be required.

• If integration implementation is aggressive, you may want to start with double entry of certaininformation into the WMS and into Oracle and gradually build up to true integration. This can alsohelp 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 morethan just Oracle, therefore a reporting tool will be needed that can pull data together to form onereport. 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, thepurchase order receipt interface (INT2) request set would contain a) the SQL load program thatbrings the data into the interface tables, b) the receiving open interface program that does all thevalidation of the data and c) the receiving interface errors report.

• Utilize the new Oracle WMS module or other integrated third party packages like BPA andeliminate the need for any interface development. BPA communicates directly with the Oracletables real time and does not require duplicate information to be maintained. The Oraclewarehouse 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 ofthis paper.

Conclusion

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

Appendix A

Appendix B

Appendix C