Arch Design

Architectural Design Document
For
WMS – Barcode Scanning & Printing

Application
Concept Version
Copyright © 2008-2009 Syntel Inc.
This document and any files with it are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. If you are not the intended recipient, please destroy all copies of the
document. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this
document or any action taken in reliance on this document is strictly prohibited and may be unlawful.
Architectural design document for Gates WMS –
Barcode Scanning & Printing Application.
Visit us at www.syntelinc.com
Revision & Approval Chart
Reviewed and
Ver. Date Description Author(s) Approved by/Date
(dd-mmm-yyyy)
0 08 – 31 – Initial Draft (Table Of Mrunal
2009 Contents) Daftari
1 09 – 01 – Initial Draft (Started Contents Mrunal
2009 in reference to TOC) Daftari
Confidential Document Page 2 of 83

Table of Contents
1. INTRODUCTION............................................................................................5
1.1. PURPOSE OF REQUIREMENT SPECIFICATIONS...........................................................5

1.2. DEFINITIONS, ABBREVIATIONS, ACRONYMS.............................................................5
1.3. INTENDED AUDIENCE.......................................................................................5
1.4. DOCUMENT OVERVIEW.....................................................................................5
1.5. UNDERSTANDING OF EXISTING SOLUTION...............................................................6
1.6. REFERENCES.................................................................................................8
2. OVERALL DESCRIPTION...........................................................................10
2.1. SOLUTION PERSPECTIVE..................................................................................10

2.2. PRODUCT FEATURES/FUNCTIONS........................................................................11
2.3. USER CHARACTERISTICS.................................................................................13
2.4. OPERATING ENVIRONMENT...............................................................................13
2.4.1. Hardware Requirement.................................................................13
2.4.2. Software Requirement..................................................................17
2.4.3. Other Operating Resources Requirement......................................17
2.5. DESIGN AND IMPLEMENTATION CONSTRAINTS.........................................................18
2.6. ASSUMPTIONS AND DEPENDENCIES.....................................................................18
3. EXTERNAL INTERFACE REQUIREMENTS....................................................19
3.1. USER INTERFACES.........................................................................................19

3.2. HARDWARE INTERFACES..................................................................................20
3.3. SOFTWARE INTERFACES..................................................................................20
3.4. COMMUNICATION INTERFACES...........................................................................28
4. SPECIFIC REQUIREMENTS........................................................................29
4.1. WAREHOUSE MANAGEMENT..............................................................................32

4.2. ORDER MANAGEMENT.....................................................................................33
4.3. RECEIVING..................................................................................................35
4.3.1. Stock.............................................................................................38
4.3.2. Stock Split.....................................................................................38
4.3.3. Back-Order....................................................................................39
4.4. PICKING.....................................................................................................40
4.4.1. Pick Cycle Setup............................................................................43

4.4.2. Pick Sub-Cycle Management..........................................................44

4.4.3. Shop Floor Picking.........................................................................45
4.4.4. Kitting...........................................................................................47
4.4.5. Bagging.........................................................................................47
4.5. SHIPPING...................................................................................................49
4.5.1. Truck Shipments...........................................................................50
4.5.2. Small Shipments...........................................................................51
4.5.3. International Shipments...............................................................52
4.6. WAREHOUSE STOCKING..................................................................................53
4.7. CYCLE COUNTING..........................................................................................55
4.8. PRODUCTIVITY.............................................................................................55
4.9. REPORTING (ON LINE AND HARD COPY)................................................................56
4.10. HISTORY..................................................................................................57
4.11. INTERFACE TO ORACLE APPLICATION HOST SYSTEM...............................................57
4.12. INTERFACE BETWEEN BARCODE GENERATOR, PRINTING APPLICATION AND SCANNERS.........58
4.12.1. Wallace PrintWare 32.................................................................58
4.12.2. P.A.W.S......................................................................................67
4.12.3. TOMCAT Server and Wi-Fi Technology communication...............79
4.13. INTERFACE TO BARCODE SCANNING SYSTEM.........................................................80
4.14. LABELS USED IN WMS AND SCANNERS..............................................................80

4.14.1. Wallace PrintWare 32.................................................................81
4.14.2. KeWill.........................................................................................83
4.14.3. Honda Specific Labels.................................................................86
4.14.4. Other Specific Labels..................................................................88

1. Introduction
1.1. Purpose of Requirement Specifications
The purpose of this document is to serve as overall guide and basis for understating
the Gates current WMS application architecture especially where the Barcode
scanning and Remote Printing logic is involved.
1.2. Definitions, Abbreviations, Acronyms
WMS Warehouse Management System

SDK Software Development Kit
ACP Asynchronous Client Processor.
PrintWare Wallace Printware 32
SA Site Administration
LP Loader Program
WS Work Station
AP Access Points
Warehouse Gates manufacturing plants or sites where WMS is used
1.3. Intended Audience
Those involved in developing and testing the website:

Developers
Gates system experts
Project managers
CIO and higher level managers.
1.4. Document Overview
This document attempts to provide as much detail as possible to guide reader to get
the overview of existing design of the solution, it includes the following sections:
Section 1 (Introduction) provides an overview of the entire architectural

document.

Section 2 (Overall Description) describes the application that is being used; it

includes product perspective, interfaces, application features,
assumptions and dependencies.
Section 3 (Interfaces required) describes the interfaces required to the
system in terms of hardware interfaces, software interfaces,
communication interfaces, printer interfaces, scanner interfaces
etc.
Section 4 (Specific Requirements) describes the specific requirement of the
print tracking service and barcode scanning system.
Section 5 (Non-Functional Requirements) describes the general system
requirements.
1.5. Understanding of Existing Solution
Gates wants to know their existing WMS application’s interaction with the barcode
scanning and remote printing application. These applications have been
implemented at different locations under different environments. To understand and
make them work under same umbrella is crucial now due to maintenance issues
happening frequently.
The primary goal of this document is to understand the overall architecture of the
Barcode scanner and printing application, and find the similarities and differences at
different locations.
A large variety of warehouse management systems is available at Gates which differ

with regard to:
their scope of functions,

their interfaces,
the required hardware,
the required operating system,
the operating concept,
the barcode and printing options.

And too many other features as well as, last but not least, regarding the investment
costs. Often, with decision for a certain WMS, the warehouse owner binds himself for
a long time to the provider and depends on them for the extension of functions ,
interfaces, and the exchange of hardware.
A modular and open warehouse management system which is programmed in a

widely accepted language independent of the hardware and operating systems
improves the compatibility to third-party products and components and ensures the
efficient adjustment to the rapidly changing market conditions. Such a
comprehensive WMS solution was developed at the Gates with the name “WMS”.
This system is a framework based on the principles of a modular WMS. It provides a
number of software modules and regulations for the software-related construction
supporting a WMS. In this document, a general data model is first described which
can be found in many warehouse management systems and sets the basis for WMS.
This discussion is followed by the description of a WMS implementation and finally

the elementary structures of WMS are presented, and its interaction with the
Barcode and Printer application which is named as “Printware”.
The objectives are as follows:
1. Understand WMS
2. Understand Printware
3. Integration with Barcode Scanners
4. Integration with (Remote) Printers
5. Understand the overall integration of all above objectives
1. Understand WMS
Understanding of the existing WMS will actually provide the high level view of overall
WMS application. WMS is the one which actually provides the data or necessary
inputs (from WMS those will be output) for the barcode to be generated and later to
be printed as labels or other information via printers.
2. Understand Printware

“Printware” is the application which is reading the WMS supplied outputs to generate
the Barcodes and later decides what to and where to print from available printers
and printing options.
3. Integration with Barcode Scanners
Barcodes are integral to warehouse and inventory control operations and are often
used with Oracle WMS and MSCA. Oracle software includes 10 default pre-seeded
label types for shipping, inventory movement and item identification processes.
Additional formats are often required for compliance labeling, report printing and
other applications. These labels are typically created with third-party label design
applications that must integrate with the Oracle system.
4. Integration with (Remote) Printers
Once the barcode interface has collected values to generate the barcodes, its values
will be stored in different formats like PDF, XML, etc. These stored files will be sent
to the printers attached to the WMS system machine. This integration will actually
determine to which printer a particular file needs to be sent for printing. Printer job
can work in two modes which can either be Synchronous or asynchronous mode.
5. Understanding the overall integration of all above objectives
The above mentioned all objectives in turn are closely dependent on each other and
are tightly integrated with each other. Understanding the integration and flow of all
these objectives together will give the complete overview of the WMS system i.e.
from the entry of item to printing the label for that particular item.
1.6. References
The following documents will provide more detail on system and software
requirements:
Meetings with Nafeez, Tom

PVCS existing codes

Database Scheme
Screen details per module : - will be updated later
For the integration of WMS with Barcode scanner and printer hardware SDK is
applicable.

2. Overall Description
2.1. Solution Perspective
Gates is using Oracle based WMS application which is standalone application which
has integration with other hardware interfaces like printers and scanners.

2.2. Product Features/Functions
The high level structure of the WMS is as follows:


The scope of the WMS is as follows:
Warehouse Management
Order Management
Receiving
Picking
Shipping
Warehouse Stocking
Cycle Counting
Productivity
Reporting (on line and hard copy)
History
Interface to Oracle Application Host System
Interface to Barcode generator and Printing application
Interface to Barcode scanning system
2.3. User Characteristics
The users can be categorized by four types:
Normal.
Administrator.
Super Administrator.
Warehouse user.
The current user types are similar to the above user groups. The varying roles and
responsibilities also offer different functionality. For details please see the reference
documents.
2.4. Operating Environment
2.4.1. Hardware Requirement
The hardware will be installed at a hosting provider.

UNIX Server:
Hewlett Packard UNIX D350
HP/UX Operating System.
Novell Server:
Compaq Proliant
Netware 4.1 Operating System.
RF Barcode Scanners:
Intermec Janus 2010 (Handheld Unit) and 2020 (Truck Mount Unit).
DOS 6.2 Operation System.
Printers:
Line Printers: Printronix ProLine Series 5. Utilized for internal and
external document printing such as picking lists, packing lists and bill
of ladings.
Thermal Printers: Zebra 140XiII. Utilized for internal label printing
such as location labels, shipping address labels, and package
identification.

Server Machine (Minimal)
Server HPUX Server Server CPU # of Speed WMS Autosys Date

OS Memor
Location Name Version Support Vendor Model Type CPUs MHZ y Database Database Purchased
standard Hewlett-
Atlanta atux002 11.23 24x7 Packard rp3440 PARISC 4 1,000 8 GB 8.1.7.4 9.2.0.7 Aug-06
standard Hewlett-
Boone bnux001 11 24x7 Packard r390 PARISC 2 240 512 MB 8.1.7.4 1999
standard Hewlett-
Crossville crux001 11.23 24x7 Packard rx2660 Itanium 2 1,595 4 GB 9.2.0.7 9.2.0.7 Jun-07
standard Hewlett-
Charleston csux001 11 24x7 Packard r390 PARISC 1 240 512 MB 8.1.7.4 1999
standard Hewlett-
E-Town etux001 11 24x7 Packard r390 PARISC 2 240 2 GB 8.1.7.4 1999
standard Hewlett-
Florence flux002 11.23 24x7 Packard rp3440 PARISC 4 1,000 8 GB 8.1.7.4 9.2.0.7 Aug-06
standard Hewlett-
Galesburg glux002 11.23 24x7 Packard rx2660 Itanium 2 1,595 4 GB 9.2.0.7 9.2.0.7 Aug-07
standard Hewlett-
Glade Spring gsux001 11.23 24x7 Packard rx2660 Itanium 2 1,595 4 GB 9.2.0.? 9.2.0.? Nov-07
standard Hewlett-
Iola ioux002 11.23 24x7 Packard rp3440 PARISC 2 1,000 8 GB 8.1.7.4 9.2.0.7 Feb-06
standard Hewlett-
Jefferson jfux001 11 24x7 Packard r390 PARISC 1 240 2 GB 8.1.7.4 1999
Moncks standard Hewlett-
Corner mcux001 11 24x7 Packard r390 PARISC 2 240 1.75 GB 8.1.7.4 1999
standard Hewlett-
Chambersburg ncux001 11 24x7 Packard r390 PARISC 1 240 512 MB 8.1.7.4 1999
standard Hewlett-
Poplar Bluff poux001 11 24x7 Packard r390 PARISC 1 240 1.5 GB 8.1.7.4 1999
standard Hewlett-
Red Bay reux001 11 24x7 Packard r390 PARISC 1 240 512 MB 8.1.7.4 1999
standard Hewlett-
Siloam Springs ssux001 11 24x7 Packard r390 PARISC 2 240 1.75 GB 8.1.7.4 1999
standard Hewlett-
Versailles vsux001 11 24x7 Packard r390 PARISC 2 240 512 MB 8.1.7.4 1999
standard Hewlett-
Boulder dnux036 11.11 24x7 Packard rp5430 PARISC 2 750 4 GB 9.2.0.8 Jun-03
2.4.2. Software Requirement
Most important software requirement is providing safety and security, aside of

elements such as multi-lingual and scalable.
Tools to be used are ORACLE, SQL Server and IIS7.
Desktop
Developed using Oracle Developer 2000 32-bit toolkit. The forms
utilize a graphical user interface (GUI).
Both forms and report executables reside on the site’s Novell server.
Desktop Client Software: Oracle Developer 2000 run-time.
RF Barcode Scanners
Developed using PowerBasic 3.2 - DOS based tool.
RF Client Software:
PowerBasic executable.
Virtual Loadable Modules for networking capability.
Gates Application Services Network - this software
communicates with the following NLMs.
Netware Loadable Modules
Developed using C and Assembler.
Custom written transaction management software which executes on
the site’s Novell server.
This software further enables the RF devices to behave as a true client
workstation, versus a “dumb terminal”.
Client Machine
Component Specifications
Operating System XP with SP2 / VISTA 32 bit / Windows 2000
Professional
Browser Internet Explorer 6.0, Mozilla Firefox 2.0, Google
Chrome, Safari
Screen Resolution 1024x768 resolutions
2.4.3. Other Operating Resources Requirement
Component Specification
2.5. Design and Implementation Constraints
2.6. Assumptions and Dependencies
Load balancing, shared-server etc are straight forward industry standards not
to be specified separately.
3. External Interface Requirements
3.1. User Interfaces
Please refer to the corresponding WMS and PrintWare screens showing the core
elements of the UI. In the WMS system there are several Hardware and Software
interfaces involved with the User interface. As the whole system is based on the
WMS and its related *.ini files. When user of WMS performs the data entry
operations, these entries will be stored as .txt files on the ACP’s “Lables” folder.
These text files are actually stored as .INI files which has prefix like “GCWxxx.INI”
and there will be an exe called “GCWxxx.exe” which will find these files and will print
them accordingly. These prints are actually labels of Barcodes which are applied to
the shipping packets and later the barcode scanners will read the information them
to categorize accordingly.
Following is the description of how the “PrintWare” performs internal operations to

print a label:
The “PrintWare” application creates a stream of data from various sources and
selects a label template called .lgf or sometimes multiple templates to merger with
the data. The application sends a temporary file to TEMP (as set in the OS
environment) folder on the PC.
A printer server called as pwspool.exe is executed when any “Printware” application
is run. The server polls the contents of the TEMP folder. The server immediately
communicates with any printer named in the configuration file to know its status. If
a temporary print file is found, the server uses Microsoft DDE (Microsoft Dynamic
Data Exchange) to make the connection to the correct printer. Upon completion, the
temporary print file is deleted.
To perform these operations several hardware and software interfaces are used
which are explained below.
3.2. Hardware Interfaces
<Describe the logical and physical characteristics of each interface between the
software product and the hardware components of the system. This may include the
supported device types, the nature of the data and control interactions between the
software and the hardware, and communication protocols to be used. >.
3.3. Software Interfaces
<Describe the connections between this product and other specific software
components (name and version), including databases, operating systems, tools,
libraries, and integrated commercial components. Identify the data items or
messages coming into the system and going out and describe the purpose of each.
Describe the services needed and the nature of communications. Refer to documents
that describe detailed application programming interface protocols. Identify data
that will be shared across software components. If the data sharing mechanism
must be implemented in a specific way (for example, use of a global data area in a
multitasking operating system), specify this as an implementation constraint.>
Following is proposed one over which Gates is using currently…
Barcode output from the Oracle environment is traditionally accomplished through

third-party software. Gates is planning to use “LoftWare” as third-party software.
However, Oracle’s Warehouse Management System (WMS) and Mobile Supply Chain
Applications (MSCA) offer a new approach that can simplify barcode label printing.
Oracle WMS and MSCA produce output in XML data streams, instead of a proprietary
Oracle format. Zebra Technologies has embedded an XML parser in its XML-enabled
printers, so output from Oracle WMS and MSCA is natively understood by the printer
without additional middleware or server hardware. The figure below illustrates the
system architectures and components required for barcode output from Oracle WMS
and MSCA using the middleware and Zebra direct connection approaches.
This describes the middleware and direct-connects barcode printing options for
Oracle WMS and MSCA, explains the system requirements for each, and provides
approach which is best suited to particular environments.
Barcodes are integral to warehouse and inventory control operations and are often
used with Oracle WMS and MSCA. Oracle software includes 10 default pre-seeded
label types for shipping, inventory movement and item identification processes.
Additional formats are often required for compliance labeling, report printing and
other applications. These labels are typically created with third-party label design
applications that must integrate with the Oracle system. Oracle’s WMS and MSCA
applications communicate print jobs natively in an XML data stream. To print
barcodes, the XML print job data must be processed and encoded into a barcode
format that a printer can recognize. Traditionally, third-party software has been
used to design label formats and manage output to the barcode label printer. The
Oracle applications and system administrator handle all the steps in between,
including management of user profiles and privileges, managing print requests, label
format and printer selection, and generation of the XML data stream.
The print job is then communicated to a barcode printer over a TCP/IP network or
other connection using either synchronous or asynchronous communication.
Asynchronous mode:
In asynchronous mode, the Oracle application drops an XML file into a directory. A
third-party application is responsible for monitoring the directory, processing the
XML data, merging the data with the label format, and then routing it to the
appropriate printer.
Synchronous mode:
Synchronous mode is a simpler approach. It uses a PL/SQL application program

interface (API) to integrate the Oracle application and the third-party application (or
printer) in real time. Oracle WMS and MSCA use the PL/SQL API to make a call to
the printer or third-party application, which then processes the incoming XML data
stream for output. Oracle’s synchronous communications architecture results in no
files to transfer eliminates cross-platform labeling issues and stores success or
failure messages within the Oracle application.
The printing process described above is roughly the same regardless of what form of
output is used. Third-party applications and the Zebra direct-connect method differ
by how the Oracle XML stream is processed and how printer communications are
managed. These approaches are described in the following sections.
Middleware:
Middleware, which can take the form of label design software, print server
applications, or document management software, is the most common method for
generating barcode output from Oracle applications. There are many barcode label
design software packages, but few offer true, certified Oracle connectivity. In fact,
Oracle has only certified five label printing partners for its WMS and MSCA
applications. The select list includes Zebra Technologies and several of its ISV
partners, including Adobe, Loftware, Bartender, and NiceLabel.
Middleware performs the XML conversion that enables Oracle data to be expressed
in barcode and text on the label. Middleware can be used for synchronous and
asynchronous printing. In asynchronous mode the middleware, not the Oracle
application, is responsible for monitoring the directory and transferring files to the
appropriate printer for timely output.
One common and popular approach is to use third-party applications in conjunction

with a print server to manage the communications and processing of print jobs. The
Oracle applications route the print request and output destination through
middleware that resides on a dedicated print server. The middleware application
processes the XML data streams, generates the barcode, populates the label fields
and ends the print job to the designated printer over a wired or wireless network
connection. A single, central middleware application can manage all enterprise
barcode printing requirements within a facility, provided there is network access to
remote locations. The middleware/print server approach may also direct all
enterprise barcode printing operations in a distributed environment by using wide-
area network connections, although firewalls can make this difficult to execute.
Separate print servers and software licenses for each facility are often required.
Middleware applications are advantageous because they can support barcode
printers from multiple vendors.
Another option is to write code or use middleware to give the Oracle application the
ability to generate barcode output. This method can be used for label printing or to
add bar coding to forms and reports. Barcode labeling operations require the
development of printer drivers so the Oracle application can communicate with the
specific models of label printers that are used. The customization required for this
approach can be time consuming and expensive. Maintenance and total cost of
ownership expenses may also be high because software development costs could be
incurred every time new label formats, features or printer models are added to the
operation.
Zebra Direct – Connect:
Zebra’s direct-connect solution uses firmware on the Zebra barcode label printer and
synchronous mode communication with Oracle WMS and MSCA to process the Oracle
XML data stream. Here is how it works.
1. API files are installed on Oracle database or WMS/MSCA application.
2. Printer is defined within Oracle WMS/MSCA and standard application printer
configuration is completed to enable bar code printing.
3. XML-enabled ZPL format is stored in printer’s memory.
4. WMS/MSCA sends XML print job to printer via TCP/IP.
5. XML print job data stream is parsed for label format name, label quantity and
variable field data.
6. Printer recalls stored XML-enabled label format and applies variable field data
while encoding the RFID tag.
7. Label is printed upon detection of “end-of-label” within XML data stream with
RFID data, human readable and bar code data.
An event in the Oracle business process triggers a request for a barcode label. The
request may be generated automatically as part of the business rules, or may be
requested by the Oracle user.
Barcode label requests are forwarded to the Oracle application, where rules and
profiles verify that the user is authorized to access the information and produce the
desired label. The profile also directs the label output to a specific Zebra printer
associated with the user.
The Oracle application then makes procedure calls in Java code to access the
information needed to produce the label. The label request and required data are
formatted into a native XML message for synchronous communication. The print job
is transmitted to the Zebra printer via TCP/IP. Wireless, Ethernet and other TCP/IP
supported networking can all be used for communication between the Oracle
application and the printer.
Zebra’s XML-enabled printers understand the native XML data streams that Oracle
WMS and MSCA produce. The incoming XML message includes a header that
specifies the required label format name and label quantity, and the rest of the data
stream specifies the variable field data. Printer firmware processes the incoming XML
Data stream, calls up the label format, and populates it with the variable data from
the XML message.
The printer then outputs the bar code label. All the different label formats required
to support Oracle business processes can be stored directly in printer memory.
Zebra® XML-enabled RFID printers create a direct connection with Oracle’s

applications and the rest of the data stream specifies the variable field data. Printer
firmware processes the incoming XML data stream, calls up the label format, and
populates it with the variable data from the XML message. The printer then outputs
the barcode label. All the different label formats required to support Oracle business
processes can be stored directly in printer memory.
Application Requirements:
The host application, Zebra printer, and label formats must all be enabled to support
direct connection and label printing. The requirements for each component are
outlined below.
The solution is currently available for the Oracle Warehouse Management System
and Mobile Supply Chain Applications version 11i9 or higher. A PL/SQL script to
process the procedure calls is added to the Oracle application. This small script
requires one-time installation and manages the API for synchronous
communications.
On the printer side, direct connection requires XML-enabled printers that operate on
Zebra Programming Language (ZPL®). Printer firmware determines which Zebra
models can process Oracle data streams. Zebra also offers XML printing capability
on its rugged Z Series® printers as well as on its PAX4™ series print engines.
Additionally, Zebra’s QL Plus™ and RW™ series of mobile printers support XML
functionality, enabling users to add mobile printing from their Oracle applications.
The label format itself must also be XML-enabled. Zebra has already XML-enabled 10
label formats that support the 10 default label types in Oracle WMS and MSCA.
These pre-formatted XML formats have been loaded and are resident on XML-
enabled XiIIIPlus printers. (While XML support is native on Zebra’s QL Plus and RW
series of mobile printers, to get the labels formats and other application content on
the mobile printers, users must order the complimentary companion XML Support
Utility CD-ROM.) If additional label formats are needed, users will need to create
them with label design software. One option is to use Zebra’s ZebraDesigner for XML
label design software, a demo version of which is included on the CD that comes
with XML-enabled printers. Designing labels within ZebraDesigner requires no ZPL
programming skills to create XML-enabled label formats.
When to Use Each Approach:
Neither middleware nor the Zebra direct-connect approach is ideal for all user
environments. Each has specific advantages depending on an enterprise’s legacy
printing system and application management preferences. Zebra recognizes that one
approach is not right for all users and will continue to support and promote its
partner solutions when they are a superior alternative to the direct-connect offering.
Most printer manufacturers support ZPL emulation and XML-enabled printing. Check
with your manufacturer for ZPL support if you are in a multi-printer environment or
contact Zebra directly. Middleware converts Oracle XML data streams so they can be
recognized by each different printer control language (PCL) present in the enterprise
printing operation.
Middleware also provides centralized management and control features that many
users find desirable. These features are not unique to the Oracle environment and
may be available in other networking and connectivity tools.
Zebra’s direct connection approach is appealing to organizations that want to

minimize their barcode printing support requirements and simplify their system
architecture. Direct connection eliminates the need for middleware to intervene and
process communication between Oracle WMS or MSCA and the printer, which
removes a potential source of failure from the system. It also eliminates related
support costs and licensing fees. The direct connect approach is also simpler to set
up and maintain because it requires less programming and software integration than
a system including middleware products. Enterprises that use the default label type’s
native to Oracle WMS and MSCA may not even have to design new labels because
Zebra ships XML-enabled versions of these label formats pre-loaded on its printers.
Zebra’s direct-connect solution is the most cost-effective and simplest option for
enterprises that will begin barcode printing from Oracle for the first time, and those
who have an all-Zebra barcode printing environment.
Guidelines for when each approach is advantageous are summarized in the table
below.
Zebra Direct- Third-party

Condition
Connect Application
New application, homogeneous printer environment √
Printers from multiple vendors without XML support √
Printers from multiple vendors w/XML and ZPL
√ √
support
Single application desired for barcode printing on √
labels, documents and reports
Lowest total label printing cost √
Ease of integration, implementation and support √
So considering all above cases we can say that, direct connection represents an
alternative for barcode printing in the Oracle environment, and is the optimal choice
for most Oracle WMS/MSCA implementations. Besides understanding the technical
requirements of each approach, organizations need to analyze their support,
software development, and architecture strategies to understand which approach is
best for them. Zebra offers direct connection as one option in a range of solutions,
and will continue to work with its partners to provide solutions for a variety of
enterprise barcode printing activities.
3.4. Communication Interfaces
<Describe the requirements associated with any communications functions required

by this product, including e-mail, web browser, network server communications
protocols, electronic forms, and so on. Define any pertinent message formatting.
Identify any communication standards that will be used, such as FTP or HTTP.
Specify any communication security or encryption issues, data transfer rates, and
synchronization mechanisms.>
4. Specific Requirements
This section describes the specific requirements of the P.A.W.S. application. All the
modules and sub modules are described in detail.
Gates Rubber Company is a multi-million dollar company currently involved in

manufacture and distribution of automotive and industrial rubber products. Gates
has multiple manufacturing sites as well as multiple distribution centers throughout
North America and the rest of the world.
As part of an effort to modernize the information systems, Gates is evaluating

software systems for the distribution sites. The full suite of Oracle Manufacturing
and Oracle Financial software has been chosen as the foundation for Gates Rubber
Company. This evaluation will facilitate the decision to modify current software or
purchase the desired functionality for use in the distribution sites.
This document presents a preliminary list of business requirements for a warehouse

management software package. The list is divided into major functional area and
includes requirements for all aspects of warehouse management as well as some
requirements for interfacing with external systems. Ability to integrate with other
application software will be a significant aspect of the evaluation. The software
selected will operate within the enterprise software solution.
Even more important than integration will be the degree of efficiency to which the
software would allow the Gates distribution sites to operate. Gates currently uses
software developed in-house that has been tailored to get the maximum efficiency
of the work-force along with the flexibility required to satisfy the needs of the
customers.
The scope of the WMS is as follows:
Warehouse Management
Order Management
Receiving
Stock
Stock Split
Back Order
Picking
Pick Cycle Setup
Pick Sub-Cycle Management
Shop Floor Picking
Kitting
Bagging
Shipping
Truck Shipments
Small Shipments
Warehouse Stocking
Cycle Counting
Productivity
Reporting (on line and hard copy)
History
Interface to Oracle Application Host System
Interface between Barcode generator, Printing application and
Scanners
Wallace PrintWare 32
P.A.W.S.
TOMCAT Server and Wi-Fi Technology communication
Interface to Barcode scanning system
Labels used in WMS and Scanners
Wallace PrintWare 32
KeWill
Honda Specific Labels
Other Specific Labels
All of the above scenarios are mentioned in a flow diagram in the below figure. The
introduction of Barcode Scanners, Labels and Remote printers are introduced at the
status message Y, the diagram starts from that place actually. Before this Y state
there are e  E  y  Y. Overall Status of products from starting to end is as
below:
eEyYpPsSU
e == Enterprise
E == Entered
y == Exporting
Y == Exported
p == Picking
P == Picked
s == Shipping
S == Shipped
U == Uploaded
4.1. Warehouse Management
Provide on-line visibility overview summary including orders, lines,

pounds, pallets, etc. that are pending for all aspects of distribution
activities.
Provide on-line visibility overview of all orders including pending, in
process, ready to ship, summarized by status with drill down (top down)
multi-level detail to associate work unit detail level.
Provide on-line visibility overview summary of all receipts pending,
intransit, held, or stocking summarized by status with drill down (top
down) multi-level expandability to associate work unit detail level.
Provide on-line visibility overview summary of all shipping activity
including orders pending, orders in process, and orders ready to ship
summarized by status, with drill down (top down) multi-level
expandability to associate work unit detail level.
4.2. Order Management
Provide capability for unique rules, criteria, methodology, for different

market and order profiles. This includes mixed mode order processing
with ability to work partial orders in varying methodologies including
special packaging, final product finish, single level BOM, and/or
merchandiser assembly.
Provide capability of systematically controlling combination of orders
based on table driven criteria.
Provide capability of concurrently utilizing combined, wave and individual
order picking methodologies based on user definable table driven rules.
(Product, Customer, Zone)
Provide capability of systematically combining orders at time of shipment,
after being picked separately, insuring orders required to ship with other
orders, and other special handling requirements, are met.
Every order will be processed via WMS and at the end it will have a
barcode label on it to notify the receivers of WMS to receive product. The
manufacturing barcodes are as shown below.
4.3. Receiving
Support single pallet processing at the scanner level.

Allow for a worker from the shop floor to request a candidate empty or
partial secondary stock location to receive stock.
Communicate the available secondary stock locations to the worker and
receive a reply indicating the location selected. Include in the algorithm
the closest secondary location to the primary.
Update inventory, real time, once stock is received.
Maintain and allow for visibility of stock information, such as a listing or
view of stock received and how it was processed.
Allow for Hot Stock identification so that based on intransit information
product receipt can be prioritized and made available to the system
faster.
Provide the ability to attach user defined transaction types to receiving
records in order to communicate receiving activity to the legacy or host
system.
Include visibility of intransit information such as product, quantity,
location, delivery date, and vehicle number.
Allow for visibility to receiving location of special instructions, possibly via
the shipping list or label.
Support the unique requirements that are presented with special vendors
like Dodge such as early intransit information or special instructions (file
transfer from Dodge to Gates).
Support definition of warehouse put away (based on row/column/level).
Provide lot control and serial number control support for specific inventory
items upon receipt into inventory and for each subsequent inventory
transaction.
Allow “Tagging” of special receipts to specific orders as an exception to
normal FIFO or ATP business rules.
Support real time location files/database with location size, fill
percentage, status, and content linkage.
Provide ability to peg incoming items to specific shipping orders
Labels starts with series 36xx or 40xx are used as representation of
storing the same products as Warehouse Stock items.
Labels starting with 9xxx are used for items which are directly ready to be
shipped. Pallets can be considered as one of such type item.
There are 3 types of receiving methods being used at Gates Corporation for
methods on the receiving please find the details below: This section helps user in
understanding picking related stuff. This section mainly contains three sections,
which are as follows.
Coding guidelines can be found in the PVCS at the selected area in the following
image:
4.3.1. Stock
When the item comes out of manufacturing plant they will have the labels
on them. Items produced are in three major categories
Pallet
Package
Individual
The receiver will have pre-printed labels for each of the types mentioned
above. These kinds of labels (i.e. Barcodes) are called as License plates.
These all labels are printed out of the data which is in WMS. WMS
contains all the information including client information for the products.
WMS will pass all these information to Wallace Printware application via
ACP’s.
4.3.2. Stock Split
Stock splitting is when the items moved from the manufacturing location
to one of the distribution centers for resale.
Stock splitting is mainly used to achieve the order sent by the client. If
the quantity which was supposed to be shipped to a particular customer is
short then the stock will be split.
This can happen in the case like if there are multiple orders for a
particular item from different customers and total quantity is less then the
total shipping quantity also.
In such cases the stock splitting is the option. The steps which need to
follow during the stock splitting are mentioned in the above figure.
4.3.3. Back-Order
Back orders are the orders which are returned items or goods from either
DC or the client.
Sometimes due to defect or some mismatch in the produced item are not
matching the client requirements or the ordered dimensions in such cases
clients will return the items back to the manufacturing site.
Sometimes DC-1 will send some order back to DC-2.
Such cases are known as Back-Orders.
DCs have to receive them and have to follow the same processes under
back order as they are doing for normal receiving.
To store or not such items will be determined on the case to case bases at
the sites.
4.4. Picking
This section helps user in understanding picking related stuff. This section mainly
contains three sections, which are as follows.
image:
4.4.1. Pick Cycle Setup
Support the definition of warehouse pick location sequence (descending,

ascending, Z pick).
Allow for definition of warehouse pick areas (based on row/column/ level).
Provide unique user defined characteristics by pick class (e.g., weight,
transportation mode, combining of orders/backorders, weight
limitations, etc.).
Determine cycle frequency, either manual or automated (timed event
driven picking cycle) based on pick classes (e.g. truck every three
hours, rush every 20 minutes).
Support incremental work units (sub-cycles) being passed to the scanner
allowing the scale of work to be defined based on pick class,
weight, etc.
Allow for site independence when defining parameter file.
Provide for sleeving, BOM and other final product assembly at time of pick
including separating this activity into unique sub-cycles.
Provide capability to support multiple primary pick locations in dedicated
pick sequences based on product quantity or packaging status or
requirements.
4.4.2. Pick Sub-Cycle Management
Systematically prioritize sub-cycles based on table driven business rules.

Provide the ability to delete and re-prioritize tasks in the pick queue.
Allow for on-line editing of each line item within the subcycle (add,
change items and quantities up to time of shipment).
Provide visibility, using a variety of filter criteria, to view cycle/subcycle
information for number of lines ready/picked, number of full pallets
ready/moved.
4.4.3. Shop Floor Picking
Allow for the request of work by a picker on the shop floor.

Communicate prioritized work to shop floor picker.
Provide the ability for a sub-cycle to be shared by more than one picker.
Allow for access of replenish functions from within the picking logic.
Ensure line item information is updated at each transaction and capture
information such as quantity picked, backorders canceled, etc.
Allow for adjustment of a line item based on product availability.
Allow for over/under shipment and cancellation of backorder.
Provide update of packaging data for each line item such as serial
number, carton, pallet, country of origin, etc.
Update product location balances once picked.
Ensure product on hand balance is decremented once order is shipped.
Support shop floor control subcycle queue update.
Provide on-line visibility of picking errors on a daily basis.
Provide ability to generate bar-coded pallet/shipping label.
Allow for the override of full pallet selection.
Allow for the generation of bill of lading without printing.
Allow for the declaration of loose packages that are not tied to a pallet.
Allow for the physical definition of a pallet for export orders including
weight, dimensions, etc...
For small orders, allow for the direct deposit of an order to shipping (NRI
manifest system) and release by re-pack label.
Allow for ability to consolidate pallets.
Allow for the ability to modify the transportation mode of an order.
Allow for the ability to identify full pallet picks so that the full pallet picks
can be separated from primary picks.
Allow for the generation and maintenance of a packing list.
Allow for the creation and maintenance of truck shipment bill of lading
that may represent more than one order or a combined/master order.
Allow for the creation and maintenance of export order documentation
(e.g., Shipper’s Export Declaration, export packing list with a
Harmonized Number for each item shipped, Customs documents, etc.).
4.4.4. Kitting
Kitting is a special process which is carried out at Iola. This is one type of
picking process.
When there are several small or individual parts has to be shipped then
Kitting is carried out.
In this process picker will pick the items individually from the locations
and will put them together in a kit which will be like boxes within a big or
medium size plastic container.
This container will be having the boxes within to differentiate the items
kept in it.
Once all items are picked by the picker the box will be packed and kept in
the shipping area to ship.
The option is available in the PAWS but due to lacking of the Remote
Printer’s currently the bills are being made as hand-made individual
plastic zip bags.
Ideally it should be the printed item information by the wireless printers
and should be on the shipping kit (plastic box) of the items.
4.4.5. Bagging
Bagging is a special process which is carried out at Iola. This is one type
of picking process.
In bagging all items are repacked or bagged individually as per the
demand of the client.
There is a separate barcode labels for the bagging.
A special program is generating the barcodes which are printed on the
bag itself. Such bags are the ones in which the items will be re-bagged
(re-packed) as per client needs.
Sometimes it will contain 2 special barcodes (bags). For example there
are 5 items which client asked to re-bagged in 1 big bag.
So in such case there will be 1 big bag which will contain 5 small bags to
be packed and shipped as bagging.
The barcode and the bag which are used in bagging are shown above.
4.5. Shipping
This section helps user to understand information related to shipping and provides
ASN information to be passed to host system once shipping is complete.
image:
Shipping section mainly contains two sections, which are as follows.
4.5.1. Truck Shipments
Provide top down visibility of all orders in process by status showing

weight, lines, packaging summarized by destination, traffic lane (ZIP code
key) with drill down capability to work unit detail.
Provide capability to systematically combine orders for shipment to a
single destination, and require this combination where identified on any of
multiple orders to this point.
Allow for the creation and maintenance of truck shipment bill of lading
that may represent more than one order or a combined/master order.
Provide capability to electronically record the Pro Number before releasing
the order for shipment.
Provide capability to communicate priorities to complete orders in process
to meet shipping schedule or fill trailers shipping in a specific traffic lane.
Provide the ability to assign ship bays for pallets.
Allow for communication of prior pallet bay assignment within a combined
order (multiple orders for an individual customer).
Allow for visibility of ready to ship information by order in shipping.
Allow for a bay assignment defined at the row, column, and level for
export pallets.
Allow shipping to combine orders under one combined bill of lading.
Provide visibility of combined order(s) that represents the combined bill of
lading.
Provide for the assignment of an order to a dock door/trailer to verify
loading accuracy.
Allow the loader to request up to 2 pallets at a time for loading.
Report pallet status (i.e., loaded or not loaded).
Update order status to ready to invoice once all pallets for a combined
order are loaded.
Provide capability to generate special export information (e.g., “mark for”
information on shipping label).
Allow for the generation and maintenance of a packing list.
4.5.2. Small Shipments
Allow for the request and relay of order information to the manifest
system (NRI).
Update order information based on the manifest system action (e.g.,
transportation charges, tracking number, routing, etc.).
4.5.3. International Shipments
Allow for the request and relay of order information to the manifest
system (NRI).
Update order information based on the manifest system action (e.g.,
transportation charges, tracking number, routing, etc.).
4.6. Warehouse Stocking
This section helps user in understanding warehouse stocking related stuff and
provides basic information to be passed to host system once stocking is complete.
Coding guidelines for the same can be found in the PVCS at the selected area in the
following image:
Warehouse stocking supports the following types of stock movement:
Secondary to Primary (Replenishment)
Primary to Secondary
Secondary to Secondary (Warehouse rearrangement, pallet
consolidation)
Picking Cycle Generated Move Stocks.
The following are requirements for all stock movements:
Include an ongoing audit of stock movement including a transaction
type.
Allow for the on-line review, update, delete and scheduling of both
system and manual requests for stock movement.
Allow for the summary review of all stock activity, a listing of stock
moves based on user defined filter criteria.
Allow for the management of the stock movement queue using the
badge or worker identification.
Identifiers required by type of location:
Primary Location
Product Number, Location, and Quantity.
Secondary Location
Product Number, Location, Manufacturing Date and Site,
Pallet Number, and Quantity.
Replenishment of the primary location can be initiated from within the
picking function by order filler or by an ad hoc request when an
operator notices a primary location is low or out of stock. The oldest
available secondary stock should be selected for replenishment.
Primary to Secondary and Secondary to Secondary stock movements are
initiated by a stocker. A stocker may request a target partial or empty
secondary location, closest to the primary location, to move the stock.
Combined pallets with the same secondary location with the same
product number inherit the oldest manufacturing date.
Picking cycle generated move stocks include full pallets, partial pallets,
and no home move stocks. Full pallet move stocks require capturing
additional information since the product is not handled by an order filler
4.7. Cycle Counting
Allow for the ad-hoc cycle counting of a product

Allow scheduled cycle counting based on ABC analysis with criteria such
as product cost, activity, quantity, etc.
Communicate the product number and quantity of products involved in a
cycle count.
Allow product quantity adjustment by a cycle counter.
Provide on-line reporting of cycle count adjustments based on a variety of
filter criteria such as product, location, date of adjustment, badge
number.
4.8. Productivity
Provide for linkage of productivity to site specific personnel systems to

allow for the following:
Link all personnel badge numbers to productivity system.
Link all personnel to teams.
Link all hours worked to productivity system.
Provide for team and work type summaries and reporting.
Allow for the capture and retention of productivity data.
Update and allow visibility of picking productivity for each line item,
specifically quantities picked.
Provide the ability to view and report on productivity measures of an
employee by badge number by major function:
Receiving
Number of full pallets put away
Number of mixed pallets put away
Number of put away into a secondary location
Number of put away into a primary location
Shipping
Number of pallets bayed
Number of pallets loaded
Picking
Number of cartons picked
Number of loose picked
Number of lines picked
Amount of weight picked
Lines/hour ratio
4.9. Reporting (on line and hard copy)
Provide on-line visibility and/or hard copies for the following type
reports:
Picking lists
Packing lists
Bills of Lading
Intransit Reports
Location listings for cycle counting
Site specific management reports
4.10. History
Provide on-line visibility of stock movements within the warehouse.

Provide on-line visibility of all adjustments to inventory balances (e.g.,
shipments, receipts, transfers, etc.).
Retain on-line visibility for a minimum of six months or as specified by
each site
4.11. Interface to Oracle Application Host System
The full suite of Oracle Manufacturing and Financial applications has been chosen
by Gates to be the enterprise information systems solution. It will be necessary for
a warehouse management software package to communicate with the Oracle
applications during the various business processes. The following paragraphs
highlight two scenarios and give a brief description of the exchange of information
that is desired. Any response to this request should indicate the level of
functionality being quoted.
Warehouse mostly run using third party software
This involves the respective warehouse using the third party software for
most aspects of data management and operation. Item master, order
entry, and general ledger functions will be performed by the Oracle
applications. The management of on hand inventory, receiving, picking,
shipping, and cycle counting for the warehouse will be managed by the
third party software.
Accept item master information from Oracle.

Accept in-transit information for incoming shipments from Oracle.
Accept expected purchase order receipts from Oracle.
Accept sales order information from Oracle.
Send all inventory transaction activity to Oracle (receipts, scrap,
shipments, cycle count, etc.) via Oracle transaction interface
tables.
Send all shipping information to Oracle, updating the appropriate
order information.
Send transaction accounting information to Oracle for period close.
Warehouse runs using third party software for picking management and
scanner communications and Oracle for inventory management.
This involves using the Oracle application for item master, order entry,
general ledger, and inventory management. The third party software
would be used to manage the picking and shipping process, as well as
processing receipt, stock movement, and cycle counting transactions
utilizing the barcode scanning equipment for efficiency.
Accept sales order lines ready for shipment.

Accept cycle counting information from Oracle.
Accept in coming shipment (in transit) and receipt (purchase order)
information for receipt processing.
Send all transaction activity to Oracle (receipts, stock movement,
cycle count, etc.) via Oracle transaction interface tables.
Send all shipping information to Oracle and process Oracle Pick
release and Ship Confirm transactions.
4.12. Interface between Barcode generator, Printing application and Scanners
This section helps user understanding the Barcode generation, printing interface
application and Scanner application which are talking with WMS application.
4.12.1. Wallace PrintWare 32
The version of PRINTWARE 32 is fully integrated, 32-bit bar-code labeling

software that runs on Windows 3.1, 95, 98 NT 4.0 and XP.
This version includes an all-new interface to give users greater control
designing and printing labels with greater adaptability for accessing data.
Label design can also be enhanced with the expanded library of industry
specific clipart images that are provided.
It provides support to printers like dot-matrix, ribbon, laser and wireless
network or Wi-Fi enabled printers.
Every label (except shipping labels) is printed out of PrintWare application
in Gates Corporation WMS.
WMS sends the command to print the labels to PrintWare via ACP’s.
ACPs are used for following tasks:
Identifying the print requester
Managing print priorities
Queuing the labels accordingly
Identifying the label format
Storing the print queues and printing them from the point or queue
no from when the connections to printers were lost.
ACPs are servers used to get command to print labels from WMS or
directly from PrintWare. ACPs are for the above mentioned purposes.
When user of WMS performs the data entry operations, these entries will
be stored as .txt files on the ACP server under the “Labels” folder.
These text files are actually stored as .INI files which has prefix like
“GCWxxx.INI”.
An exe called “GCWxxx.exe” which will find these files from the “Labels”
directory and will print them. These prints are the actual labels or
Barcodes, which are applied to the shipping packets and later used by the
barcode scanners to categorize them accordingly.
PrintWare application creates a stream of data from various sources and
selects a label template called as “*.ldf” (sometimes multiple templates)
to merge with the data. The application sends a temporary file to the
TEMP (as set in the OS environment) folder on the PC.
A print server (pwspool.exe) is executed when PrintWare application is
run. The server pulls the contents of the TEMP folder.
The server immediately communicates with any printer named in the
configuration file to know its status. If a temporary print file is found, the
server uses Microsoft DDE to make the connection to the correct printer.
Upon completion, all the temporary files created will be deleted.
The code of PrintWare is written in C++ language. The Gates Packaging
Department is managing the application and code, and is responsible for
resolving any issues.
Based on customer specific requirements the Packaging Department has
created different label templates and GUI to access all available
templates.
User has to select the template and related labels in terms of the
barcodes will be printed accordingly, which PrintWare takes care of.
Following is code snippet with proper comments to understand the basics
of the PrintWare application.
WMS system will keep following type of *.TXT or *.INI file on the ACPs.
Once the file is placed on ACPs “Labels” directory the “pwspool.exe” will
be called automatically and will execute the following command or code
written in C++ to send the print command to the printers specified or else
it will be printed via the queue and priorities.
Output of the above code depends on the information supplied from the
*.TXT or *.INI file as shown in below figure it may be of different types
and the corresponding outputs are shown with them
image:
PrintWare is capable of printing several types of labels. The labels are
categorized as follows:
Receiving  License Plate Labels
Picking / Packaging  Content Labels
Export labels  Marked Labels
Shipping Labels  Address Labels
International Labels
It also takes care of handling the remote printers which are installed at
certain sites. It will give command via ACP’s to the remote printer to print
the barcode labels, especially when the kitting is carried out.
For the PAWS and Interface of Scanner, Access Points, TOMCAT servers and WMS
with ORACLE database is represented in the following diagram as just an overview.
(P.S. Details are described in the following sections individually…)
4.12.2. P.A.W.S.
Gates uses Symbol 9060 and 9090 scanners windows mobile based devices for the
scanning purpose. Every barcode which is printing out of PrintWare systems are
being used at different stages of WMS at Gates. Gates barcode tags contain
information like product number, name, quantity, item id, pallet id, location
information, etc. This pocket pc comes with built-in scanner gun, which provides
high level of barcode readability for most types of barcodes. The current types of
barcodes being used are CODE 39, Code 128 and PDF 417. For small package
shipping purposes Gates use another type of barcode generation system which is
KeWill. To perform scanning to such types of barcodes Gates is using special
scanning gun which is known as Symbol 9060 and Symbol 9090. It provides
interface to read the 2D barcodes which are typically printed out of KeWill and are
used worldwide for FedEx and UPS shipping.
This document will cover majorly the PrintWare barcode output and its scanning
application details. To read the barcodes Gates has developed special application
called as P.A.W.S.
P.A.W.S.: It is made in .Net C# as front end, it stores nothing as database. The
scanners on which this P.A.W.S. system is installed will always communicate to the
Access Points which are located at everywhere in the warehouses. P.A.W.S is
involved in various functionalities which is previously covered this document. PAWS
is involved in almost all the tasks of the WMS portion like Receiving, Picking and
Shipping. In shipping there is different type of scanner involved but still it is
running on the PAWS. PAWS is providing a remote version of the WMS on the
scanners to provide quick interface for the warehouse workers. It acts like
communication interface to pass on information between WMS and Oracle DBs with
the enhanced capabilities of reading Barcode values.
Access Points: APs are physically located in warehouses and they are being used
in transmitting and receiving the data to and from between Scanners and WMS
application using TOMCAT server and Wi-Fi interface for communication. APs are
made up of the Wi-Fi receiver and TOMCAT server interface. It is connected to the
scanners via Wi-Fi. It is connected to the WMS via fiber optics connection with the
WMS systems.
TOMCAT server and Wi-Fi interface: This communication interface will be
covered in the next topic of this document in detail.
ACPs: ACPs are servers which are responsible for executing the print command
from WMS application or Scanners. ACPs will queue up the incoming print requests,
prioritize the requests, and then sends to available free printer on the network.
4.12.2.1. Scanner Device Understanding
At Gates we are using Symbol scanners with version 9060 and 9090. Both
are Windows mobile or pocket PCs operated on Windows Mobile 5.x+
series operating systems. More detailed specifications about the scanner
devices can be found at the following link.
Symbol_MC9090_Specification_Information
Gates is primarily using 9060 at most of the sites, but does have some
9090 in a few locations. The 9090 series is the updated version of the
9060 series.
Apart from scanners the battery is the main component of the scanners.
Gates is using some external batteries to quickly replace if the battery of
particular device runs short of battery life. Gates is using following type of
charger to charge more batteries together.
Scanners are capable of storing the last state of the operation they were
performing if they are running out the battery life so replacing the
discharged one with the charged one will not stop the operation. (PAWS is
also involved in maintaining this data temporarily until the soft boot is
done.)
4.12.2.2. Scanner Installation – Configurations
When there is need of a new scanner at particular sites, Site

Administrators (SA) have to purchase the new scanners or request spare
units from other sites. All scanners are capable of working at any site with
the following configuration steps.
When the scanner is brought to the warehouse premise the SA has to
configure it to allow to be operated in the warehouse network
environment.
In order to configure the site settings the SA will connect the new scanner
to the Work station via Microsoft ActiveSync software. Once the Scanner
is in sync with the WS, SA can copy the Loader Program in the specified
directory of the scanner.
Work Stations: WS are normal desktops which have WMS installed
where a WMS user can login into the WMS to perform the tasks.
Loader Program: LP is the special written command which is copied
in .CAB files on the scanners via Active Sync. .CAB files are the
installation files for the Mobile Devices. Once the .CAB files are loaded the
program written inside them will run and will start making changes in the
registry and some other stuff.
Once LP is installed at particular location the SA will do cold-boot on the
scanners. This will automatically calls the LP during the next boot up. At
that time LP will run its internal logic to run the application. As first step
LP will remove all the Games and shortcuts from the scanner. Then it will
install all necessary files required by scanner to run PAWS.
This installation will take care of the installation of TOMCAT server
communication between PAWS and APs.
Once this is done SA will open the TOMCAT server site to assign the next
available IP address for the scanner to register it on the network.
This IP address will be hardcoded on the scanners and it will be used as
the reference for the scanners communication and identity purpose.
Once this is done the SA has to register the scanner to the MAC network,
where the SA will perform the MAC filtering. This process will register the
scanner in the secure environment.
After completing this, the scanner is ready to be operated in the specific
site environment.
The SA has to copy the configuration file in scanner which contains all the
site specific address and other WMS site information.
The IP address, LP and configuration is key for the scanner to be operated
in each of the WMS sites.
4.12.2.3. Scanner application work method (PAWS)
The application which we have installed is known as PAWS.

PAWS will be in 2 main categories, the Update modular and the PAWS
(Remote WMS) application.
PAWS Update Modular: This modular update is responsible for the
collecting the latest updates from the site and will update the PAWS
application folder. When user presses the PAWS Update this will make
connection to the AP’s via TOMCAT server using Wi-Fi communication
interface. Once the connection is made it will go through the file
comparison with version check. The version check is based on the
comparison of the files which are loaded on the Scanners and the data on
the servers. The custom program written in the PAWS updater completes
this comparison and automatically updates the scanners to ensure they
are on the same version.
Scanner Configuration (Site Specific): Every scanner can be made
site specific at the time of installation. The following image shows the
.XML configuration file. In this file you can made site specific changes and
some other information about scanner like its IP address, ID, application
version, etc.
Because of this .XML file scanners are configurable and the PAWS
code maintenance is really easy.
This is one time process to configure the file but this should be
done for every scanner individually and at every site.
SA has to perform this step while installing new scanner at the
site.
The configuration parameters are also available in the WMS
application so that it can be aligned with site specific WMS site too.
PAWS Application: This application is the primary application which can

be thought of as mobile version of WMS. The primary functionalities this
application can offer is as following with its description :
Receiving: Its same like as explained in above sections.
Picking: It is same like as explained in above sections.
Stocking: It is same like as explained in above sections.
Shipping: It is same like as explained in above sections.
Cycle Count: It is same like as explained in above sections. But
here at some sites warehouse workers are doing it manually. The
cycle counting is the part of the inventory verifying against the
actual stock and the system maintained stock. When the process is
completed manually and a user does not update the final stock
against the total stock creating out of balance inventory. PAWS
provide this feature to do it instantly so that the stock remains the
same in system and physically at the location.
Mfg Product: It is some additional functionality provided by the
PAWS in scanners.
Utility: It is some additional functionality provided by the PAWS in
scanners.
4.12.2.4. Scanner Interface with the APs and WMS
Scanners used by Gates are updated real time for the WMS application.
They serve the purpose of allowing true mobile features. Scanners
achieve with the assistance of the Wi-Fi technology, TOMCAT servers and
the Access Points.
This interface is totally dependent on the Wireless Frequency (Wi-Fi)
technology. As mentioned previously, all the scanners are assigned the
specific IP address and are configured via MAC filtering.
MAC filtering happens in the TOMCAT servers. All IP addresses are being
generated automatically via TOMCAT servers and it is assigned as next
available address to the new scanners.
The AP’s are just transmitters and receivers which receive data from the
scanners and transmit the same back to the WMS application.
AP’s are connected to scanners via Wi-Fi. The WMS application is
connected to AP’s via fiber optics. The basic interface is provided by
TOMCAT servers.
There are multiple scanners which will transmit the data at the same
time. The AP’s are able to recognize the individual requests via the IP
address from which they are passing the request. AP’s will interpret the
incoming request and will transfer the data to the WMS application which
will be connected via Fiber Optics to the APs.
Once the data is received by the WMS application it will be saved to the
Oracle database and will have immediate effect to the WMS application
and PAWS.
The Oracle database and TOMCAT servers are residing on the same server
so the data transmission is faster and it provides real time updates to the
PAWS and WMS applications.
4.12.2.5. Normal Problems and solutions with PAWS and WMS
WMS and PAWS application serves almost all the requirements of the
Gates in the best possible manner. During the visits to the IOLA and
SILOAM SPRINGS we found some problems which will be discussed in this
section.
Gates is going to change the WMS system to an undecided provider in the
future. Feedback from WMS sites is the current application is having
everything required by Gates.
Gates users are almost satisfied with the system still there are few
problems which will be with every systems when it will be used for longer
duration. The possible reasons can be so many, here will discuss the
problems first and then the solutions.
Normal Problems with PAWS and WMS
The scanners which are used are very old now so their battery life
is not good.
Many times the battery loses its charge while workers are in
between some operation in PAWS.
The scanners and PAWS have ability to store the same information
while it is being soft boot, but again they are not starting from the
point where they have been during their last transaction.
Configuring the steps for installing new or exchanged scanners is
really difficult due to no proper steps in place which explains the
setup or troubleshooting.
Users of WMS are not utilizing the WMS system and handling
many of the tasks manually although system provides all
functionalities.
The demand flow application and the WMS application should be
aligned or should be sync with each other so that the process of
receiving can be more efficient.
Here the piece of code is missing which is required to be developed
or if it is already there then we need to put the same at proper
implementation.
PAWS code should be updated to include the functionality of the
rack or location size and weight capacity so that it helps receiver
or picker to determine the empty location to store stock.
Such missing integrations are increasing the manual tasks at
warehouse and in the end the production costs as a whole.
No consistency is followed at all sites or no knowledge sharing is
happening which clearly affects the process and routine work of
Gates very slow.
Required and most valuable suggestions are not being
implemented which forces warehouse worker to do manual work.
Example: the rack information is missing it just allows entering
locations but not their sizes and capacity.
Suggested solutions with PAWS and WMS
First and most important is to educate the users of WMS.

During the visits it was observed that the WMS provides the
functionality required to complete the identified business processes
and flows.
The site administrators or the workers pain points should be noted
at a centralized location and be discussed by the WMS team to
determine a resolution.
The missing links which can improve the business flow and
decrease the labor, time and money should be achieved
immediately.
Missing code or patches for integration of the manufacturing plant
and receiving should be targeted first.
WMS and PAWS applications review should happen immediately to
have the quickest solution.
WMS provides task scheduling, priority assignment, task updates,
location information, resource planning, dash board explaining
current progress within warehouse, etc. which is not being utilized
at all the places which should happen.
Knowledge sharing between the sites should happen, which can
help to improve the quality of the application and also will make
the processes standardized to assist WMS teams and management
at Denver to achieve any maintenance or new changes made in
WMS or PAWS.
Proper manuals or installation steps are covered in this document.
The WMS experts and need to prepare some easy to use reference
manuals which can help any new person to complete tasks with
the same speed and efficiency.
Every warehouse should have the flow charts on the premises
explaining how to do the day to day activity with the help of WMS
and PAWS.
Need to refer the ACCESS application which is used at almost all
sites but in different technologies it should be supported by the
Denver as a centralized out of the WMS and PAWS application as it
is really required application.
Prior to implementation of replacement WMS system, document
and reference information from WMS site users and administrators
to ensure all requirements are included.
The technology in which the WMS and PAWS has been very recent
one so the changes and maintenance will be very easy and also
resources can easily available in market.
The code written for PAWS is very well structured and organized.
Gates can meet any required changes easily to customize the
same.
4.12.3. TOMCAT Server and Wi-Fi Technology communication
The following diagram shows the overall diagram with all the technologies in
placed. It displays all the technologies in Blue arrows and the light blue boxes are
the application or interfaces.
4.13. Interface to Barcode scanning system
This section helps user understanding the Barcode and scanning interface with
WMS application.
4.14. Labels used in WMS and Scanners
This section helps user understanding the labels which are Barcodes basically. The
following are all different types of barcodes and their brief understanding with brief
introduction which Gates is using for their WMS system. There are two systems to
printout the barcodes out of WMS. Both systems with their functions and types of
Barcode Labels they are printing are described in the following section. There is
some specific customer for which different types of barcode labels needs to be
printed which is also covered in the following section.
4.14.1. Wallace PrintWare 32

PrintWare is actually capable of printing several types of labels.
According to frequency of use we can differentiate them into following
categories:
Receiving Labels:
Such labels are known as License plates by the WMS
sites. These labels are being used by the Receivers. When
the stock is moved from manufacturing plant, this type of
label is used scan the products to Primary or Secondary
locations in warehouse.
Normally they will keep the printed labels with them which
are mainly type of Palette, Package and Loose label types.
The labels are not used sequentially and are randomly
assigned to the products as it is transferred from the
manufacturing area to the warehouse or loading area for
stock splitting.
If the item is in shape of direct shipping thy will use the
labels that begin with 9xxx series.
After attaching the label and assigning the inventory as
received they will go to empty locations and stock items
accordingly.
Storing Labels
Storing labels are same as License plates. They are
primarily used for the products that are to be stored in
Warehouses.
Labels starts with 36xx series are used to store pallets in
“Siloam Springs” warehouse and starts with 8xxx are used
at “Iola” warehouse and almost at all other warehouses.
Labels starts with 7xxx series are used to store items
which are type of loose products.
Content Labels
Content labels are used while preparing the shipment. They
are used when there are different types of items which
need to be shipped for the same customer in loose or
repack shipment type.
They contain the full information of the loose or repacked
container.
Marked Labels
Address Labels
4.14.2. KeWill
KeWill is for printing shipping labels. KeWill is the actual program which
Gates is using for printing different shipping labels of international
standards which are accepted worldwide.
To print the labels from KeWill different type of scanner gun is used as
pictured below. It reads information from the Barcodes printed out of the
PrintWare and passes information to the KeWill to print the special
international standardize barcodes for small package shipments.
According to frequency of use we can differentiate them into following

categories:
Shipping Labels For FedEx Ground Shipping

For products which are required to be shipped via
FedEx Gates is using this type of labels which are
printed by KeWill and are used as shipping labels.
These type of shipping labels are special type of label
ware know as FedEx Ground “96” Code 128
barcodes.
The latest one which Gates is using for the same
purpose is known as PDF-417 2D symbol barcode.
These barcodes allow customers or receivers to track
the shipping information also and which is with the
help of one more symbol which is known as UCC/EAN
Code 128 “SSCC-18” barcode symbol.
For more information on FedEx shipping labels please
folw the below link.
FedEx_Ground_Label_Layout_Specification
Shipping Labels For UPS Shipping

For products which are required to be shipped via UPS
we are using KeWill and following is the barcode type
Gates uses for UPS shipping products.
4.14.3. Honda Specific Labels
Honda has specific need for their shipping labels requirements and for
the same Gates is using Honda specific stand alone application. This
application is used after all the steps are completed by Gates WMS
process. This application was purchased from Honda to meet their special
shipping barcode requirements.
This software is used only at specific sites. They are using special setup
with stand alone work station, printer and barcode scanners purchased
and installed from Honda.
4.14.4. Other Specific Labels
Other Specific Labels are used as and when there is some special
shipping requirements by specific customers like John deer, General
Motors, etc.

Arch Design

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Arch Design

Încărcat de

Drepturi de autor:

Formate disponibile

Architectural Design Document

WMS – Barcode Scanning & Printing

Revision & Approval Chart

Confidential Document Page 2 of 83

1.1. PURPOSE OF REQUIREMENT SPECIFICATIONS...........................................................5

2.1. SOLUTION PERSPECTIVE..................................................................................10

3. EXTERNAL INTERFACE REQUIREMENTS....................................................19

3.1. USER INTERFACES.........................................................................................19

4.1. WAREHOUSE MANAGEMENT..............................................................................32

Confidential Document Page 3 of 83

4.4.2. Pick Sub-Cycle Management..........................................................44

4.14. LABELS USED IN WMS AND SCANNERS..............................................................80

Confidential Document Page 4 of 83

1.1. Purpose of Requirement Specifications

1.2. Definitions, Abbreviations, Acronyms

WMS Warehouse Management System

1.3. Intended Audience

Those involved in developing and testing the website:

1.4. Document Overview

Section 1 (Introduction) provides an overview of the entire architectural

Confidential Document Page 5 of 83

Section 2 (Overall Description) describes the application that is being used; it

1.5. Understanding of Existing Solution

A large variety of warehouse management systems is available at Gates which differ

their scope of functions,

Confidential Document Page 6 of 83

A modular and open warehouse management system which is programmed in a

This discussion is followed by the description of a WMS implementation and finally

The objectives are as follows:

Confidential Document Page 7 of 83

3. Integration with Barcode Scanners

4. Integration with (Remote) Printers

5. Understanding the overall integration of all above objectives

Meetings with Nafeez, Tom

Confidential Document Page 8 of 83

PVCS existing codes

Confidential Document Page 9 of 83

2.1. Solution Perspective

Confidential Document Page 10 of 83

2.2. Product Features/Functions

The high level structure of the WMS is as follows:

Confidential Document Page 11 of 83

Confidential Document Page 12 of 83

The scope of the WMS is as follows:

2.3. User Characteristics

The users can be categorized by four types:

2.4. Operating Environment

2.4.1. Hardware Requirement

The hardware will be installed at a hosting provider.

Confidential Document Page 13 of 83

Confidential Document Page 14 of 83

Server HPUX Server Server CPU # of Speed WMS Autosys Date

Most important software requirement is providing safety and security, aside of

2.4.3. Other Operating Resources Requirement

2.6. Assumptions and Dependencies

3.1. User Interfaces

Following is the description of how the “PrintWare” performs internal operations to

3.2. Hardware Interfaces

3.3. Software Interfaces

Following is proposed one over which Gates is using currently…

Barcode output from the Oracle environment is traditionally accomplished through

Synchronous mode is a simpler approach. It uses a PL/SQL application program

One common and popular approach is to use third-party applications in conjunction