PDA DRIVEN WAREHOUSE INVENTORY MANAGEMENT SYSTEM Sebastian Albert Master of Science in Technology

Transcription

1 PDA DRIVEN WAREHOUSE INVENTORY MANAGEMENT SYSTEM Sebastian Albert Master of Science in Technology Abstract In times of economic slow-down, cutting costs is the major strategy used by the companies. There is a need to track the performance of each product in terms of demand to determine how much to order and when to order. The parameters that are required to answer these questions are economic order quantity (EOQ) and the re-order point. The annual cost of each product is obtained to determine the best deal for the invoices received for the product. This project implemented a mobile inventory management system in PDA and tracks the performance of each product using a web application. This will help the decision makers to initiate accurate re-order and make forecast and demand of the product at any point of time. 1. Introduction Stock items to be delivered exactly when needed are impractical. Therefore it is necessary to establish inventory policies concerning when to replenish and how much to replenish. The costs that are relevant are procurement cost, cost of the item, carrying cost and order cost. There is no need to keep buffer stock when demand and lead times are known. This helps in minimizing the cost of the inventory [1]. The major objective of the project is to implement a mobile inventory system in a PDA, update the product and invoice details obtained from the PDA into server database, set and calculate parameters required to determine economic order quantity of the product, re-order point and the annual cost of the product. The following sections discuss about the problem at hand, requirements of the project, design of the system, the methodology used to implement the system, validation and conclusion. 2. Problem Statement The inventory management requires to answers two basic questions: how much and when to order to be cost effective. The agents of the system identified are the sourcing manager who places the order, the vendor who provides the invoice for the product, the inventory personnel who updates the system and the planner who determines an inventory policy and displays the results. The Economic Order Quantity can determine the minimum quantity that needs to be ordered every re-order point. EOQ is essentially an accounting formula that determines the point at which the combination of order costs and inventory carrying costs are the least. [2]. Forecasted annual usage, order cost and carrying cost are used to determine the Economic Order Quantity. Order cost is the sum of the fixed costs that are incurred each time an item is ordered [2]. Carrying cost is primarily made up of the costs associated with the inventory investment and storage cost. [2]. There is a need to compare different vendor invoices; the annual cost of each product needs to be calculated to determine the best deal. The Annual cost is determined by annual usage, order quantity, order cost, carrying cost and safety stock. [2]. Safety stock is the minimum inventory required to be kept in the warehouse. The simplified method to find the safety stock is half the lead- time. Lead-time is the time taken from when the product was ordered to the time it required to reach the warehouse. The Reorder point is the sum of lead-time demand and the safety stock. Lead-time demand is forecasted demand during the lead-time period [3].These parameters were used to answer how much and when to order the product. The next section discuss about the sample calculation used to determine these parameters discussed above. 2.1 Parameters and Formulae The parameter that needs to be calculated is economic order quantity, annual inventory cost and reorder point of the product a. Economic Order Quantity (EOQ): Economic Order Quantity is minimum cost order quantity. EOQ = Sqrt( (2xDemandx Order Cost ) / Carry Cost) Lead-Time is the time required for the ordered products to reach the inventory. 1

2 Lead-Time demand = Demand / Day x Lead-Time Safety Stock is the minimum stock required to be in the inventory. Safety Stock = ½(Lead Time Demand) b. Total Annual Cost: Total Annual Cost incurred for the product: Demand / Order Quantity + ½ (EOQ) + Safety Stock x Order Cost x Annual Carrying Cost c. Re-order Point Re-order Point is the point at which the product has to be ordered in-order for it to reach the inventory before the minimum number product remaining is equal to the number of safety stock. Re-order Point = Lead-time Demand + Safety Stock 3. Project Requirement The project was aimed at building a mobile inventory management system. The customers of the software could be a company that produces a product and requires product parts to be bought from a vendor. The manager is required to place an order to the vendor and provide product details like the name of the product, product id, description of the product, the name of the manufacturer and quantity of the product. The vendor provided an invoice, which would then be approved by the manager. The invoice would contain the cost of the product, the transportation cost and the lead-time that will be taken for the product to reach the inventory. The inventory personal needs to update the quantity present in the inventory at all times. The following section deals with use case specification for each of these agents. These use cases specified in the figure 1 define the acceptance criteria for the system. 3.1 Use Case 1 This use case was proposed for the sourcing manager. It requires the system to provide interface for adding product details and placing the order to the vendor using a PDA. The functions required are ability to update and delete the product, store in a local database and be able to upload the data to the server. 3.2 Use Case 2 This use case was proposed for the inventory manager. It requires providing the functionality of order quantity and order date update for each product. The system requires storing the changes to the local database in the PDA and upload to the details to the server. 3.3 Use Case 3 This use case was proposed for the vendor. It requires providing functionalities to download the ordered products and be able to upload invoice details to the server. 3.4 Use Case 4 This use case was proposed for the inventory policy planner. It requires functionalities to set parameters namely, annual demand, order cost and carrying cost. Based on these set parameters economic order quantity, re-order point and annual cost needs to be determined. The results need to project product details stored from the updates from the sourcing manager, inventory manager and vendor in the form of a table and a graph showing the updates of the order quantity and order dates from the inventory manager indicating the safety stock and re-order point. Figure 1: Use case Specification 2

3 4. Design of the Application 4.1 System Design The system design comprises of two PDA connecting to the Server and having a back-end database as shown in the figure 2. The system was designed to meet the use case specification. It was separated into modules. Use case 1 and Use case 2 were merged i.e. sourcing manager and the inventory manager were merged into one module. The module for manager would add, delete, update and upload product details to the server. The database comprises of an inventory table to insert and update the product details and another table would be created for every new product to update order quantity and order date to record a history of product updates. This would be helpful in projecting graphs and forecasting demand of the product over a period of time. Vendor module would download the product detail from the server and update the invoice details into the server using the PDA. The planner would use the third module; the web application would be used to log into the system and be able to see the list of product being ordered. The module will help the planner update the parameters required by the system to determine the economic order quantity, annual cost and the re-order point. The system would calculate the annual cost, reorder point and display the results in a table and project re-order point in a graph. 4.2 Technical Design The technologies used for the implementation of the project were J2ME for the PDA clients, Java Server programming for the Web application. Apache WebServer Tomcat is used for hosting the web application. The data was transferred in XML format. Record management System is used to store data in the PDA. The data is transferred using an HTTP connection established between the PDA and a Servlet in the Tomcat. PostgreSQL is the back-end RDMS database used. It requires a UNIX environment and was installed in Cygwin, a windows based unix environment. The persistent data about the product is stored in PostgreSQL. kxml is used to render the product in XML format in the PDA for manager and the kxml parser would be used to parse and obtain the data from the server in the PDA for the vendor. Document Object Model parser is used by the Servlet to insert the new product detail and update the older product details. Sirius Jpowered library package is used to display the graph. Technologies used are summarized below. MIDP Mobile Information Device Profile defines API s to write application for small POSE devices Emulator of PDA to test and debug before loading into the actual device RMS Record Management Store to store data locally in the MIDP client kxml Pull parser for MIDP clients to write and parse XML DOM Model parser used in servlet to parse XML for product detail PostgreSQL Back-end database Servlets JPowered management system Server side processing of clients requests Provides libraries to project Graph Figure 2: System Diagram 3

4 5. Implementation Implementation was divided into four phase and were implement in a two week mile stone basis. The following sections discuss implementations, tests and issues faced in each of these phases. 5.1 Manager PDA interface / functionality development Phase one comprises developing the PDA interface for the manager. A PDA application for the manager of inventory was created with the ability to add, delete and update the product detail. The Canvas class was used instead of the Form class to enhance the graphical appearance and Textboxes were drawn to obtain the values for the various fields like product name, product ID, manufacturer name, number of order quantity, and date of order placement. The data was written into records in the form of byte arrays. Records are stored as memory chunks in the PDA and the record enumeration is not in sequence. Use of the rebuild function to update the enumeration to reflect the current record set and reset function to return the enumeration index to the same state as right after the enumeration was first created helps in implementing data manipulation functions. 5.2 Data Communication and Database update of Product details This phase comprises of establishing a HTTP connection and transferring the product details in XML format. A HTTP connection was established between a servlet and tested with passing a string. Using kxml, the record was enumerated and all the product details were written in XML format into a string. This string was then sent to the server. The servlet was used to read the string and create an XML file in the server. The XML file was then parsed using a DOM parser and the data was stored into an array. The major issue dealt here is to separate the products that were newly created and those that were updated. This can be done by checking the database for the current number of products stored in the database with that of the product list obtained from the XML file. The product list from the database can be obtained with a simple SELECT query into a result set. Those that were in the database were updated using UPDATE query and those that were added new where inserted using INSERT query. kxml parser is large in memory usage and therefore classes that were not needed were removed. kxml package needs to be in the zipped format if java wireless toolkit was used in development. HTTP connection needs to be enabled in the Java MIDP preferences if Palm emulator is used for development. 5.3 Vendor interface/ functionality development This phase comprises of building the PDA interface for the vendor with upload and download functionality for providing the invoice detail. A PDA application was created to request the product list ordered by the sourcing manager. The XML file was read by the servlet and then sent to the client PDA as a string. The kxml parser in the vendor PDA then parsed the string and product details extracted were stored into the record management store. Each time the product list is downloaded, the old record stores containing all the records are deleted and a new record store was created and the product lists were stored. The data was then displayed. The vendor was provided with functionality to update the data for the product and upload updated details when connected to the wireless network. 5.4 Web Application for the Inventory Policy Planner Phase four comprises the developing of a web application required for the inventory policy planner. The products were listed from the result set obtained from the servlet from the database and on selecting each product the planner would be provided with a web page to enter details required to calculate the annual cost and re-order point of the selected product. The table was projected for the product with the current product details, and a graph would be displayed with the order quantity in the y axis and order date on the x axis and showing safety stock and re-order point. 5.5 Implementation with wireless connection Handspring visor was used to run the software. Xircom WLAN was used to connect the PDA to ASU wireless network. The network setting was set to dynamically obtain an IP address using DHCP. The PDA was used to transfer product details wireless to the server. 6. Sequence of Events The inventory manager places order through the PDA and the details are stored into the local database. The screen shot shows adding a product by selecting with the stylus into the textboxes and updating the product detail. 4

5 Product Added Display on selection On selecting the product from the list, product name is updated to kycero3 Product cost, transport cost and lead-time can be updated and uploaded. After setting parameters like demand, order cost and carrying cost, the table and graphs are projected for each product. Table showing Product details: Deleting the product shows a sample product Download the product in Vendor PDA 5

6 Graph showing the re-order point: 7. Results and Validation The use cases were considered to be the acceptance criteria for the project to be successful. The use cases were validated and the results are discussed in this section. Use case 1 & 2 results: The software application loaded into the PDA has the ability to add, delete, update and upload the product details from the local database into the server database. Use case 3 results: Software application for the vendor has capabilities to download product details, update invoice details and upload data to the server. Use case 4 results: A web application has a login page and list the list of products updated. Parameters can be set for each product and results were calculated and projected for every product detail in a table and graph. A sample table can be seen in the Appendix. The graph projects a history of order quantity and date updates in y and x axis correspondingly. Sample graph result is projected below. 8. Conclusions The project was successful in implementing the use cases identified in the inventory management scenario and the application was able to track the performance of each product. The major advantage of the project is that the client can run applications offline and can periodically update the server. 8.1 Applied Technologies Learned The Database Management System and Software for PDA courses taken helped in learning the technologies required to implement the software. The project helped in enhancing the knowledge in J2ME programming, Java Server Programming, Database connectivity, SQL queries, XML parsing using DOM, XML manipulation using kxml. 8.2 Issues Dealt With Records are stored as memory chunks in the PDA and the record enumeration is not in sequence. Use of the rebuild function to update the enumeration to reflect the current record set and reset function to return the enumeration index to the same state as right after the enumeration was first created helps in implementing data manipulation functions. The complicated design of the system consisting of many parameters and agents were simplified. The role of a sourcing manager and the inventory personnel was merged. The Vendor was assumed to provide the invoice for any product ordered. 8.3 Advantages of the Software The inventory management software application in mobile devices will be highly useful. The inventory personals require moving around the inventory to get updates about the quantity of the product. The application can run offline and therefore does not require wireless access in the inventory and can later transfer the data to the server at a convenient time. The advantage of using XML was that the data was self-describing and the client and the server are loosely coupled. kxml is a pull parser and the application can process the data as it is being downloaded from the server.[4] Planners of the inventory policy can have updates straight from the inventory and therefore can track the productivity of the product instantly. The planner could project the annual cost that would be incurred by the product in the long run by getting the invoice from the vendor providing the product. This helps in making better choices in terms of placing orders with the vendor providing the best deal and determining the products that are more productive. 8.4 Future Work The functionalities in the project can be improved by having many vendors able to access the product detail and be able to give invoice details. The system needs to have functions to identify each vendor and be able to compare the annual cost projected and 6

7 pick the best deal. A separate module could be developed for the sourcing manager and the inventory update. Callback functionalities to sourcing manager to place order on re-order points and vendor to provide invoice on orders placed can be provided. The inventory management parameter calculation can be converted to accessible Webservices. The project can also be extended to forecast demand as the history of order updates is being tracked. References [1] Adam, Everett E., Jr.; Ebert, Ronald J, Production and Operation Management Concepts, Models and Behavior. Paramus, NJ, U.S.A. Prentice Hall PTR [1988]. [2] Optimizing Economic Order Quantity (EOQ), Dave Piasecki, Available Http: ty.htm [3] Optimizing Safety Stock, Dave Piasecki, Available Http: [4] Parsing XML in J2ME, Available Http: ticles/parsingxml/ APPENDIX 1 Product Detail Schema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns="vendor:orderlistschema" elementformdefault="qualified" targetnamespace="vendor:orderlistschema"> name="prodlist"> <xs:complextype> <xs:sequence> name="product" type="prodtype" /> </xs:sequence> </xs:complextype> </xs:element> name="product"> <xs:complextype> <xs:sequence> name="prodname" type="xs:string" /> name="id" type="xs:string" /> name="manf" type="xs:string" /> name="order-qty" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Sample XML for the schema above:?xml version='1.0' encoding='utf-8'?> <products xmlns='product:proddetailschema'> <productlist> <prod> <name>spanner</name> <id>1234</id> <manf>lowes</manf> <description>product to screw</description> <order_qty>76</order_qty> <arrival_date> </order_date> </prod> </productlist> </products> Vendor Invoice XML Schema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns="vendor:invoiceschema" elementformdefault="qualified" targetnamespace="vendor:invoiceschema"> name="invoice"> <xs:complextype> <xs:sequence> name="product" type="producttype" /> </xs:sequence> </xs:complextype> </xs:element> name="product"> <xs:complextype> <xs:sequence> name="prodname" type="xs:string" /> name="lead_time" type="xs:string" /> name="transport_cost" type="xs:string" /> 7

8 name="prod_cost" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Sample XML based on the above schema: <?xml version='1.0' encoding='utf-8'?> <!-- Vendor Invoice corresponds to vendor schema --> <invoice xmlns="vendor:invoiceschema"> <prodlist> <product> <prodname>spanner</prodname> <lead_time>4</lead_time> <transport_cost>12</transport_cost> <product_cost>65</product_cost> </product> </prodlist> </invoice> APPENDIX 2 SOFTWARE REQUIREMENT SPECIFICATION The System requires two personal digital assistants, a tomcat Web Server with a PostgreSQL RDBMS as backend database. Palm OS emulator was used for testing and debugging. PostgreSQL is run in Cygwin environment. Programming language was Java.Ant was the build tool used. MIDP Profile and Configuration APIs required for the client. Development Environment and Required Packages Programming Lg Java: j2sdk1.4.1 Build Tool- Ant: jakarta-ant Server- TOMCAT:jakarta-tomcat RDBMS- PostgreSql: postgresql IDE- J2ME Wireless ToolKit 2.1 Pull parser for client PDA - Kxml2.1.7 API used for MIDP client- Profile: midp4palm1.0, midp2.0fcs Configuration: j2me_cldc1.0.4 PDA Emulator- Palm OS Emulator: POSE 3.0a8 Platform- Cygwin: version JPowered Graphs 8