RDynamicsDynamics RFID Integration

by

Jarrod Cook, Dan Russo, and Ken VirostekThe Silver Snakes

A Senior Project Report Submitted to the Faculty of Electrical, Computer, and Software Engineering

Penn State Erie, The Behrend College

Faculty Supervisor: Dr. Xiaocong FanSecondary Faculty Supervisors: Dr. Wen-Li Wang and Dr. Kathy Muhonen

Industrial Supervisors: Mr. Kurt Bleil and Mr. Nick KonzelIndustry Sponsor: Distributed Network Software, LLC.

April 2008

Table of ContentsABSTRACT: 4SECTION 1: PROBLEM STATEMENT....................................................................................5

1.1 – Need Statement...................................................................................................................51.2 – Objective Statement............................................................................................................51.3 – Background and Related Work...........................................................................................6

SECTION 2: THE REQUIREMENTS SPECIFICATION.......................................................92.1 – Marketing Requirements....................................................................................................9

2.1.1 – Objective Tree...........................................................................................................102.1.2 Engineering Requirements............................................................................................10

2.2 – Constraints........................................................................................................................122.3 – Standards...........................................................................................................................12

SECTION 3: DESIGN.................................................................................................................143.1 – Design Decisions..............................................................................................................143.2 – Level-0 Design..................................................................................................................163.3 – Level-1 Design..................................................................................................................183.4 – Level-2 Design..................................................................................................................193.5 – Class Diagrams.................................................................................................................21

3.5.1 – RManage Class Diagram...........................................................................................223.5.2 – RSubmit Class Diagram............................................................................................233.5.3 – RDetect Class Diagram..............................................................................................24

3.6 – Conceptual Data Model....................................................................................................263.7 – Use Case and Sequence Diagrams....................................................................................27

3.7.1 – RManage - Add-in Receiving....................................................................................273.7.2 – RManage - Add-in Shipping......................................................................................293.7.3 – RSubmit – ASP..........................................................................................................31

3.8 – Other Used Class Diagrams..............................................................................................323.9 – Design Alternatives..........................................................................................................36

SECTION 4: DESIGN VERIFICATION.............................................................................384.1 – Test Results.......................................................................................................................38

4.1.1 – Submitting and Storing an ASN................................................................................384.1.2 – Retrieving RFID Data................................................................................................414.1.3 – Completed RDetect Testing.......................................................................................444.1.4 – Integrating Into GP....................................................................................................49

4.2 – Requirements Verification................................................................................................704.3 – Standards...........................................................................................................................71

SECTION 5: SUMMARY AND CONCLUSIONS...................................................................72SECTION 6: REFERENCES.....................................................................................................73APPENDIX A: PROJECT MANAGEMENT PLAN...............................................................74

A.1 – Work Breakdown.............................................................................................................74A.2 – Member Contributions.....................................................................................................76A.3 - Acknowledgements..........................................................................................................76

2

3

Abstract:

The Dynamics RFID Integration project, sponsored by DNS (Distributed Network Software), provides increased functionality to an ERP (Enterprise Resource Planning) system to create an advanced method to track inventory. The foundations of the project are Microsoft Dynamics Great Plains 10 and Alien RFID Readers. Using the Visual Studio Tools for Dynamics GP SDK and the Alien .NET API in conjunction with Visual Studio .NET, a middleware system was created that allows integration between these two crucial elements.

Due to the nature of integrated components, the project utilizes many different programming languages. C#, HTML, JavaScript, and Transact SQL ensure that vital communication between modules is attained. C# is the main programming language of the project, used for the Visual Studio .NET add-ins of Dynamics. The web application developed to accommodate acceptance of ASNs is enhanced with HTML and JavaScript. RDynamics also has a database backend created to store ASN information via stored procedures programmed in Transact SQL.

4

Section 1: Problem Statement

1.1 – Need StatementThe inventory of a business is frequently tracked by counting items and entering data into

a computer system. Maintaining an accurate inventory requires routine counting of inventory in stock and processing of incoming and outgoing shipments. Problems can arise with inventory if items are overlooked when being counted or if inventory is stored or labeled incorrectly, which can translate into an incorrect shipment. Several companies use barcodes to keep track of inventory but this method is not perfect. Manually scanning every item is necessary and skipping items is common. The use of Radio Frequency Identification (RFID) tags to count inventory decreases human interaction in item accounting. Wal-Mart, Target, and the Department of Defense are all companies that have adopted RFID tracking systems and require their suppliers to use RFID tags. Wal-Mart has found that it reduces out-of-stocks by 30% in items that sell between 0.1 and 15 units a day [1].

According to the 2002 US census there were a total of 1,550,158 wholesale and retail businesses [2]. A poorly managed inventory can create adverse effects for any business. For example, perishable products will be wasted if overstocked. Businesses have an ongoing need for a better inventory system. RFID tracking is arguably the best inventory tracking system available to date. One survey suggests that by the end of 2005, 40% of inventory-based businesses had hoped to implement an RFID tracking system [3]. RFID will allow much of the inventory process to be automated. Inventory automation will result in a more cost efficient process. Data can then be implemented into the company’s ERP (Enterprise Resource Planning) system, which can then generate reports dealing with ordering and accounting information. ERP systems integrate a company’s data and processes into one system [4]. This allows sales and inventory to be integrated so that your inventory will be even more accurate. Currently inventory data is entered into these systems manually; an RFID system will automatically update these numbers when shipments occur. An RFID system for tracking inventories would benefit any major business by effectively managing inventory data.

1.2 – Objective StatementThe goal of this project is to develop a system that can accept data from an RFID reader

and integrate it into a company’s ERP system. It will be assumed that antennas will be correctly set-up at each shipping bay to read the tags correctly. RFID data will be collected by RFID readers located at the shipping bay of the company. The reader type should be kept as generic as possible although alien readers will be used throughout the scope of this project. The readers will be capable of reading RFID tags located on cases or pallets of shipped items. We will

5

develop an application to read and accept tag data and aid in maintaining accurate inventory levels. The data should then increment or decrement the current inventory counts in the company’s databases. The application will be developed to work with Microsoft Dynamics Great Plains ERP (Enterprise Resource Planning) system. Finally, data should be integrated into the ERP as seamlessly as possible.

1.3 – Background and Related WorkThis project will entail many preexisting technologies and the concept behind the idea is

to get them to work together in a productive manner. As stated prior, many businesses either have RFID systems in place or are working towards integrating this technology. An AMR (Advanced Marketing Resources) research report found that benefits of using RFID tags for inventory management include; a 20% savings on labor, a 25% reduction in inventory levels, and an 80% reduction in theft and fraud [7]. This means that there are already many of these systems functioning and in place. The RFID lab here at Penn State Behrend currently tests RFID systems using SAP, which is the ERP software system produced by SAP AG(Systeme, Anwendungen und Produkte in der Datenverarbeitung or "Systems, Applications and Products in Data Processing")[5]. Currently The RFID readers are set up at the shipping and receiving bays and when a shipment passes through the tags are read. The product/pallet ID is then sent out over a network where it can be accepted by the server running the ERP system. The ERP system is software that keeps track of information on all aspects of the business.

The reason for this current move towards RFID is because current methods have been proven less efficient and more costly. The original method of inventory management was and in some cases still is manual counting and entry. This implies that every item is counted by one or more persons and recorded, then entered into the businesses accounting system. This is by far the most costly method as it is labor intensive as well as time consuming and inaccurate. From here businesses moved more toward bar code scanning. In a barcode system instead of counting and recording everything, you just scan it in with a reader and it is entered into the system automatically. This still requires someone to go around and manually scan every product, which is still labor intensive and leaves quite a bit of room for error. RFID is the current emerging technology, promising spending upwards of 1.9 billion in 2008 and growing to 4.2 billion in 2009 [7]. RFID allows any product to be tagged with a tag that transmits a unique ID that can be read from up to several meters away. This means that as products are brought through the shipping bay they can automatically be read in and entered into the system with little or no human interaction. This implies that it is possible to virtually eliminate errors in inventory systems, which is shown in the AMR study result in the above paragraph. With such a large outlook it is necessary now to develop applications to aid in seamlessly integrating with common business accounting software, so that when the demand peaks the market is ready.

6

Many solutions to this problem already exist in the market, of these solutions; however, many are very costly and cumbersome. One of the main alternative solutions would be Microsoft’s BizTalk, which has incorporated RFID. BizTalk is not a cheap solution; starting January 1, 2008 the price of the enterprise edition will be $34,999[8]. Companies have many different types of systems so a smaller more specific solution would be very beneficial. There also exists many different types of ERP systems but studies show that if the ERP is not user friendly then the employees refuse to use it and revert to previous techniques. To guard against this, the project will be seamlessly integrated into an already familiar Microsoft Application Environment.

In this project our goal is to take these existing technologies and develop a new system to work with Microsoft’s Dynamics GP (Great Plains) ERP software. In the project it will be assumed we already have properly functioning RFID reader’s set-up and ready for communication, as these systems already exist and are not the focus of this project. The goal is therefore to develop an application that will integrate the data received from the readers into GP as seamlessly as possible, keeping the type of reader and software needed as generic as possible. By keeping everything very generic, once complete the system will be capable of being used on a wide array of platforms. The application should detect RFID readers and allow Dynamics to use these readers to aid in automating various transactions. The final system will definitely have marketing potential as it will help to reduce inventory errors, among other issues, that account for losses in business as you can see from tables 1, and 2 below. Once complete it will be possible to setup an ERP system with RFID inventory management at any business, and allow them to start using a more automated inventory management process.

7

Table 1: Tangible Benefits [6]

Table 2: Intangible Benefits [6]

8

Section 2: The Requirements Specification

2.1 – Marketing RequirementsThe marketing requirements below specify the needs that should be met according to the

project specifications. These requirements were developed according to anticipated customer needs as well as required program functionality.

- The system should be:

1. Capable of accurately modify inventories2. User Friendly3. Portable4. Fast5. Interactive6. Small in size7. Compatible8. Easily maintained9. Operational on different systems and environments10. Secure11. Well documented12. Consistent in receiving and logging data13. Capable of formatting data correctly for Great Plains14. Easily integrated into the ERP system 15. Capable of providing user support16. Organized structurally

9

2.1.1 – Objective Tree

The Objective Tree below shows the ranking of project requirements in order of their importance. Each requirement has been weighted based on a percentage determined using the pair-wise comparison matrices shown in Appendix A.

Figure 1: Objective Tree

2.1.2 Engineering Requirements

10

RFID Inventory Tracking

Accuracy0.51

User Friendly0.13

Compatibility0.26

Maintainability0.10

Data Format0.14

Documentation0.125

Consistent0.29 Fast

0.50

Support0.125

Integration0.60

Security0.20

Portable0.20

Correctness0.57

Size0.18

Operational Environment

0.55

Organized Structure

0.27Interactive

.25

The table below presents the project engineering requirements, which address the technical needs of the design. The engineering requirements describe exactly what standards the final product should meet according to the project needs and the marketing requirements determined above.Marketing Requirement(s) Engineering Requirements Justification

1,3 The system must be able to understand tag data from Alien RFID readers.

Alien readers are the only RFID readers necessary within the scope of the project.

1 System must handle and detect reader status changes.

Since the project depends on properly functioning Alien readers, the system must acknowledge reader availability.

2 The system must auto receive/send Advanced Shipment Notifications and Goods Received.

ASNs and Goods Received are necessary for seamless integration.

3, 4 The system must run in a Microsoft Windows XP, Server 2003 environment.

Integration is taking place with Microsoft Dynamics Great Plains.

3 The integration must preserve the Business Logic of Microsoft Dynamics Great Plains.

The project can be considered an add-on to Dynamics GP, not a stand alone ERP system.

1, 2 The system must notify the user of any read errors.

Inaccurate readings should be handled to ensure accurate inventory tracking.

1, 2 The system should aid in automating specific transactions for Dynamics.

The final product should be easily useable from the Dynamics application.

Marketing Requirements:

1. The system should accurately modify inventories

2. The system should be user friendly/easy to use

3. The system should be compatible with existing technologies

4. The system should be easily maintainable

11

Table 3: Engineering Requirements

2.2 – ConstraintsEconomic Constraints – The cost of this project should be minimal is it is simply a middleware between two already expensive products.

Sustainability Constraints – The system should be as generic as possible so that when future technologies are developed it can be easily adapted.

Manufacturability Constraints – The project should consist of only code so manufacturing should simply involve putting the code onto media.

Ethical Constraints – The project should not infringe upon any existing technology copyrights.

Social Constraints – The application should be easy to use and learn so that it can be readily implemented into existing companies and so that time and money are not wasted on training efforts.

2.3 – Standards

The only standards that apply to this project have been defined by both EPCglobal and the Electronic Data Interchange (EDI) standards. The application should work with Gen2 SGTIN tags, the most current industry tag defined by EPCglobal, although the tag type is not crucial in this application. The application will function appropriately with any standardized 96-bit tag. Also ASNs used will follow the EDI 856 standard that defines the prefixes, layout, and delimiters. An example of such an ASN is shown in Figure 2.

12

Figure 2: Sample ASN [9]

13

Section 3: Design

3.1 – Design DecisionsBased on our needs and requirements several options of design methods were available to

us. The design options that we considered are described in detail in section 2.12 on design alternatives. After careful consideration we decided that the waterfall development method would best fit this project along with an event driven architecture. This is based on the fact that we will be receiving a standardized stream of data that must be analyzed and handled accordingly. It will also be necessary to create an additional database in order to house the ASN data, since Dynamics has no built in RFID functionality.

The project itself (RDynamics) contains three logical components as shown in Figure 3. Due to the nature of the system it was developed as three independent programs that communicate with each other through the use of the SQL database. RSubmit, the ASP (Active Server Pages) portion of the project, is initially required to retrieve the actual ASN from the supplier. The Supplier can navigate to this page from any web browser. They will then upload their .txt or .xml ASN through the page. This portion then uploads the ASN parses it and stores it into the database. RDetect, the stand alone portion, is responsible for managing readers and database information on the server. This portion will run at all times and monitor reader status. When a reader comes online or goes offline the database will be notified of the change. The final portion RManage is the actual add-in to Dynamics itself. It is present as a menu item in the Receiving and Shipping forms of Dynamics. When the user clicks on one of the buttons the corresponding process is started. Inventory is automatically modified through Dynamics as necessary.

14

Figure 3: Three parts of RDynamics

The interaction that each component of the RDynamics system has with one another is displayed in Figure 4, as are the six main steps in the system logic. While no component interacts directly with the other two, the SQL database RDataStore acts as a mediator for all data transferred.

15

Figure 4: Project Flow

3.2 – Level-0 DesignThe level-0 design in Figure 5 effectively shows the inputs and outputs of the software

developed. Tag data is received over the network from the RFID readers and the output is a modification of inventory levels in the ERP system.

16

Figure 5: Level-0 Diagram

Module RDynamicsInputs RFID Tag Data – Provided over network port from readers

ASN Data – Provided by outside business partnersOutputs Modification of ERP Tables – Numerical modification to the

numbers in inventory tables through the GP interfaceError Messages – User notifications of problems during operation

Functionality The Dynamics Interface will effectively accept tag data from the reader(s) over the network and depending on the reader and/or user selected options the software will decide what action should be taken on the amount of that item in inventory (addition/subtraction) and by how much. The change will be performed upon the ERP tables via the Great Plains interface. Any errors incurred along the way will be reported only when necessary to the user via pop-ups.

Table 3: RDynamics Level-0 Module Description

17

3.3 – Level-1 DesignThe Level-1 design shown in Figure 6 is a breakdown of RDynamics in the Level-0

design. The ASN data that is received from outside business partners are parsed by the RSubmit ASP module and stored in the SQL RFID database. The status of the readers is captured by the RDetect component and stored in the same database. The RManage module receives the list of available readers from the database and in turn accepts tag data. The RManage module then retrieves the appropriate ASN from the database and compares it with tags to get item information. The item data is passed to Microsoft Dynamics GP for addition or subtraction of inventory.

Figure 6: Level-1 Diagram

18

Module RSubmit - ASPInputs ASN – .txt or .xml file from outside business partnerOutputs Parsed ASN data – product and RFID data (ASN)Functionality This process decomposes the ASN file received from the

business partner and populates fields of the ASN class, which is ultimately stored in the SQL RFID database.

Table 4: Level-1 RSubmit Module Description

Module RDetect - RFIDInputs RFID Reader Events – communicates reader status changes

User Input – instantiates a reader directlyOutputs Reader Information – Information about the reader status

(clsReader)Functionality This process handles reader events and user input and stores

the reader information in the SQL RFID database.Table 5: Level-1 RDetect Module Description

Module RManage – Add-inInputs RFID Reader Information – Information regarding the reader (clsReader)

ASN Data – ASN field information (ASN)Outputs Posted Transactions in Dynamics GP – Inventory that has been modified

Messages to User – Notification of errorsFunctionality This process interacts with the Dynamics SQL RFID database by retrieving

RFID reader information and ASN data. These inputs determine the inventory to be modified. Order completion is also verified in this process. Information is then posted to the ERP system, so that inventory is modified properly.

Table 6: Level-1 RManage Module Description

3.4 – Level-2 DesignThe Level-2 Design is the breakdown of the Dynamics Add-ins RFID block, which is the

complex function on the program that involves getting the data to the ERP. Figure 7 illustrates the process in which user input specifies whether we are shipping or receiving so that the appropriate thing may be handled and the ERP may be updated accordingly.

19

Figure 7: Level 2 Diagram

20

Module Receiving or Returns Transaction EntryInputs User Data – Selecting the appropriate reader

Product List – Tag list retrieved from the reader(strings)Expected Product List – Database with list of expected products(ASN Data)

Outputs Inventory Data – Data to be added to inventory(order info and item info)

Functionality This function takes in the read tags along with the expected tags. If the user input it received tells it that we are receiving it then checks the received items with its ASN database to discover the product ID it then adds them to the inventory and if the order is complete is verifies the ASN.

Table 7: Level-2 Receive Products Module Description

Module Sales Transaction EntryInputs User Data – Select the reader, ASN number and Associations

Product List – Tag list retrieved from the reader(s)(strings)Outputs Inventory Data – Data to be subtracted from inventory(int)Functionality This function takes the tags the have been read in and if the

user states that we are shipping constructs the ASN. It maps the Tags read with the user supplied data to generate the ASN.

Table 8: Level-2 Ship Products Module Description

3.5 – Class DiagramsThe symbols presented in each class diagrams are defined in the legend below. These

classes were designed to perform the required tasks, but other classes contained in both the Dynamics and Alien API’s were also necessary. These have been reverse engineered and shown as well.

Class Legend:

- Private Property

- Protected Property - Public Property

- Private Method

21

- Protected Method

- Public Method

3.5.1 – RManage Class Diagram

The class diagram in Figure 8 is a further breakdown of the RManage or add-in portion of the project. The main parts of this portion are the receiving and shipping portions of the program. They are responsible for managing the corresponding process. The GPAddIn portion is what actually communicates with Dynamics and the other classes are mainly used for data storage.

22

Figure 8: RManage Class Diagram

3.5.2 – RSubmit Class Diagram

This class diagram illustrates the RSubmit module. This portion is responsible for receiving data submitted by a vendor on an ASP page and filing it into the database accordingly. The class diagram for this portion is shown in Figure 9.

23

Figure 9: RSubmit Class Diagram

3.5.3 – RDetect Class Diagram

The class diagram in Figure 10 shows RDetect, the stand alone portion of the project. This portion is responsible for monitoring the network and adding and removing

24

readers to the SQL profile. It also updates the status of readers and allows users to both adjust setting and manually add readers to the system.

Figure 10: RDetect Class Diagram

25

3.6 – Conceptual Data ModelThe conceptual data model in Figure 11 describes the semantics of our project and maps

the concepts to the relationships. This describes what will be stored in the SQL database that is created.

Figure 11: Conceptual Data Model

26

3.7 – Use Case and Sequence DiagramsThe use case diagrams show the process of a system in terms of business events, who

initiated the events, and how the system responds to those events. The boxed area is the area internal to our system. The use cases in the following figures allow the user to see what events will cause the system to react. The corresponding sequence diagrams relate our use case diagrams to our program to show the order in which signals will occur.

3.7.1 – RManage - Add-in Receiving

Figure 12: Receive Use Case Diagram

27

Figure 13: Receive Sequence Diagram

28

3.7.2 – RManage - Add-in Shipping

Figure 14: Shipping Use Case Diagram

29

Figure 15: Shipping Sequence Diagram30

3.7.3 – RSubmit – ASP

Figure 16: RSubmit Use Case Diagram

31

Figure 17: RSubmit Sequence Diagram

3.8 – Other Used Class Diagrams

Since this project is based on integrating two existing technologies use of classes internal to them is necessary. Classes from both the Alien and Dynamics programs are used and in order to derive the class diagrams reverse engineering via Visual Studios was used. The class

32

diagrams stem from the provided libraries for both Alien technology and Dynamics GP. The class diagrams are shown in Figures 18-20.

Figure 18: Class Diagram AlienRFID

33

Figure 19: Class Diagram AlienRFID Expanded

34

Figure 20: Class Diagram Dynamics

35

3.9 – Design AlternativesAlthough the team decided to use an event driven architecture, several other software

architectures were considered and analyzed. The pipes & filters architecture and database-centric architecture were each evaluated but ultimately appeared less beneficial to our specific project.

The benefits of the event driven architecture are described below.

- Additional transformations can be added after the initial design without needing to rework the entire system.

- Transformations can be easily reused throughout the system.- The architecture can be used to develop either concurrent or sequential systems.- Allows very fast responses to events to be implemented.

As with any software architecture, there are also disadvantages to its implementation. The two major drawbacks to event driven architecture are listed below.

- Complex to program.- Difficult to validate.

User interaction will be kept to a minimum – the program will involve the user only when necessary. Since portions of our project are developed as libraries it will be very difficult to debug our code in execution.

The Pipes & Filters architecture was initially examined for the RFID Inventory Tracking System. The project is based on manipulating data received via an RFID tag. Since shipping inventory, receiving inventory, might need to be filtered based on locale and tag protocol we thought pipes & filters would work nicely. However, only having three or four filters does not indicate that we need to handle tag protocols at an architectural level.

Due to the project’s need to communicate with an inventory database to manage shipping and receiving, the database-centric architecture appeared to be a viable software architecture solution. As more details of the project were discovered, it became clear that our project would never bypass Microsoft Dynamics to directly modify information in the database. Once the scope of our project was clarified and our responsibility was to only deal with information transmitted between the RFID reader and Dynamics, the database-centric architecture proved to be less useful than the pipe and filter architecture.

36

37

Section 4: Design Verification

4.1 – Test Results

The following tests present how it was proved that the project, or pieces of the project, functioned according to requirements. Most tests could be verified visually by running an emulator or feeding data and verifying that data was updated and/or stored correctly. The data is presented in the images below.

4.1.1 – Submitting and Storing an ASN

The submission of a vendor ASN and extraction of information into the database required three main functions within the RSubmit module. The interaction of vendors with the RSubmit module occurred with the web page seen in Figure 21 below.

Figure 21: Default Web Page Displayed

ASN Test 1: Successful ASN Submission, Text and XML

Precondition: The vendor has an ASN to upload to the RSubmit module

Post condition: The ASN is saved to the server and the details of the ASN are stored into the database.

38

The first chore of the RSubmit module was to allow the user to submit a standard ASN document in either .txt or .xml format. Radio buttons are used to distinguish between the formats, and Browse and Upload buttons are supplied to allow the vendor easy accessibility to their ASN file. Once the vendor clicks the Upload button, the parsing function for the associated radio button selection is called. Upon successful submission of an ASN file, the vendor will be supplied with a quick message including the ASN number, PO number, total items included, and date and time submitted. A sample message after a successful submission is shown below.

Figure 22: Successful ASN Submission

Once the Upload button is clicked, the AsnStore table of the database is modified to reflect the new ASN entry. The information has been directly pulled from the vendor’s ASN. Figure 23 below shows the new entries into the database.

Figure 23: Rows entered into Database

Additionally, a View Detailed Information link button will appear after an ASN is uploaded. The vendor can view all information that was stored on the database as seen in Figure 24. The XML version of the View Detail Information link button is in Figure 25. Figures 24 and 25 are shown on the following page.

39

Figure 24: Details after Link Button Click – Text Version

Figure 25: Details after Link Button Click – XML Version

40

ASN Test 2: Web Page Exception Handling

Precondition: A prerequisite of the RSubmit module has not been met.

Post condition: An error message is displayed to the user that suggests corrective action.

The exception handling for the ASN submission and storage verifies that a file has been selected to upload and also that the file is a standard ASN in .txt or .xml files. Proof of valid exception handling is in Figure 26 and 27.

Figure 26: Error – No File Uploaded

Figure 27: Error – Incorrect Format Type or Non-standard ASN Submission

4.1.2 – Retrieving RFID Data

In order to correctly read in data from a reader on a network a simple application was developed to do so. This application simply detects when a specific reader turns on,

41

for example the receiving or shipping reader, and handles data accordingly. The application is capable of discovering the reader and parsing the tag list from the reader. This meets our first engineering requirement, that the system must be able to understand tag data from Alien RFID readers. Figures 16-18 illustrate the results achieved from this reader integration. The program was initially tested using an RFID simulator, Rifidi emulator, which allows the tag id to be specified, so that it was possible to ensure the correct tag was being read by the reader. Next the Alien Utility was used to read an actual tag and then the program was used to read the same tag, once again verifying that it was reading the correct tag.

Figure 28: Connection to Reader

42

Figure 29: Parsing Tag List

Figure 30: Viewing Tag Data

43

4.1.3 – Completed RDetect Testing

The RDetect portion of the project has been tested and the results are shown below. Due to this project being a proof of concept, the tests shown are those related to overall project functionality and preventative measures to guard against unintended use.

4.1.3.1 – Reader DetectionReader detection refers to discovering RFID readers connected to the server either

by the serial communication port or via local intranet.

Test Case:

Precondition – Alien RFID readers are turned on, and connected to the server.

Post condition – Alien RFID readers are displayed in the reader list.

Step 1 – Start the detection process by running the RDetect windows application:

Figure 31: Empty Reader List

44

Step 2 – Set the frequency related to discovering connected Alien RFID readers, and wait for them to be detected and added to the reader list:

Figure 32: Detected Alien RFID Readers Dynamically Added to Reader List

4.1.3.2– Updating Reader AvailabilityReader availability refers to readers that online and able to be connected to read

tag data. Once a reader that has been detected goes offline, the availability of the reader has changed and needs to indicate that tag data can no longer be read from the reader.

Test Case:

Precondition – A detected reader has been turned off.

Post condition – The active field for the detected reader is updated to false in the ReaderStatus table.

Error Handling – All exceptions thrown from database calls are caught and are displayed to the user.

45

Step 1 – With the RDetect windows application running assert an Alien RFID reader has been detected:

Figure 33: Detected Reader and ReaderStatus Table

Step 2 – Turn detected Alien RFID reader off:

46

Figure 34: Reader List and Updated ReaderStatus Table

4.1.3.3 – Reader ConnectionReader connection refers to logging into an Alien RFID reader that has been

discovered.

Test Case:

Precondition – Alien RFID readers are detected and displayed in the reader list.

Post condition – Login Successful.

Step 1 – Select a detected Alien RFID reader from the reader list and select the location of the reader and enter the userid and password for the reader:

47

Figure 35: Connection Setup

Step 2 – Test the connection to assert valid data is stored:

Figure 36: Test Connection Prompt

48

4.1.3.4 – Storing Reader Connection DataReader connection data refers to reader data stored in the ReaderStatus table that

is used from the RManage portion of the project.

Test Case:

Precondition – Selected Alien RFID reader has successfully logged in.

Post condition – Successfully Stored.

Step 1 – Click the save connection button:

Figure 37: Update Connection and ReaderStatus Table

4.1.4 – Integrating Into GP

Integrating an application proved to be harder than originally thought, due to the fact that there exists little or no documentation. Developing an add-in application requires locating the specific Dynamics form(s) you with to modify and attaching your process to that form. Since it would be very destructive to directly modify Dynamics tables all data must be instead updated through the Dynamics form structures. This allows the business logic of the program to be maintained, by allowing Dynamics to

49

update all the necessary parts of its tables. In order to discover how to import data into Dynamics another application was developed to simply take data that was given and add it into the correct form for user review and posting. This was done from the receiving perspective, but can easily be ported to shipping. This meets the fourth and fifth engineering requirement by running effectively in the proper environment and by preserving the business logic level, so as not to affect the function of Microsoft Great Plains. In the test application a new window was created to allow the user to type in specific information that should be added to the order, in this case a receiving order. When the ASN integration is complete and RFID tags can be mapped with product ID’s this window can be removed and data from the ASN can simply be piped directly into Dynamics. This is shown in Figures 19 – 24.

Figure 38: Application Add-in on the Receiving Window

50

Figure 39: The Application Test Window

Figure 40: Information that will later be provided by the ASN

51

Figure 41: Auto-Post to Order

Figure 42: Information that will later be provided by the RFID tag

52

Figure 43: Auto-Add item to order list

4.1.4.1– Completed Dynamics Add-In Testing

The following are results showing the functioning and testing of the final product for the add-in portion of the project. All possible sources of errors have been checked caught and accounted for. This portion relies on data from an SQL database which is maintained by the other two portions of the project.

4.1.4.2 – ReceivingThe receiving portion of the add-in performs most of its tasks in the background

and automatically modifies Dynamics only gathering user data when necessary, meeting our seventh engineering requirement. First the user must click “Receive via RFID” in the receiving form and after this a window will present itself asking which reader should be used in case more that one receiving reader is used. Next this portion automatically waits for and receives tags once again meeting the first engineering requirement. Once a tag is received the ASN is retrieved from the database allowing the tag and all following tags to be compared and the item number to be found. Once the item number of the tag is found on the proper ASN the item is added to the Receivings form in Dynamics, which meets the second engineering requirement. Any read errors or reader problems will be presented to the user and receiving will stop meeting the sixth engineering requirement. Once the user selects to stop receiving if all items have not been received a summary of

53

these comes up and allows the user to add them manually in case they have been missed otherwise an order summary comes up and then the user is left with a completed receiving transaction entry form. The process is shown in the figures below:

Test Case:

Precondition – An ASN for an order has been received and the following information is present in the database:

Figure 44: ASN Store

Post condition – The order is present and correct in the Dynamics Receiving Form

Error Handling – Any incorrect tags will be ignored as they will most likely be picked up from other nearby tags. Any items not received will be displayed. If the reader for some reason disconnects we will stop receiving tags and continue automatically to the next step as that is a signal of order completion.

Step 1 – Start the receiving process by clicking receive via RFID on the Receivings window of Dynamics:

54

Figure 45: Menu item location (Dynamics Receivings form)

Step 2 – The Reader pops up and searches for all available readers. Select one of the available from the list.

Figure 46: Reader Selection Window

Step 3 – The Reader information is displayed and the start receiving button becomes enabled:

55

Figure 47: After Selecting a Reader

Step 4 – After the user hits start receiving the program connects to the reader and waits for tags. Upon receiving the first tag it finds the appropriate ASN and loads it in:

Figure 48: Receiving the first tag and getting the ASN

Step 5 – The information of the order and the first item or items is then piped into the receiving window and we wait for more tags until the user hits “Stop Receiving”:

56

Figure 49: Data Added, Waiting for More

Step 6 – When the user hits stop the program checks to see if any items on the order have been missed. If so the user is presented with this information and asked what to do:

57

Figure 50: Items Not Received

Step 7 – If the user chooses they can add these items anyways in case they were missed:

58

Figure 51: Items being added from items not received list

Step 8 – Finally a summary of all items received through the RFID process is presented:

59

Figure 52: Summary of Order

Post condition met

60

Figure 53: Entire received order given to Dynamics to be added to inventory

4.1.4.3 – ShippingThe Shipping portion of the add-in is responsible for taking an order that is being

shipped and allowing the user to make associations between item numbers and tags. When the user clicks generate ASN in the shipping window the form below shows up. This form allows tags to be retrieved from the appropriate reader in the shipping bay. The user then has to associate these tags with an item from the order being shipped. When finished the user can then generate the actual ASN file and save it wherever they want to be sent out to the appropriate business. All possible errors are caught if the user enters invalid data or tries to generate the ASN without the necessary data meeting the sixth requirement. This process is shown in the figures below:Test Case:

61

Precondition – An order has already been placed in the ERP system and is ready to be shipped.

Post condition – A correctly formatted ASN has been generated.

Error Handling – Missing Data – Message box to user and do not allowTrying to use a tag for multiple items – Message box to user and do not allowReader goes offline – Disable the “Get Tags” button and refresh readers.

Step 1 – Start the shipping process by clicking the “Generate ASN” menu item on the sales window of Dynamics:

Figure 54: Menu item on the sales transaction window

Step 2 – All available shipping readers are displayed in the list and you must choose the one to use:

62

Figure 55: The generating ASN window

Step 3 – Once a reader is selected, its information is displayed and get tags is enabled. The user needs to click get tags and read tags will be added to the tag list:

63

Figure 56: Getting tag IDs from the reader

Step 4 – The user must enter the ASN number in the appropriate box. Palette tag can be set by selecting a tag and hitting “Associate” and unset by clicking “Unassociate”:

64

Figure 57: Associating the palette tag

Step 5 – Items must be selected from the sales transaction window, which causes its information to be displayed in the ASN window:

65

Figure 58: Selecting items to add to the ASN

66

Step 6 – Tags must be given to the items by selecting the tags and hitting “Associate” and unset by clicking “Unassociate”:

Figure 59: Associating tags with items

Step 7 – When finished the user simply has to hit “Generate ASN” and the ASN is shown to the user:

67

Figure 60: Example ASN produced from information

Step 8 – Finally the user can save the ASN by hitting “Save” and selecting a location:Post Condition Met

68

Figure 61: Saving ASN

69

4.2 – Requirements Verification

Table 9 illustrates how each of the requirements presented in the project were verified, if verified. Figure and supporting evidence can be found in section 4.1 containing information on test results.

Engineering Requirements Requirement Met?

Verification References

The system must be able to understand tag data from Alien RFID readers.

Yes A program was created to detect and parse tag lists from an RFID emulator, which was successful. Next a known tag was read from an Alien reader and checked against the known tag ID.

Section 4.1.2

The system must be able to read ID’s and modify inventories with 100% accuracy.

Yes When a database contains an ASN and a tag is read in, the correct item is found in the database if it exists 100% of the time.

Section 4.1.4.1, Section 4.1.4.2

The system must auto receive/send Advanced Shipment Notifications and Goods Received.

Yes When an order is ready to be shipped the user clicks “Generate ASN”. A window allows them to make the proper associations and then it can be saved and sent wherever necessary.

Section 4.1.1, Section 4.1.4.3

The system must run in a Microsoft Windows XP+, Server 2003 environment.

Yes The software was developed using tools available to these systems, insuring it will run as intended.

Section 4.1

The integration must Yes Dynamics add-ins were Section 4.1.4.2,

70

preserve the Business Logic of Microsoft Dynamics Great Plains.

created to work directly with Dynamics forms rather than modifying its tables. This would allow Dynamics to do the actual table updates so that it can still maintain its business logic.

Section 4.1.4.3

The system must notify the user of any read errors.

Yes When any problems occur during reader use or during user data entry the user is presented with a description of the problem and the problem is handled accordingly.

Section 4.1.3.2,Section 4.1.4.2,Section 4.1.4.3

The system should aid in automating specific transactions for Dynamics.

Yes The system is complete and fully functional.

Section 4.1

Table 9: Requirements Verification

4.3 – Standards

Existing design standards are employed by our system in two main areas. RDynamics will accept any Gen2 SGTIN tag, the standard RFID tag commonly used in major retail inventory transfer. However, the system is not limited to these specific 96-bit tags and can process many other tags able to be read by RFID readers. The EDI 856 standard for ASNs was used to create the functions that parse incoming ASNs and also to construct ASNs from the RManage component. If an ASN is submitted that does not follow the standard it will cause an exception and error message and will not be accepted by the RSubmit component.

71

Section 5: Summary and ConclusionsDeveloping the RDynamics system required a very intensive design process. Many

intricacies of different programs, technologies, and programming languages were learned throughout the design process. A large lesson was learned in the necessity of careful planning whenever a project is undertaken that allows users to develop components independently of each other. Separate development is helpful to speed up the design process; however, the inputs and outputs of each system must be completely realized so that no compatibility issues arise. When dealing with different technologies, having correct and updated .dll files is imperative. Furthermore, having good documentation for whatever software is being modified is incredibly crucial, as being without it results in many hours of trial and error for a process that would have been trivial had it been properly documented.

Any further work on this project would only enhance the system, it is already fully functional. Developing a solution that is more generic would have been much more difficult, but could have a large benefit considering the rate that software becomes obsolete. As it stands, the system works well considering the given constraints and development tools.

Section 6: References[1] “Radio Frequency Identification”, Wikipedia, 2007, http://www.wikipedia.org

72

[2] “The 2007 Statistical Abstract”, U.S. Census Bureau, 2007, http://www.census.gov/compendia/statab/wholesale_retail_trade/establishments_sales_payroll_and_employees/

[3] Todd Wasserman, “Is RFID Right for Your Business?” Inc., Dec 2006, http://technology.inc.com/telecom/articles/200612/rfidright.html

[4] “Enterprise Resource Planning”, Wikipedia, 2007, http://www.wikipedia.org

[5] “SAP R/3”, Wikipedia, 2007, http://www.wikipedia.org

[6] Daniel E. O’Leary, “Enterprise Resource Planning (ERP) Systems: An Empirical Analysis of Benefits,” Journal of Emerging Technologies in Accounting, Vol. 1 2004, http://www-rcf.usc.edu/~oleary/Papers/Empirical%20Benefits.pdf

[7] “Sundex offers ‘slap and ship’ RFID solutions to Wal-Mart suppliers”, Sundex Information systems, April 21, 2004, http://www.sundex.com/news_april2004.asp

[8] “Microsoft BizTalk Server 2006 R2 Pricing and Licensing”, Microsoft Corporation, September 10, 2007, http://www.microsoft.com

[9] “EPC/RFID Program Update”, Best Buy, July 21, 2005, http://www.bestbuy.com

Appendix A: Project Management Plan

73

A.1 – Work Breakdown

74

75

A.2 – Member ContributionsDan Russo was responsible for all design concerning Alien Readers. This included, but

was not limited to reader status changes, connecting to readers, and network discovery. He also created the RDataStore database and associated procedures. Ken Virostek developed the web page which consisted of uploading the ASN to the server, parsing the ASN in different formats, and storing the ASN in the database. He also aided Jarrod in creating ASNs from Dynamics. Jarrod Cook worked with Dynamics forms and automating transaction processes. He interacted with both Dan and Ken to completely integrate the project.

A.3 - Acknowledgements The Silver Snakes would like to thank Dr. Xiaocong Fan for his continued support and

guidance throughout the duration of the project. We would also like to thank Dr. Kathy Muhonen and Dr. Wen-Li Wang as well as Mr. Nick Konzel and Mr. Kurt Bleil from Distributed Network Software, LLC. The faculty should be praised for their exceptional guidance and for their contributions and advice given on each report and presentation. The industrial sponsors should be acknowledged for their prompt responses for any questions posed, and also for allowing us to be creative with our final design.

76