User talk:Siddharthpoddar

STOCK MANAGEMENT SYSTEM
Index 1. Introduction 1.1. System objectives and overall description 1.2. System boundaries 1.2.1. System context 1.2.2. System constraints and assumptions 2. Functional requirements 3. Non-functional quality requirements 4. Future requirements 5. Appendices 5.1 Context diagram 5.2 Entity-Relationship diagram 5.3 Data Flow diagram 5.4 Goal diagram 5.5 Sales Analysis diagram 5.6 Sales Analysis model

1. Introduction There are supermarkets, suppliers, and warehouse managers in the system. The company has 500 supermarkets and a big warehouse. About 4000 items are stored in the warehouse. Each item is provided from exactly one supplier.

1.1. System Objectives and Overall Description

1.1.1. The Stock Management System (SMS) assumes control over the bookkeeping and accounting needed to operate a Warehouse for a company specializing in retail sales of food and groceries. All day-to-day operations of the warehouse, as well as conducted weekly accounting of the products stored in the warehouse and disbursed to participating supermarkets, will be performed by the software.

1.1.2. A considerable amount of accounting needed to operate a typical warehouse calls for a reliable and fast software tool to help the warehouse management handle flows of information regarding incoming and outgoing quantities of products and a stock inventory.

1.1.3. The problem of storage of the accounting documents such as invoices and orders would be solved.

1.1.4. Tedious arithmetic involved in the corresponding bookkeeping will be automated.

.1.5. A cost of maintenance of a specially trained accounting professional in the warehouse would be saved by replacing this position with a software tool and a less costly data entry specialist.

1.2. System Boundary

1.2.1. System Context

1.2.1.1. The SMS is located at central warehouse and keeps track of the stock level of each item in the warehouse, orders from supermarkets, and orders from the warehouse to the suppliers. Items and product groups and their quantities in the warehouse are all part of the system.

1.2.1.2. The SMS will provide supermarket managers with the ability to enter ordering information directly into the system. But it also accepts the order by phone from the supermarket that doesn't have the connected computer system. In this case, a data entry specialist will handle the paper formats of orders and invoices.

1.2.1.3. A convenient GUI (graphical user interface) will provide users with the ability to quickly enter the information from the incoming orders from the supermarkets and to output the invoices reflecting the outgoing flow of goods supplied to the supermarkets.

1.2.1.4. To maintain the current level of the stock inventory, the system will be provided with easy-to-use ways of entering the product information such as names, quantities, purchasing/sales prices, and stock level.

1.2.1.5. A database of records reflecting each in and out transaction will be automatically maintained.

1.2.1.6. The SMS is supposed to provide the weekly sales analysis report reflecting the warehouse operations during the week in an automatic manner.

1.2.1.7. A careful analysis and bookkeeping will be conducted regarding the delayed orders arising from insufficient stock levels happened during the week.

1.2.2. System Constraints and Assumptions

1.2.2.1. The SMS assumes that all deliveries from warehouse to supermarkets are successfully completed, so there is no loss of item or delay on the way to the supermarkets. Therefore any trucking system is beyond the SMS boundary.

1.2.2.2. The SMS assumes all suppliers have enough stocks, therefore whenever warehouse manager orders items, they can be delivered within 24 hours.

1.2.2.3. Specific bookkeeping and accounting regulations reflecting the current laws and regulations will have to be programmed when updated.

1.2.2.4. The system will require some occasional supervision of a trained accountant to verify its correctness upon the system update.

2. Functional Requirements

2.1. Accepting Orders from Supermarkets

2.1.1 Informal Description

2.1.1.1. Supermarket Manager initiates the processing of the order. The manager provides ordering information such as the name of the supermarket, the requested item, the requested amount of the item, and the date and time of ordering. Either the supermarket manager keys the data into the SMS directly, or he orders by phone and the warehouse operator keys the entry into the SMS.

2.1.1.2. The orders from different supermarkets on each different item will be enqueued daily up until 4 p.m., after which the queue will be processed and the supply of each item will be determined (batch processing). After the 4 p.m. threshold, the queue is emptied and the accumulation of orders for the next business day commences.

2.1.2. Precondition: Supermarket manager is at the terminal, and the warehouse system is in a consistent state. The stock level of the supermarket goes down to a certain level.

2.1.3. Postcondition: The manager gets the unique order id number in return.

2.2. Responding to Orders from Supermarkets

2.2.1. Informal Description

2.2.1.1. After the batch processing has been completed soon after 4 p.m. on each business day, the SMS shall first process the delayed (i.e. carried over from the previous day(s) orders, for each of the items) orders. The recent orders (i.e. ones from current day) will be serviced next. 2.2.1.2. Now that the order has been received, the system responds to it and decides how much stuff the supermarket will get. For each item for which any quantity has been ordered by any supermarket, the SMS checks the amount of available items versus the sum of the amounts in the orders.

2.2.1.3. If there is enough in the warehouse to complete all orders, then they will all be filled, the goods sent, the supermarkets billed, and the amount in stock will be reduced by the amount sent.

2.2.1.4. If there is not enough stock, then the delayed orders are filled proportionately to the amounts desired. The remainders for each order shall thereby become delayed for some (or all) of the items.

2.2.1.5. The stock inventory is updated for each item to reflect the new quantities that remain. A record is kept of the state of each order for each item.

2.2.1.6. An invoice shall be generated to reflect the Item, Amount, Destination, and Date of shipping for each order.

2.2.2. Precondition: The batch job starts at 4:00 P.M., and the item, order id, amounts and order date and time are correct.

2.2.3. Postcondition: The goods are then sent, the supermarkets billed, and the amount in stock and requested by the supermarket is reduced by the amount sent.

2.3. Getting Supermarkets Billed

2.3.1. Informal Description

2.3.1.1 The supermarket is billed for goods rendered.

2.3.2. Precondition: A supermarket’s order is filled and the goods indicated in invoice are sent to it.

2.3.3. Postcondition: Supermarket now owes the amount in the invoice more money.

2.4. Sending Goods to Supermarket (outside System)

2.4.1. Informal Description

2.4.1.1. Put the items in the mail or on the truck to be shipped to the market.

2.4.2. Precondition: There are enough of the appropriate goods in the warehouse.

2.4.3. Postcondition: The goods are no longer in the warehouse but are on their way to the supermarket. They are assumed to eventually arrive.

2.5. Ordering from Suppliers

2.5.1. Informal Description

2.5.1.1. Upon processing all orders, the system checks the stock inventory. For each item, if the remaining quantity is less than 100 items (i.e. may be from 0 to 100), an order is sent to the corresponding supplier for 1000 units of the item.

2.5.1.2. If there is none of an item and the supermarkets have requested some, additionally request the number for which the supermarkets have asked.

2.5.2. Precondition: It is just after 5:00 P.M. after completing all on a weekday and the item being ordered is already in the system.

2.5.3. Postcondition: Restock the supermarket shelves with the appropriate items.

2.6. Receiving Payment

2.6.1. Informal Description

2.6.1.1. Get a payment from the supermarket manager on duty.

2.6.2. Precondition: The supermarket owes at least as much money as the payment amount.

2.6.3. Postcondition: The amount the supermarket owes has been decreased by the amount of payment.

2.7. Paying Suppliers

2.7.1. Informal Description

2.7.1.1. Give a timely payment to the suppliers who would be really happy to have the money.

2.7.2 Precondition: The warehouse owes the supplier money.

2.7.3. Postcondition: The supplier has accepted the payment. The warehouse now owes the supplier the amount less money.

2.8. Processing Deliveries from Suppliers

2.8.1. Informal Description

2.8.1.1. Items from the supplier on a truck have arrived at the warehouse. Some bookkeeping needs to be done.

2.8.1.2. The supplier is responsible for providing the information such as name of supplier, delivered item, amount, date and time of shipping from the delivery slip into the SMS system.

2.8.1.3. The delivery slips are put into a waiting queue in order to be processed at 4 p.m. on each business day. After the 4pm threshold, the queue is emptied and the accumulation of orders for the next business day commences.

2.8.1.4. The stock inventory is updated to reflect the incoming amounts of all the items.

2.8.2. Precondition: The delivery slip has arrived. The supplier and the item have been entered into the system.

2.8.3. Postcondition: The stock of the item has been increased by the appropriate amount. The amount in question has been added to what the warehouse owes the supplier.

2.9. Conducting a Daily Sales Analysis

2.9.1 Informal Description

2.9.1.1. The system starts with the number delayed yesterday and subtracts the number of delayed orders that have been processed. Then it adds the number of new orders this day and subtracts off the number of non-delayed orders processed. This gives the new daily number of orders processed.

2.9.1.1. the system gives the output in rows and columns, according to accounting regulations. For each supplier, it outputs the amount due to that supplier. For each supermarket, the amount it owes is given too.

2.9.2. Precondition: It is the end of the working day, at 5:00 P.M.

2.9.3. Postcondition:. The warehouse manager can see the sales analysis report of the previous business day in the morning.

2.10. Conducting a Weekly Sales Analysis

2.10.1. Informal Description

2.10.1.1. The SMS shall generate a weekly sales analysis report that shall contain the following information: • Total amount of delayed orders from previous sales analysis • Total amount of orders received during this week from supermarkets • Total amount of delayed orders processed this week • Total amount of non-delayed orders processed this week • Total amount of orders currently delayed.

2.10.1.2. Sets the number delayed for the week equal to the number delayed at the end of the last week minus the sum of the numbers of delayed orders processed plus the new orders this day minus the sum of the number of orders processed daily.

2.10.1.3. Outputs all of these numbers for the day and for the week neatly in rows and columns according to day and gives the sums in the right places.

2.10.2. Precondition: It is Friday night after completing the daily sales analysis for Friday. There have been no problems with the daily sales reports for the last week.

2.10.3. Postcondition: Gives the weekly sales analysis for each of the five business days, from Monday until Friday.

3. Non-functional (Quality) Requirements

3.1. Usability

3.1.1 Warehouse managers should be able to order and view the levels of any stock in the system at any time through a Graphical User Interface. The Graphical User Interface shall conform to company standards outlined later.

3.1.2 There will be a separate GUI for the supermarket managers to use. It will conform to the Company Graphical User Interface Standard.

3.1.3 The warehouse managers and executive management, as well as marketing personnel, will be able to read the sales and reports of how much money the various supermarkets owe as well as how much money is owed to suppliers.

3.1.4 The Company Graphical User Interface Standard states that the interface be clear, uncluttered, consistent, and efficient. A keyboard and mouse will be used, as numbers need to be entered into the system.

3.1.5. There should be few errors and all numerical input should be double-checked with the user. The interface learning curve should be shallow, and occasional users should enjoy learning the system.

3.2. System Performance and Reliability

3.2.1. The central warehouse system should begin its processing of orders at 4:00 p.m. and finish by 5:00 p.m. at least 95% of the time, looking at intervals of at least two months.

3.2.2. Orders from the supermarket to the central warehouse will arrive within one hour 98% of the time, looking at any interval of at least one month.

3.2.3 The supermarket systems should run with 1/20 second response times on systems with state-of-the-art as of 1 year ago $1500 desktops.

3.2.4. The central system should meet all its requirements on a server costing less than $20,000 dollars 1 year ago.

3.2.5. The system should not use more than double an absolute lower bound on its bandwidth consumption.

3.2.6. The mean time between failures of the system shall be no more than once every 10,000 hours. Failure of this means a system crash or more than half of the data is corrupted.

3.2.7. The mean time between failures of the individual supermarket systems shall be no more than once every 1,000 hours. Failure of this means a blank screen, kernel panic, freezing up, but not web browser crashes.

3.3. System Scalability and Modifiability

3.3.1. The company should be able to double the size of its operations without seriously affecting the response time of the system.

3.3.2. The system shall be very extensible: that is, it should be able to become real-time, and it should be implemented in a type-safe language with modern programming principles and practices and should be as extensible and modifiable as possible.

3.4. Portability The system will be portable to the various hardware platforms it needs to run on including Linux, Windows NT, and MacOS. The system should be easily portable to PalmOS.

4. Future Requirements

4.1. The SMS will need to support the estimation of economic ordering quantity and time from suppliers. Therefore it will help to minimize the cost of holding items in the warehouse.

4.2. The SMS will need to support real time stock keeping.

4.3. The SMS will need to support urgent delivery requests from supermarkets.

5. Appendices

5.1. System Context diagram 5.2. Entity Relationship Diagram

5.3. Data Flow Diagram

5.5. Goal Diagram

5.6. Sales Analysis Model

5.6.1. The SMS is supposed to provide the weekly sales analysis report for warehouse managers every Friday after closing daily data gathering.

5.6.2. The business hours of the warehouse are from 9am to 5pm, but all supermarkets are open 24 hours a day 365 days a year.

5.6.3. Definition of sales analysis items

5.6.3.1. Total available amount of each item The SMS generates the total available amount of an item by adding the total remaining amount of the item at previous business day plus the total amount delivered by suppliers for each item every day at 4 p.m. Total amount delivered by suppliers for each day is defined as amount of an item for which warehouse has received the delivery slip from the supplier this day before 4 p.m. For example, the amount delivered on June 1st is equal to total amount on the delivery slips SMS received from May 31, 4:00:01 p.m. to June 1, 4:00:00 p.m.

5.6.3.2. The amount of orders received today Supermarket managers can order items at any time they want, but only orders placed before 4pm everyday will be treated an order occurring on each specific day. In other words, the amount of orders from supermarkets on June 1st is actually the orders placed from May 31, 4:00:01pm to June 1, 4:00:00pm.

5.6.3.3. The amount of delayed orders at the sales analysis on the previous business day The SMS assigns the amount of items to the corresponding orders every 4pm from Monday to Friday. At this point, if the stock level of the requested item is not sufficient to serve all of the orders, the remaining quantity is parcelled out between the orders proportionally to the quantities desired. If the total amount of orders minus the total assigned amount is greater than zero, this amount is defined as the total delayed amount of orders for the next business day.

5.6.3.4. The amount of delayed orders processed today The amount of items which assigned to process 5.3.3.3 today

5.6.3.5. The amount of non-delayed orders processed today The amount of items which assigned to process 5.3.3.2 today Only when 5.6.3.3 equals 5.6.3.4, 5.6.3.5 can be greater than zero. In other words, delayed orders must be processed before new ones.

5.6.3.6. The amount of delayed orders not processed today Defined by 5.6.3.3 less 5.6.3.4

5.6.3.7. The amount of non-delayed orders not processed today Defined by 5.6.3.2 less 5.6.3.4

5.6.3.8. Total amount of currently delayed Defined by 5.6.3.6 plus 5.6.3.7

5.6.4. Event-Response Model Agent Event Response Supermarkets Place orders Total amounts of orders received today / Increase Warehouse Deliver orders Total amounts of delayed orders processed today / Increase Warehouse Deliver orders Total amounts of non-delayed orders processed today / Increase Suppliers Deliver orders Total available amounts of items / Increase

5.6.5. The weekly sales analysis report will include the following information

5.6.5.1. Total amount of delayed orders at previous sale analysis Total amount of orders which could not be served at 4pm on the last Friday.

5.6.5.2. Total amount of orders received this week from supermarkets The sum of amount of orders received during each day from Monday to Friday of this week.

5.6.5.3. Total amount of delayed orders processed this week The sum of amount of delayed orders processed during each day from Monday to Friday of this week.

5.6.5.4. Total amount of non-delayed orders processed this week The sum of amount of non-delayed orders processed during each day from Monday to Friday of this week.

5.6.5.5. Total amount of orders currently delayed = Total amount of orders received this week from supermarkets

- (Total amount of delayed orders processed this week

+ Total amount of non-delayed orders processed this week)

== TEXTED BY SIDDHARTH PODDAR & VAIBHAV VASHISTHA B.Tech(IT) FROM:-MNIT,JAIPUR

FOR FUTURE CONTACT send email at:-siddharthpoddar1990@gmail.com