Galla – the Small Shop ERP Product

1,110 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,110
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Galla – the Small Shop ERP Product

  1. 1. Galla – the Small Shop ERP Product Date: November 13, 2005 Team Members: Palwencha Nagraj Krishna(palwencha@it.iitb.ac.in) (project manager, documentation) Anirudha Joshi (anirudha@iitb.ac.in) (domain specialist, product and human-interaction design) Gulavani Bhargav Subhash (bhargav@cse.iitb.ac.in) (software architect, system interface design and development) Avinash Gupta (avinash08@iitb.ac.in) (quality assurance) Nilesh Nalnikar (nileshnalnikar@iitb.ac.in) (tooling, system interface design and development)
  2. 2. Index 1. Introduction 3 1.1 Background 3 1.2 Design Goals 3 1.2.1 Requirements 6 1.2.2 Preliminary Use Cases 11 2. Architecture 25 2.1 Overall Architecture 25 2.2 Data Models 26 2.3 Object Oriented Design 29 2.3.1 CRC cards 29 2.3.2 Interaction Diagrams 40 2.4 Package Structure 43 2.5 User Interface Design 44 3. Test cases and QA 50 3.1 Test cases 50 3.2 Testing methods and Test optimization 54 3.3 QA Review 55 4. Estimation 57 5. Bibliography 60 2
  3. 3. Chapter1. Introduction 1.1 Background The Need Millions of small shops in urban India are threatened by the changing business environment. As large shopping malls, departmental stores and super markets have emerged to dot the cities, traditional small shops have had to fight back to retain market share. The onslaught of organized retail through large shops is evident in metros and is spreading fast to smaller cities. Large shopping malls provide enhanced shopping experience to the young, upward mobile population that often purchases high-margin, high-value items. Large shops are marketed better, often as multi-city chains such as Crosswords, D-Mart, Big Bazaar, Foodworld, Lifestyle and Shoppers Stop. Their large scale enables them to operate at lower margins – many of the larger grocery stores give discounts over the printed price. Some have even started marketing themselves as the cheapest – “Is se sastaa aur accha kahin nahin.” (No where else will you find it cheaper and better than here.) They use automated systems for procurement, demand forecasting, printing price labels, billing and inventory tracking, ensuring high efficiency at lower costs. However, large shops have some problems. Several of the large shops are very crowded on weekends. Because customers tend to buy for the whole week at a time, their average shopping is higher, leading to long queues at the checkout cashiers. To manage crowds, these shops have had to deploy better security arrangements, thus taking away some of the shopping experience. Since a large shop caters to a larger geographical area, customers have to either bring their vehicles (cars, scooters) leading to traffic congestion near the large shop, or need to rely on public transport (bus, rickshaw, taxi) to reach the shop and particularly to carry their purchase back home. Moreover, and perhaps because of these reasons, large shops have not yet managed to attract shoppers from lower-middle and lower classes in the cities. This poses an opportunity to the small shops. Small shops have responded by improving quality of service, in particular by introducing free home delivery. Some small shops also provide credit to customers and retain long-term relationship with them. Customers of small shops rely on personal recommendations by the shop keeper. In case of many of the non- branded items such as cereals, shops serve as a brand. However going forward, this may not prove to be sufficient. If small shops have to sustain competition with the organized retail chains, they will have to constantly improve efficiency and use the power of information technology to improve service. Small shops compete not only with large shops, but also with each other. In the process, no doubt some of the small shops will be shaken out of the business. Those that remain competitive must ensure that they are equipped to do business in the environment of the future. 1.2 Design Goals The Vision Powai Technologies Pvt. Ltd. is a start-up company that proposes to bring out a device (Galla) for implementing ERP systems in small shops in India and a service (galla.com) that will serve these small shops through this device. 3
  4. 4. Galla is an Enterprise Resource Planning (ERP) tool for small shops. It is a scalable piece of hardware. The shop may start with only one device, but may scale up to connect multiple devices together as the business grows. galla.com, the service from Powai Technologies Pvt. Ltd. provides shop keepers with these kinds of services: Services to administer and maintain Galla Services of accounting, demand forecasting, cash-flow management etc. A web-based shopping interface for customers to locate best deals which hook up through the device as additional orders galla.com may be only one of the services. Through Galla, the shopkeeper may interface with other such services from other organizations. Figure 1 shows a schematic of the proposed vision for Galla, galla.com and other services. Shop galla.com service Vendors Customer Interne Gall Gall t a a other services Cashier Small Shopkeeper Fig. 1 A schematic of the proposed system and the role of Galla, the device. This document is restricted to the requirements of Galla, and not other services such as galla.com or the Internet. About this Document This document captures the requirements, the initial use-cases and key quality attribute scenarios expected from the tool of Galla, the device. A complete description of the requirements of galla.com, the service, is beyond the scope of this document. This document refers to galla.com as an external interface of Galla. Galla can perform several functions related to small shop ERP independently, without the need to interface with galla.com. Galla Galla is a hardware device that lets a small shop use the power of information technology to do the routine tasks more efficiently and flexibly. These tasks include billing, cash flow, customer credit tracking, inventory, vendor account management etc. Galla lets the shopkeeper retain his current business practices such as personalized service and credit to customers. 4
  5. 5. Galla also throws open new possibilities by supporting decision making on the basis of experience and information (as opposed to experience alone) and by introduction of modern business practices in traditional shops. It allows the shopkeeper to respond to the changing business environment and provide better service by doing things like up-sale, discounts and sale, frequent customer relationship management, premium pricing, demand forecasting etc. To start with, Galla is being targeted to shops whose primary function is retail sale (e.g. medical shop, grocery store, vegetable shop etc.). At this stage, the product is not being targeted to shops that primarily sell services (e.g. restaurants, laundry etc.) Galla is inexpensive, given the large numbers of small shops in India. Galla fits in the informal culture of the Indian trading community and does not force any formalities on the shopkeeper that he does not desire. It is easy to use, even by a user with limited literacy and limited familiarity with technology. It works in an environment with high dust and heat, limited connectivity and fluctuating power. Galla is flexible and scalable, catering to needs of all kinds of small shops in India. One, lone shopkeeper is able to carry out all activities single-handedly. A shopkeeper may choose to use only a part of the tool to start with. Yet, as business grows, he is able to delegate work to employees, add terminals or connect to external services. As the shopkeeper becomes familiar with the advantages of Galla, he can start using the additional features. The design of Galla makes the transitions easy. The Stakeholders The following are assumed to be the stakeholders in this project: Users o Shop Manager (usually also the owner of the shop, who takes all the business decisions of the shop and may do all the other roles in a small shop). o Cashier (who handles the device to manager all transactions with the customer for either located within the shop or mobile). o Employee (who runs errands and does assigned tasks). o Consultant (who provides the shop services such as hardware maintenance, administration, configuration, training etc.) Development team (members in Powai Technologies Pvt. Ltd.) o Management o Marketing o Project manager o Domain specialist o Human-interaction designer o Software architect o Quality assurance lead o Developers o Quality assurance members 5
  6. 6. 1.2.1 Requirements Functional Requirements 1. Ordering and Billing 1.1. Ordering: Users: Shop Manager, Cashier, Phone operator, Customer. Stakeholders: Domain specialist, Human-interaction designer. The system should enable an order taker to take orders from a customer and prepare a bill for settlement. The system should support at least these types of orders: 1.1.1. Items in Hand: In the first type of order, the customer walks through the shop and collects all items he wishes to purchase himself from the shelf. 1.1.2. Shopping List: In the second type of order, the customer gives a verbal or written order to the shop manager at the counter. An order may come over the phone or over the web. The shop manager or one of the employees then collects all the ordered items from the shelves. In case items are out of stock, the system should warn the order taker at the time of accepting the order. In case the items are ‘nearly’ out of stock, the system should allow the order taker to check if some unbilled customers have not picked up the remaining stock. The system should help the order taker or an employee to pull out all items from the shelves to process such an order. 1.1.3. Advance Order: This may be an order for an item to be delivered to the customer at a later date or time (e.g. birthday cake to be delivered tomorrow) 1.1.4. Recurring Order: An order that customers want repeated at a periodicity for a duration of time (e.g. one litre of milk delivered daily, except on Sundays) 1.2. Up-sale Items: Users: Shop Manager, Cashier, Phone operator, Customer. Stakeholders: Domain specialist, Human-interaction designer. When the order is being taken, the system should support the shop manager to suggest up-sale items (additional suggestions from the shopkeeper). The shop manager may do so from his personal experience. In addition, the system can suggest additional items depending on the other purchases, the season, the customer’s history etc. (for example, if a customer buys birthday candles, the system can suggest birthday cake, party decoration items, soft drinks and other relevant items 1.3. Order Changes: Users: Shop Manager, Cashier, Phone operator, Customer. Stakeholders: Domain specialist, Human-interaction designer. While processing the order, if the employee or the customer wants to change some of the items in the order (e.g. item cancelled, quantity changed, variety changed etc.) the system should allow this. 1.4. Home Delivery: Users: Shop Manager, Cashier, Phone operator, Employee, Customer. Stakeholders: Domain specialist, Human-interaction designer. In case the shop supports home delivery, the system should enable the shop manager 6
  7. 7. to take orders in the shop or on the phone. The system should allow for delayed settlement for such orders. 1.5. Returns management: Users: Shop Manager, Cashier, Phone operator, Customer. Stakeholders: Domain specialist, Human-interaction designer. The system should allow the shop manager to accept allowed returns from customers at the discretion of the shop manager. Returned items may be re-offered for sale, may be marked to be returned to the vendor or marked to be discarded at the discretion of the shop manager. The system should account for returned items according to their status. 2. Customer Settlement 2.1. Settlement: Users: Shop Manager, Cashier and Customer. Stakeholders: Domain specialist, Human-interaction designer. The system should allow the manager to settle a transaction through cash, credit card or if the customer has an account with the shop, on credit. A settlement may be delayed in case of home delivery orders or recurring orders. 2.2. Credit Warning: Users: Shop Manager, Cashier and Customer. Stakeholders: Domain specialist, Human-interaction designer. If a transaction is settled on credit, the manager or cashier should be warned about the current outstanding amount of the customer. The transaction should be settled on credit only on the approval from the manager or the cashier. 2.3. Account Settlement: Users: Shop Manager, Cashier and Customer. Stakeholders: Domain specialist, Human-interaction designer. Manager should be able to accept settlement against a customer account by cash or credit card. 3. Cash Flow Management 3.1. Cash Flow Statement: Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. The system should give a summary of income, expenses, vendor outstanding amounts for items sold, and customer outstanding amounts for items sold and net cash flow for a given period of time in the past. 3.2. Cash Flow Forecasting: Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. The system should compute known and expected future vendor payments, expenses, cash flow, demand forecasts etc. and give a cash flow forecast for a given period of 7
  8. 8. time. Such forecast should clearly differentiate between assured pessimistic expectation, most probable expectations and potential optimistic expectations. 4. Customer Credit Tracking 4.1. Outstanding: Users: Shop Manager, Cashier, and Customer. Stakeholders: Domain specialist, Human-interaction designer. The manager should be able to browse the current outstanding amount of all customers. He should be able to sort the list in various ways, (by date, amount, oldest settlements etc.) 4.2. Statement: Users: Shop Manager, Cashier and Customer. Stakeholders: Domain specialist, Human-interaction designer. For each customer, the manager should be able to print out a statement of bills and payments received for a given period. 5. Preferred Customer Relationship Management 5.1. Preferred Customer Relationship Management: Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer Manager should be able to run his own preferred customer relationship management program or be a partner in an external preferred customer relationship program (such as galla.com service or Ticket Restaurant programme). These are the offers he should be able to make: Discounts / reward points / free services to be given to customers in case they do specified amount of purchases in specified time period, single purchases worth certain amounts or on orders settled against cash, credit or credit cards. Discounts / reward points / free services to be given to specific customers. Redemption rules for reward points if any. 5.2. Control: Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. All parameters could be discretionary to the shop manager. In addition, the shop manager may be able to set these parameters, so that they are not discretionary to the cashier. 6. Inventory: Users: Shop Manager, Cashier and Employee. Stakeholders: Domain specialist, Human-interaction designer. The system should help the manager to take a physical inventory of all stocks. The system should assist the manager by preparing a list of items sorted according to their location in the shop. The system should help the manager to weed out expired items, expiring items or items that have not been sold for a long time. 7. Discounts and Sale: Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. The system should allow the shop manager to run discount sales. Such sales may be run by controlling several permutations and combinations of the following: 8
  9. 9. o Sale for a period of time (one week) o Periodic sales (e.g. sale from 1-4 pm in the afternoons on weekdays) o Sale of all items nearing expiry (particularly, non-returnable items) o Sale of all non-returnable items not sold for ‘long’ time 8. Ordering and Demand Forecasting 8.1. Demand Forecasting: Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Galla should provide basic demand forecasting facilities based on the local trends in the shop for specific items. In addition, the system can suggest additional items the demand for which is likely to pick up in a given period of time depending on the current sale trend (bleblaids), the season (Diwali, so order lamps) or other parameters (vendor introducing new products or giving special commissions). If the shopkeeper chooses to subscribe to external services such as galla.com, Galla should interface with such external services to provide more advanced features offered by those services through http interface. 8.2. Ordering: Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. The system should prepare vendor-wise orders of items that have been sold out, or items whose stock is almost over (i.e. as per the demand forecast for an item, it may not last 1x to 5x number of days it takes for the supplier to supply the goods). The manager should be allowed to vary the factor, or add / delete items to such orders manually. The system should place recurring orders with vendors as well. 8.3. Filing stocks: Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. The system should help the manager and employees to file stocks delivered by the vendor. The system should help the manager to track discrepancies between the items supplied and the vendor bills. 9. Vendor Account Management 9.1. Vendor Bills and Payment: Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. The system should record the bills received from vendors and payments made to vendors. The system should enable the preparation of a statement of bills and payments for the given period of time. 9.2. Returnable / Damaged Goods: Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. The system should enable the manager to return unsold, returnable goods to vendors make adjustments against bills and provide credit notes to vendors. 10. Expenses: Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. The system should record all expenses such as salaries of employees, rent, etc. 9
  10. 10. Elements Not Considered There will be aspects of the system that are important in the final product but the team is unable to consider because the team can spend limited time. For now we are putting such aspects beyond the scope of this project. Here is a list of such aspects we have identified as of now: Functionality of galla.com services, including web-based ordering by the customer Home delivery management Credit issues with vendors (and how commissions vary as a result) Loans / credit from banks and several other issues related to banking Details of shop expenses such as employee salaries, rent etc. 10
  11. 11. 1.2.2 Preliminary Use Cases Cash Flow Forecasting Discounts Demand and Sales Forecasting Includes Includes Start-up / Customer Credit Includes Shut-down Tracking Includes Includes Setting Customer Includes Administratio Loyalty Benefits Shop Manager n Expenses Placing Stock Orders Taking Vendor Includes Returns Shop Includes Employe Vendor Includes Session Vendor Settlement Includes Includes Filing Cashier Stock Create New Accepting Delivery Account and Billing Customer Phone Session Includes Operator Goods Includes Order Returns Includes Change Extends Ordering Create New Includes Account Includes Normal Order Recurring Account Order Settlement Order Settlement Credit Card Cash Credit Credit Cash Delivery Card Person Galla – the Small Shop ERP Product 11
  12. 12. 1. Administration Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: Administration use case is triggered when the system is being set up by the manager or consultant for the first time or when the manager is free and wants to carry out some administrative tasks. Administration functions are to be carried out by the manager personally or by an external consultant in consultations with a manager. Administration includes the following use cases: • Start-up • Stock taking • Setting up customer loyalty benefits • Preparing the orders and demand forecasting • Cash flow forecasting • Setting up discounts and sales • Customer credit tracking • Filing stocks • Expenses • Shut-down 1.1 Start-up Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: Start-up use case is triggered when the shop opens for business. The manager or the cashier physically starts the system by pressing the on switch, identifies and authenticates him. Then the system becomes ready for transactions. The default state of the system is normal order use case. 1.2 Stock Taking Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 6 Stock taking use case is triggered when the manager decides to physically verify the stock in the shop at his discretion. The manager indicates that he wants to take stock. The system prepares a summary of all the stock in the shop and prints it out in a manner that is convenient to take stock (e.g. shelf-wise). It also indicates stocks that are expired, stocks that are nearing expiry and stocks that have remained unsold for a long duration (more than a percentage of shelf life of an item). The manager, with help from other shop employees conducts verification of stock, optionally removes expired items and optionally identifies old or expiring items for potential discount sale or return to vendors. The manager indicates this to the system either during the process 12
  13. 13. of stock verification or after. Similarly, he also indicates any items that are missing. The system eliminates items that are earmarked to be discarded and returned and removes them from the stock. The manager may also add items during stock taking that are available for sale in the shop, but are not recorded in the system. While an item is being added, the system will indicate status of other items such that no duplicate entries occur. 1.3 Setting Customer Loyalty Benefits Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 5.1, 5.2 Setting customer loyalty benefits use case is triggered when the manager decides to set up a customer loyalty program or to change its rules at his discretion. The manager sets up or modifies rules about Discounts / reward points / free services to be given to customers in case they do specified amount of purchases in specified time period, single purchases worth certain amounts or on orders settled against cash, credit or credit cards. Discounts / reward points / free services to be given to specific customers. Redemption rules for reward points if any In addition, the manager may set what items are and are not discretionary to the cashier. 1.4 Demand Forecasting Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 8.1 Demand forecasting use case is triggered when the manager decides to prepare orders and forecast demand in the large at his discretion, from cash flow forecasting use case, the placing orders use case or from the setting up discounts and sales use case. The system provides analytical tools about the current confirmed recurring orders, current stocks of various items and projected future demands on the basis of past trends, seasons, market trends or other parameters. The system will give some parameters to the manager to manipulate (such as conservative estimates, most probable estimates, aggressive estimates, sales and discount parameters, customer loyalty programme parameters etc.). On the basis of this analysis, the system prepares a set of preliminary orders of items per- vendor on the basis of the average time each vendor is known to have taken in the past to supply from the time of placing order. When the use case is triggered in context of a particular vendor, the system will do demand forecasting and order preparation as above only in the context of a specific vendor. The manager may optionally decide to manually edit these orders on the basis of his personal judgement and experience. If the shop has subscribed to an external demand forecasting service, the system may display results from this external service, in addition to predictions from the local service. The manager will use his discretion to decide the final orders. 13
  14. 14. 1.5 Cash Flow Forecasting Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 3.1, 3.2 Cash flow forecasting use case is triggered when the manager decides to do cash flow analysis at his discretion or from the setting up discounts and sales use case. The manager provides a start date and end date from the past and the system displays or prints a statement for the given period. The cash flow statement displays income, expenses, vendor outstanding amounts for items sold, customer outstanding amounts for items sold and net cash flow. The system provides analytical tools to forecast cash flow in future, including confirmed recurring orders, current outstanding from account holding customers, confirmed recurring expenses (salary, rent etc.), as well as projected demands (demand forecasting use case) on the basis of past trends. The system will give some parameters to the manager to manipulate (such as conservative estimates, most probable estimates, aggressive estimates, sales and discount parameters, customer loyalty programme parameters etc.). Thus system takes the input from the demand forecasting feature and translates that into cash flow prediction. 1.6 Setting up Discounts and Sales Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 7 Setting up discounts and sales use case is triggered when the manager decides to set up discounts and sales in his shops at his discretion. The system allows the manager to analyze sales trends over a period of time, including hours of day, days of the week, months of the year, days of maximum sales, days of minimal sales etc. On the basis of these trends, the system can suggest revenue management schemes (e.g. discounts on specific items, discounts at specific times, days of week, periods etc.). The manager may optionally edit some of these schemes, or an earlier saved scheme or set up a completely new scheme. While trying out different schemes, the system will compute demand forecasts and cash flow forecasts for each scheme, without committing to any scheme. The manager may save schemes for use later. 1.7 Customer Credit Tracking Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 4.1, 4.2 Customer credit tracking use case is triggered when the manager decides to analyze the current situation about account holding customers and wants to follow up on the customers whose payments are due. The system will give options to view all account holding customers, customers with overdue amounts, customers with outstanding amounts above a threshold, customers from specific area etc. 14
  15. 15. The system will display customer data and give further options to sort the data according to several parameters (location, outstanding amount, name etc.), to print summary of the views or to print statements for chosen customers. The manager may optionally drill down to see purchase trends of a specific customer or a group of customers. He can further drill down to analyze the details of each order. The manager may at his discretion initiate a call to specific customers regarding their outstanding amount. If the customer agrees to settle, an account settlement use case is triggered. The manager may optionally blacklist a customer from further purchases or write off overdue amounts of certain customers. 1.8 Filing Stocks Users: Shop Manager, Consultant. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 8.3 Filing stocks user case is triggered at the discretion of the manager when goods from vendors arrive and after the accepting delivery and billing use case. Although this is an administration function, the manager may solicit help of other shop employees in this use case and delegate some of the responsibilities to other shop employees. If delegated, it should not be possible to go to other administrative modules from this use case. The stock taker unpacks, inspects and counts the goods and enters them in the system and optionally tracks them with an identifier such as a bar code. The stock taker may optionally indicate where the item is to be kept in the shop. The system may help him in this by providing default values based on the past experience of similar items. The system shows any discrepancies at the end of entering items from the order and the delivery challan. The stock filer approves these discrepancies, and through the manager informs the vendor about them. These are later used during vendor settlement use case. 1.9 Expenses Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 10 Expenses user case is triggered at the discretion of the manager when any shop related expenses happen. The manager indicates the type of expense (rent, salary, electricity, phone bill etc.), the amount and the date. The system records the expense against the shop. 1.10 Shut-down Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: Shut-down use case is triggered when the shop closes for business and no other administrative functions need to be performed. The manager or the cashier physically shuts the system down by pressing the off switch. 15
  16. 16. 2. Vendor Session Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 9 Vendor session use case starts when a vendor walks in the shop or when he calls up on the phone, or when the manager calls up the vendor to place an order at his discretion. This session includes following use cases: Create new vendor account Placing orders Accepting delivery and billing Vendor returns Vendor settlement 2.1 Create New Vendor Account Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: Create new vendor account use case starts at the discretion of the manager at any time during the vendor session use case. The manager asks for the vendor for details such as name, address, phone number, typical items supplied, lead time for procuring items, commissions on each item, payment terms and enters those in the system. The system generates vendor identification. 2.2 Placing Orders Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 8.2 Placing orders use case starts at the discretion of the manager at any time during the vendor session use case. Typically, it may be triggered from the demand forecasting use case or from the accepting delivery and billing use case. The manager reviews and edits an order created during demand forecasting for a particular vendor. Alternately, he may choose to create a completely new order. The manager places the order either in a printed form, in a vendor-supplied format or orally. The manager updates the finalised order in the system if there are any changes. Based on past experience with the vendor or entries in the vendor account, the system updates the probable date of delivery. The manager checks the probable date of delivery back with the vendor and may optionally update this in the system. If the order contains new items, the system automatically prompts the manger to enter these items in the system. 2.3 Accepting delivery and billing Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 9.1 16
  17. 17. Accepting delivery and billing use case starts during the vendor session use case when the vendor delivers goods or an invoice. The system displays corresponding order for which the delivery is to be made. If no order was entered, placing orders use case is triggered at this point to create a new order. The manager checks if the items in the order match the items in the delivery challan or otherwise updates the order. At this point, the stock filing use case may be triggered. If the vendor has supplied an invoice, the manager inputs the receipt of the invoice in the system along with one or more delivery challans against which the bills were received. The system generates a statement that indicates if the stock filing use case has been completed for this delivery challan and goods have been verified or not. The manager may optionally take a print of the statement. If there are discrepancies in the amount between corresponding delivery challans and invoice amount, the system indicates this to the manager in the statement. The manager may choose to inform this discrepancy to the vendor at this stage at this discretion. 2.4 Vendor returns Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 9.2 Vendor returns use case starts at the discretion of the manager at any time during the vendor session use case if any items are due to be returned to the vendor. The manager shows or describes the returnable items to the vendor. The vendor accepts or rejects these items. If the vendor rejects a returnable item, the manager at his discretion decides to move the item back for sale or writes off the item and indicates this to the system. If the vendor accepts a returnable item, the manager indicates this to the system. After all returnable items have thus been processed, the manager optionally prints a memo of all returnable items and provides a credit note to the vendor. Such credit notes are entered as negative transactions in the vendors account and are considered during vendor settlement use case. 2.5 Vendor settlement Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 9 Vendor settlement use case triggers when the manager at his discretion decides to carry out a vendor settlement during a vendor session use case. The system displays a statement of the amount due for the vendor, considering bills, discrepancies between delivery challan and the invoice (uncovered during the accepting delivery and billing use case), returns (vendor returns use case) and discrepancies between the delivery challan and the items delivered (uncovered during the filing stocks use case). The system indicates separately the amount over due beyond the credit limit prescribed in the vendor’s account from the date of the invoice and delivery. 17
  18. 18. At his discretion, the manager decides to pay the vendor a sum of money and indicates the payment details to the system (cash, credit card, cheque etc.) At his discretion, the manager may input an ‘adjustment amount’ to adjust for any accounting discrepancies between the system and the vendor. 3. Customer Session Users: Shop Manager, Cashier, Employee. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 1, 2 Customer session starts when a customer walks in the shop or when he calls up on the phone. This session includes following use cases: Ordering Order Settlement Creating New Account Account Settlement Goods Returns 3.1 Ordering Users: Shop Manager, Cashier, Phone operator, Employee, Customer. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 1 Note: Order Settlement is an abstract generalization. Ordering use cases are of two types – normal order and recurring order. 3.1.1 Normal Order Users: Shop Manager, Cashier, Employee. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 1.1.1, 1.1.2, 1.1.3, 1.2, 1.4 Normal order use case begins in one of the following cases: The customer walks in the shop and picks out items he wishes to buy The customer walks in the shop and orders items he wishes to buy either verbally or through a written order The customer calls the shop by phone and orders the desired goods. The customer places an order over a web-based service such as galla.com. An order may be taken by either the manager, or the phone operator or the cashier (called order taker). If the order comes over the phone, the order taker asks the customer for the phone number. If there is a home address tied to the phone number, the system displays the same and the order taker verifies it and if necessary updates it. The order taker takes the written or verbal orders or items selected by the customer and feeds items into the system. If the items are bar coded and if the customer has already picked them out from the shelf, the order taker may scan these to enter them into the system. 18
  19. 19. As each item is entered, the system checks it against the saleable inventory and warns the order taker about items out of stock or nearly out of stock. The order taker may ignore these warnings if the customer has already picked out the items from the shelf. After all items in the customer’s order are entered, the system prompts for any up-sale items along with their price and other relevant details. These items may be related to the items in the current order, current season or any other items generated by a data mining algorithm. The order taker may offer the customer from among these or any other up-sale items by his experience. If the customer agrees, these items are also added to the order. After all items have been entered, the order taker applies (on suggestion from the system and / or at his discretion) any applicable discounts and informs the customer about the total amount due and asks the customer which of three payment options he would prefer for order settlement: Cash payment Credit card payment Credit settlement. This option is available only to customers who have an account with the shop The customer informs about his choice. The order taker inputs the choice in the system. If the customer chose credit, the credit order settlement use case is triggered at this stage. If the order taker does not approve credit order settlement, the customer has option to use other payment mechanisms. If the customer does not choose any other option, the order is treated as cancelled and the order taker returns the goods to the rack if necessary. The order taker gives the customer the option of delivering the order in shop or at the customer’s home. If the customer chooses home and the customer was ordering in the shop, the order taker asks for home address and phone number or, if the customer has an account, customer account number, and inputs it in the system. The order taker gives the customer the option of delivering the order immediately or at a later date and time (advance order). The order taker records the customer’s option and at his discretion may change the date and time depend on the availability of stocks, shop timings and availability of delivery boys. Even in case of an immediate order, while the order is being fulfilled, the order taker may optionally put the current order on hold and take order from another customer or do other things. If the order is on the phone, the order taker may hang up the phone at this stage and may offer to call the customer back in case the customer was paying by credit card. The order taker optionally prints a receipt of the order. Unless the customer has already done so, the order taker or any other employee processes the order (removes the items from the shelf, packs them etc.). If this was to be a delayed order, when the time of order processing comes, the system reminds the order taker and displays items in the order. Order processing may be done by another employee in parallel with the order being taken by the order taker. If there are any changes necessary during the order processing, order change extension use case is triggered. Once the order is processed, it is ready for delivery. If the customer chose credit card for order settlement, and if the order was on the phone, the order taker calls the customer back at this stage. 19
  20. 20. If the customer chose chooses credit card for order settlement, the credit card order settlement use case is triggered. If the credit card company does not approve the settlement, the customer has option to use other payment mechanisms. If the customer does not choose any other option, the order is treated as cancelled and the order taker returns the goods to the shelf. At this stage, if the customer selected home delivery, the items are sent to the customer. Else, the items are delivered to the customer in the shop. If the credit card was used as the settlement mechanism, and the delivery was in the shop, the order taker takes a signature of the customer on the charge slip. If the delivery was at home, the delivery person takes a signature of the customer on the charge slip and returns the charge slip to the order taker. If the customer chose cash order settlement option, the cash order settlement use case is triggered. If the customer is unable to pay cash and if the delivery is in the shop, the customer has option to use other payment mechanisms. If the customer does not choose a valid settlement option, the order is treated as cancelled and the order taker returns the goods to the shelf. 3.1.2 Recurring Order Users: Shop Manager, Cashier, Employee. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 1.1.4 Recurring order use case works like a normal order in all respects except that while each item is being ordered, the recurrence of the item is recorded. Such recurrence may be daily, weekly or monthly. 3.1.3 Order Change Extends Ordering Users: Shop Manager, Cashier, Employee. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 1.3 Order change extension use case is triggered during the normal order use case or recurring order use case if during the order fulfilment, any items are added or changed from the order. If a particular part of the order cannot be fulfilled, (because it is found to be out of stock or damaged) the order taker opens the order and deletes the item. If the customer asks for additional items during order fulfilment, those are added to the order. If the order was on phone, the order taker optionally communicates with the customer and changes the order as per his instructions. After all changes are made to the order, the order taker optionally prints a modified order receipt. If credit was chosen as the settlement option, the earlier credit transaction is rolled back and new credit order settlement use case is carried out. 3.2 Order Settlement Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 2 Note: Order Settlement is an abstract generalization. 20
  21. 21. Order settlement use case is triggered when an order is ready for settlement during normal order use case. An order may be settled by either cash, credit card or credit. 3.2.1 Credit Order Settlement Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 2.1, 2.2 Credit order settlement use case is triggered when a customer chooses to settle an order by credit and after the order is entered by the order taker during normal order use case, recurring order use case or during order change extension use case. The customer provides the necessary identification for authorization by order taker (cashier or manager). The order taker inputs the identification into the system. The system informs the order taker about the current outstanding amount against the customer. At his discretion, the order taker authorizes the settlement or does not authorize it. If he authorizes it, the order taker records the settlement in the system and optionally prints a statement of the customer’s account since the last settlement. 3.2.2 Credit Card Order Settlement Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 2.1 Credit card order settlement use case is triggered during the normal order use case if the customer opts to settle the order by credit card. If the customer placed the order in the shop in person, the credit card order settlement use case is triggered after the order is processed and any order changes are made in the order change extension use case. If the customer placed the order on the phone, the credit card order settlement use case is triggered after the order is processed, any order changes are made in the order change extension use case and the order taker has called the customer back to get the credit card details. The customer provides the credit card details. The order taker enters the credit card details on the system. Optionally, the system dials out to the credit card company number and provides transaction information. The credit card company provides authorization code. The system prints out a charge slip. 3.2.3 Cash Order Settlement Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 2.1 Cash order settlement use case is triggered during the normal order use case if the customer opts to settle the order by cash, after the order is processed. Any order changes are made in the order change extension use case and the items are delivered to the customer (either in the shop or at home). The customer provides the necessary cash. If the delivery is in the shop, the order taker accepts the cash and optionally enters the cash details (number of notes, coins etc.) in the system. If he does so, the system displays the amount of change that needs to be returned. The order taker returns the appropriate change. The order taker indicates so to the system that the cash transaction was completed. 21
  22. 22. If the delivery is at home, the delivery person accepts the cash and return any change. When the delivery person comes to the shop, the he hands the cash over to the order taker. The order taker indicates so to the system that the cash transaction was completed. 3.3 Create New Account Users: Shop Manager. Stakeholders: Domain specialist, Human-interaction designer. Requirements: Create new account use case starts at the discretion of the manager at any time during the customer session use case if the manager offers the customer to open an account and the customer accepts. The manager asks for the customer for details such as name, address, phone number and enters those in the system. The system generates a customer identification. The manager hands over this identification to the customer. 3.4 Account Settlement Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 2.3 Note: Account Settlement is an abstract generalization. Account settlement use case is triggered at any time when a customer shows willingness to settle an account. This may happen when the customer visits the shop or when the manager calls up the customer reminding him of his outstanding amount during the customer credit tracking use case. An order may be settled by either cash or credit card. 3.4.1 Cash Account Settlement Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 2.3 Cash account settlement use case is triggered if the customer chooses to settle the account by cash. This may happen when the customer visits the shop or when the manager calls up the customer reminding him of his outstanding amount during the customer credit tracking use case. The manager or cashier informs the customer of the outstanding amount and asks him how much amount he is willing to settle. The customer informs about full or partial settlement. If the customer is in the shop, the customer provides the necessary cash immediately. The manager or cashier accepts the cash and enters the amount to be settled against the customer in the system. Optionally he also enters the cash details (number of notes, coins etc.) in the system. If he does so, the system displays the amount of change that needs to be returned, if any. The manager or cashier returns the appropriate change and indicates so to the system that the cash transaction was completed. If the customer is at home, the manager sends an employee to collect the cash from the customer at home. When the employee returns with the cash, the manager accepts the cash and enters the amount to be settled against the customer in the system. 22
  23. 23. 3.4.2 Credit Card Account Settlement Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 2.3 Credit card account settlement use case is triggered if the customer chooses to settle the account by credit card. This may happen when the customer visits the shop or when the manager calls up the customer reminding him of his outstanding amount during the customer credit tracking use case. The manager or cashier informs the customer of the outstanding amount and asks him how much amount he is willing to settle. The customer informs about full or partial settlement. The customer provides the credit card details. The manager or cashier enters the credit card details on the system. Optionally, the system dials out to the credit card company number and provides transaction information. The credit card company provides authorization code. The system prints out a charge slip. If the customer is in the shop, the customer signs the charge slip immediately. If the customer is at home, the manager or cashier sends an employee to collect the signature from the customer at home. The manager or cashier accepts the charge slip and enters the amount to be settled against the customer in the system. 3.5 Goods Returns Users: Shop Manager, Cashier. Stakeholders: Domain specialist, Human-interaction designer. Requirements: 1.5 Goods returns use case starts when a customer brings a returnable item in a returnable condition back to the shop for the purpose of returning it. The customer presents the returnable item to the order taker. The order taker inspects the items and ensures that they are in returnable condition as per the policies of the shop. The order taker then asks the customer for proof of purchase (the receipt). He enters the receipt number in the system to look up the transaction. If the customer does not provide the receipt, the order taker may use at his discretion the customer name, date of transaction or name of the item sold to look up the order in the system. Once he finds the transaction, he re- verifies that the item is returnable (i.e. the date of transaction is within acceptable range, if the transaction was completed through credit cards etc.) and marks the particular item as returned in the system. The system rolls back the item in the order and gives these choices to the order taker: Return cash amount If the cashier or manager chooses this option, he returns the cash amount to the customer – he may particularly do so if the original order was settled by cash. Give a credit token If the cashier or the manager chooses this option, he prints a token that the customer can redeem against future shopping as cash for some duration of time that the order taker optionally decides. 23
  24. 24. Give credit in account This choice appears if the customer has an account with the shop. If the cashier or the manager chooses this option, he adjusts the amount against the account of the customer – he may particularly do so if the original order was settled by credit. 24
  25. 25. Chapter2. Architecture 2.1 Overall Architecture The layered view of the overall Architecture is as shown: A+B+C DB Management System UI Mgr OS Devices A = Customer Management B = Vendor Management C = Administrative Activities Fig 2.1 Layered architecture diagram For customers requiring single terminal, all the layers of the above architecture diagram will be packaged into a single terminal. In the case that multiple terminals are required, there will be a master terminal which has the database server running on it. There can be one or more terminals where the backup database will reside and any one of these terminals can take on the role of master terminal in case the master terminal fails. The other terminals can connect to the database server (over LAN) residing at the master. But these terminals will have the processing capability and the same application layer as is present in the master terminal is present on all of these. These terminals can also have some cache of part of the database, so that they can operate standalone when not on network. There could as well be other dumb terminals which can connect to the master terminal for all the activities. These various kinds of terminals are shown in the figure below. Note that all these terminals are connected over a LAN which could be wireless or wired. A + B + C A + B + C U IM g r U IM g r DBM S DBM S OS OS D e v ic e s D e vic e s M a s te r Backup A + B + C A + B + C U IM g r U IM g r Ca che Cache OS OS D e v ic e s D e v ic e s T e r m in a l w it h o u t D B M S T e r m in a l w it h o u t D B M S Fig 2.2 Layered architecture over a LAN The overall functionality can divided in following subsets:: a) Billing Customer + Customer Goods Returns Management + Transactions Summary b) Vendor Accounts Maintenance + Expense Management + Vendor Returns Management + Vendor Transactions Summary c) Inventory tracking (database of all items up to date) + Order Management + Stock Filing + Stock Checking 25
  26. 26. d) Maintaining Customer Accounts e) Customer Relationship Management (CRM) f) Forecasting + Predictions The software can be delivered to the client with one or more of the above functional aspects provided that the dependences shown in the following dependence graph are satisfied: a b d c e f Fig 2.3 Dependence Graph 2.2 Data Model The following databases will be required for the system to carry out the requirements detailed in the software requirements specification. In the Entity Relation Diagram, CO refers to Customer Order, and VI refers to Vendor Invoice. 26
  27. 27. Fig 2.4 ER Diagram In the following we list the attributes of each of the tables, their primary keys (underlined) and the foreign keys (if any) 1. Item 1. Item-Code 2. Description 3. IsReturnable 4. Type (loose/packed – if loose, it will have rate/unit, else it will have price) 2. Transient Item Info 1. Item-Code (foreign key) 2. Category-Code 3. Cost (per unit item) 4. Expiry-date 5. Vendor-id 27
  28. 28. 6. Commission 7. ReturnDuration (Period until which the goods can be returned) 3. Transient Info 1. Item-Code 2. Category-Code 3. Quantity (the remaining quantity) 4. Safe-Quantity (this is the derived attribute and the system might modify this attribute periodically. This is used to indicate whether the item is nearly out of stock) 4. Vendor Information 1. Vendor-Id 2. Name 3. Address 4. Phone 5. Supplies Items 1. Vendor-Id (foreign key) 2. Item-Code (foreign key) 3. Category-Code (foreign key) 6. Vendor Payment 1. Vendor-Id (foreign key) 2. Payment-Number 3. Date 4. Amount 5. Payment-Mode (this will be a finite domain attribute – {cash, credit-card, credit}) 7. Purchase Order 1. Order-Id 2. Vendor-Id (foreign key) 3. Date 4. IsPending 5. Delivery Date 8. Purchase Details 1. Order-Id (foreign key) 2. Item-Code (foreign key) 3. Category-Code (foreign key) 4. Quantity (for each of the ordered item) 9. Delivery Discrepancy 1. Discrepancy-Id 2. Order-Id (foreign key) 3. Item-Code (foreign key) 4. Category-Code (foreign key) 5. Quantity 10. Customer Information 1. Customer-Id 2. Name 3. Address 4. Phone 5. Points (used for giving the discounts according to rules in table Loyalty Rules) 11. Customer Order (CO) 1. Order-Id 2. Customer-Id (foreign key) 3. Date 4. IsPending 28
  29. 29. 5. Cost 6. Tax 7. Payment-Mode (enum data {cash, credit, credit card}) 12. CO Contents 1. Order-Id (foreign key) 2. Item-Code (foreign key) 3. Category-Code (foreign key) 13. Customer Payment 1. Payment-Id 2. Order-Id (may be null, in case payment is not associated with single order) 3. Customer-Id (foreign key) 4. Date 14. Loyalty Rules 1. Min-Points 2. Max-Points 3. Discount-Percentage 15. Discount 1. Item-Code (foreign key) 2. Category-Code (foreign key) 3. Discount-Percentage 4. Min-Quantity 16. Reward Points 1. Min-Purchase 2. Max-Purchase 3. Points 2.3 Object Oriented Design 2.3.1 CRC Cards The CRC cards for the various classes are as follows: Class CustomerTransactionsScreen Responsibilities Collaborators Provide a navigation interface for differentCustomerOrderScreen screens DisplayWidgets CustomerOrderSettlementScreen Create the different screens navigable fromCustomerGoodsReturnScreen this screen CustomerPaymentScreen NewCustomerScreen CustomerOrderSearchScreen PendingCustomerOrderScreen CustomerCreditSumaryScreen Class CustomerOrderScreen 29
  30. 30. Responsibilities Collaborators DisplayWidgets CustomerOrder Pass on the values for Customer details to CustomerOrderSettlementScreen CustomerOrder object Pass on the details(or just item id) of each NewCustomerScreen item entered to CustomerOrder object as each item is added Pass on the order status to the CustomerOrder object Create the CustomerOrderSettlement object Customer Display the Order Settlement Screen when done with the order Class CustomerOrder Responsibilities Collaborators Add an item to the list and check the consistency (in stock?) Get Item Details from item identifier Delete Item from the list Add the customer identifier Get Customer Details from the customer identifier Get Customer Details from the customer name Compute tax Compute total amount Check if credit can be given to the customer Set the payment mode Set/Reset the pending order status Compute discount Commit the order Class CreditCardSettlementScreen Responsibilities Collaborators 30
  31. 31. Responsibilities Collaborators Pass on the credit card information to the CustomerOrder CreditCardHandler object Send the message to perform the credit card transaction to CreditCardTransaction object Prompt the status of credit card transaction CreditCardHandler Class CreditCardHandler Responsibilities Collaborators Contact the credit card transaction gateway Perform the credit card transaction for the indicated amount Set the status of the transaction Class CustomerPaymentScreen Responsibilities Collaborators Display Widgets CustomerPayment Pass on the credit card information to theCreditCardHandler CreditCardHandler object Prompt the status of credit card transaction, if credit card opted for Class CustomerPayment Responsibilities Collaborators Set the customer identifier Set the amount paid Set the mode of paymennt Commit the Payment Class GoodsReturnScreen Responsibilities Collaborators Display Widgets CustomerGoodsReturn Pass on the Order Identifier against which the returns are made to CustomerGoodsReturn object 31
  32. 32. Responsibilities Collaborators For each item entered check from the CustomerGoodsReturn object whether it is valid for return Pass on the mode of return payment to the CustomerGoodsReturn object Class GoodsReturn Responsibilities Collaborators Set the order identifier Add return item to the list Check if added item is consistent Compute total return Set the type of mode of payment Commit the goods returned Class NewCustomerScreen Responsibilities Collaborators Display Widgets Customer Pass on the details of the customer to the Customer object Class Customer Responsibilities Collaborators Set the detials of Customer Commit the details The CRC cards for the Vendor activities are as follows: Class VendorSummaryScreen Responsibilities Collaborators Display Widgets VendorSumary Display the list of all vendors and optionallyVendorStatementScreen vendor details For any selected vendor show the list of itemsVendorStatement supplied by him in a collapsible fashion / new screen Create the VendorStatementScreen NewVendorScreen 32
  33. 33. Responsibilities Collaborators Create the NewVendorScreen Vendor Create the Vendor object PendingVendorOrderScreen Cerate the VendorStatement object PendingVendorOrder Class VendorSummary Responsibilities Collaborators Get the set of all registered vendors For each vendor get the set of items supplied by that vendor Class VendorOrderScreen Responsibilities Collaborators DisplayWidgets VendorOrder Pass on vendor details to VendorOrder object Pass on each item added to the VendorOrder object Class VendorOrder Responsibilities Collaborators Set Vendor details Check each item added for consistency Compute total amount Compute taxes Commit the vendor order details Class VendorGoodsReturnScreen Responsibilities Collaborators Display Widgets VendorGoodsReturn Pass on the vendor order identifier to the VendorGoodsReturn object Pass on each of the items entered to VendorGoodsReturn object for validity of return Pass on the amount and mode of payment to VendorGoodsReturn object 33
  34. 34. Class VendorGoodsReturn Responsibilities Collaborators Set the vendor order identifier Set the amount and mode of payment Check each item for validity of return Compute total amount Commit the vendor goods return details Class VendorPaymentScreen Responsibilities Collaborators Display Widgets VendorPayment Pass on the amount and mode of payment to the VendorPayment object Class VendorPayment Responsibilities Collaborators Set the vendor identifier Set the amount paid Set the mode of payment Commit the details Class NewVendorScreen Responsibilities Collaborators Display Widgets Vendor Pass on the details of Vendor to the Vendor object Pass on each item entered to the Vendor object Class Vendor Responsibilities Collaborators Set the detials of Vendor Add an item supplied by vendor Commit the vendor details 34
  35. 35. Class VendorStatementScreen Responsibilities Collaborators Display Widgets VendorStatement Pass on the VendorId to the VendorStatementVendorOrderScreen object Create the VendorOrderScreen VendorOrder Create the VendorGoodsReturnScreen VendorGoodsReturnScreen Create the VendorOrder object VendorGoodsReturn Create the VendorGoodsReturn object VendorPaymentScreen Create the VendorPaymentScreen VendorPayment Create the VendorPayment object Class VendorStatement Responsibilities Collaborators Set the VendorId Get data about all the vendor orders from the selected vendor Get data about all the payments made to the selected vendor Following are the CRC cards for Administrative activities: Class AuthenticationScreen Responsibilities Collaborators DisplayWidgets Authentication Pass on the username and password to theLoggedUser Authentication object Display error message in case of failure Pass on the username and role of that user to the LoggedUser object Class Authentication Responsibilities Collaborators Set the username Set the password Check whether the pair (username, pasword) is valid 35
  36. 36. Responsibilities Collaborators Get the role associated with username Class LoggedUser Responsibilities Collaborators Set the logged username Set the logged user role Class AdministrativeActivitiesScreen Responsibilities Collaborators Provide a navigation interface for differentStockSummaryScreen screens Display Widgets ExpensesScreen SalesTrendScreen DemandForecastScreen CashFlowScreen LoyaltyProgramsSettingScreen DiscountsSettingsScreen RewardPointSettingsScreen Class StockSummaryScreen Responsibilities Collaborators Display the list of items with their existingStockSummary quantities Display Widgets Class StockSummary Responsibilities Collaborators Get the list of items with their respective existing quantities Provide an iterator for the list Class ExpensesScreen Responsibilities Collaborators Display Widgets Expenses Provide input combos for entering date range 36
  37. 37. Responsibilities Collaborators Display all the expense items between the date range mentioned in this screen Class Expenses Responsibilities Collaborators Set the start and end dates Get the vendor expenses and other expenses from the database Provide an iterator for the expenses list Class CustomerCreditSummaryScreen Responsibilities Collaborators Display Widgets CustomerCreditSummary List for each customer who has outstanding credit, the credit amount and the earliest date of outstanding credit Class CustomerCreditSummary Responsibilities Collaborators Get the list of customers that have outstanding credit from the database Provide an iterator for the list Class PendingVendorOrderScreen Responsibilities Collaborators Display Widgets PendingVendorOrder VendorOrderScreen VendorOrder Class PendingVendorOrder Responsibilities Collaborators Get the list of pending vendor orders from the database Provide an iterator for the list 37
  38. 38. Class PendingCustomerOrderScreen Responsibilities Collaborators Display Widgets PendingCustomerOrder CustomerOrderScreen CustomerOrder Class PendingCustomerOrder Responsibilities Collaborators Get the list of pending customer orders from the database Provide an iterator for the list Class SalesTrendScreen Responsibilities Collaborators Send the parameters on which trends are to beSalesTrendAnalzer computed to the AnalyzerAdapter object Ask the analyzer to compute the results Get and display the results Class SalesTrendAnalyzer Responsibilities Collaborators Receive the data to be processed Process the data Send the results in standard format Class DemandForecastScreen Responsibilities Collaborators Send the parameters on which trends are to beAnalyzerAdapter computed to the AnalyzerAdapter object Ask the analyzer to compute the results Get and display the results Class AnalyzerAdapter Responsibilities Collaborators Set the data to be sent SalesTrendAnalyzer 38
  39. 39. Responsibilities Collaborators Send the data in standard format DemandForecastAnalyzer Receive the results in standard format RemoteAnalyzer Class DemandForecastAnalyzer Responsibilities Collaborators Receive the data to be processed Process the data Send the results in standard format Class RemoteAnalyzer Responsibilities Collaborators Read the remote address + port Establish connection to remote service Receive the data to be processed Send the data to the remote processor Convert the results in standard format 39
  40. 40. 2.3.2 Interaction Diagrams Fig 2.4 Interaction diagram for Customer Order The Interaction diagram for Customer Order is as shown above. The interaction diagram for Goods Return is shown below: Fig 2.5 Interaction diagram for Good Return 40
  41. 41. The interaction diagram for add customer is as shown below: Fig 2.6 Interaction diagram for adding Customer Screen The interaction diagram for vendor summary and vendor statement is as shown below: Fig 2.7 Interaction Diagram for Vendor Summary and Vendor Statement Screen The interaction diagram for vendor order is as shown below: 41
  42. 42. Fig 2.8 Interaction diagram for Vendor Order Screen The interaction diagram for sales trends is as shown below: Fig 2.9 Interaction Diagram for Sales Trend Screen 42
  43. 43. 2.4 Package Structure We will now classify the classes that are required to carry out the functionality of each of the subsets (a to f) that we had identified earlier a) Billing Customer + Customer Goods Returns Management + Transactions Summary • CustomerOrderScreen • CustomerOrder • CreditCardSettlementScreen • CreditCardHandler • GoodsReturnScreen • GoodsReturn • PendingCustomerOrderScreen • PendingCustomerOrder b) Vendor Accounts Maintenance + Expense Management + Vendor Returns Management + Vendor Transactions Summary • VendorSumaryScreen • VendorSumary • VendorStatementScreen • VendorStatement • VendorOrderScreen • VendorOrder • VendorGoodsReturnScreen • VendorGoodsReturn • VendorPaymentScreen • VendorPayment • NewVendorScreen • Vendor • ExpensesScreen • Expenses • PendingVendorOrderScreen • PendingVendorOrder c) Inventory tracking (database of all items up to date) + Order Management + Stock Filing + Stock Checking • StockSummaryScreen • StockSummary • StockFilingScreen • StockFiling d) Maintaining Customer Accounts • NewCustomerScreen • Customer e) Customer Relationship Management (CRM) • CustomerCreditSumaryScreen • CustomerCreditSummary • LoyaltyProgramsSettingScreen • DiscountsSettingsScreen • RewardPointSettingsScreen f) Administration + Forecasting + Predictions • Authentication • AuthenticationScreen • LoggedUser • SalesTrendScreen 43
  44. 44. • SalesTrendAnalyzer • DemandForecastScreen • DemandForecastAnalyzer • AnalyzerAdapter • RemoteAnalyzer 2.5 User Interface Diagrams Admin Screens o Admin screen • Start-up o Please Authenticate Yourself screen • Stock taking o Stock Summary screen / print Stock Item screen • Setting up customer loyalty benefits o Loyalty Program Scheme Settings screen o Special Customer Settings screen o Rewards Points Rules screen New Reward Points Rule o Reward Points Redemption Rules screen New Reward Points Redemption rule screen o Discounts screen New Discount screen • Preparing the orders and demand forecasting + Cash flow forecasting + Setting up discounts and sales o Sales Trends screen / print Select Options screen o Demand Forecast screen / print Set Forecast Parameters screen o Cash Flow Forecast screen / print (same Set Forecast Parameters screen as demand forecast) o Discounts Schemes Summary screen / print New Discount Scheme screen / print o Pending Orders Summary screen / print Order screen / print (has options for each item: Order quantity, frequency, Delivery challan quantity, Verified filed quantity, Damage / discrepancy quantity, Sold, Unsold, Returned, Bill quantity, Bill amount, Contested amount) tracks to DC no/date, bill no/date, allows multiple 44
  45. 45. DCs, bills, POs to be linked to each other. Think about this, it is not easy to visualize as one view!!!!!!!! • Customer credit tracking o Customer Group Credit Summary screen Create New Group screen Customer Group Trends screen Customer Credit Summary screen • Customer Bill screen • Customer Trend screen • Filing stocks o Filing Stock Item screen Bar Code print • Expenses o Enter Expense Voucher screen Set Expense as Recurring screen • Shut-down o Shut-down Confirmation screen Vendor Session Screens o Vendors Summary screen Add / Edit Vendor screen • Add / Edit Vendor Item screen Vendor Statement screen • Vendor Payment screen (same Order screen / print in preparing orders use case) Create new vendor account o (same Add / Edit Vendor screen as above) Placing orders (same Order screen / print in preparing orders use case) Accepting delivery and billing (same Order screen / print in preparing orders use case) Vendor returns (same Order screen / print in preparing orders use case) Vendor settlement (same as Vendor Payment screen) 45
  46. 46. Customer Session Screens Ordering o Order / Bill screen Up-sale Items screen Recurring Order screen Credit Card Transaction screen Credit Transaction screen Add / Edit Customer screen Order Settlement (same Order / Bill screen as above) Creating New Account (same Add / Edit Customer screen as above) Account Settlement o Customer Statement screen (same Order / Bill screen as above) Goods Returns o Search Order / Bill screen (same Order / Bill screen as above) All the screens to be designed are listed below o Admin screen o Please Authenticate Yourself screen o Stock Summary screen / print Stock Item screen o Loyalty Program Scheme Settings screen o Special Customer Settings screen o Rewards Points Rules screen New Reward Points Rule o Reward Points Redemption Rules screen New Reward Points Redemption rule screen o Discounts screen New Discount screen o Sales Trends screen / print Select Options screen o Demand Forecast screen / print 46
  47. 47. Set Forecast Parameters screen o Cash Flow Forecast screen / print (same Set Forecast Parameters screen as demand forecast) o Discounts Schemes Summary screen / print New Discount Scheme screen / print o Pending Orders Summary screen / print Order screen / print (has options for each item: Order quantity, frequency, Delivery challan quantity, Verified filed quantity, Damage / discrepancy quantity, Sold, Unsold, Returned, Bill quantity, Bill amount, Contested amount) tracks to DC no/date, bill no/date, allows multiple DCs, bills, POs to be linked to each other. Think about this, it is not easy to visualize as one view!!!!!!!! o Customer Group Credit Summary screen Create New Group screen Customer Group Trends screen Customer Credit Summary screen • Customer Bill screen • Customer Trend screen o Filing Stock Item screen Bar Code print o Enter Expense Voucher screen Set Expense as Recurring screen o Shut-down Confirmation screen o Vendors Summary screen Add / Edit Vendor screen • Add / Edit Vendor Item screen Vendor Statement screen • Vendor Payment screen (same Order screen / print in preparing orders use case) o (same Add / Edit Vendor screen as above) (same Order screen / print in preparing orders use case) (same Order screen / print in preparing orders use case) (same Order screen / print in preparing orders use case) (same as Vendor Payment screen) o Order / Bill screen Up-sale Items screen Recurring Order screen 47
  48. 48. Credit Card Transaction screen Credit Transaction screen Add / Edit Customer screen (same Order / Bill screen as above) (same Add / Edit Customer screen as above) o Customer Statement screen (same Order / Bill screen as above) o Search Order / Bill screen (same Order / Bill screen as above) o Enter Expense Voucher screen Set Expense as Recurring screen o Shut-down Confirmation screen 48
  49. 49. Sales Trends Authentication screen screen Trends and Forecasts screen Demand Forecast screen Admin Cash Flow screen Forecast screen Stock Summary Expense Pending Cust. Credit Settings screen Voucher screen Orders screen Summ. screen screen Loyalty Prog. Vend. Order Cust. Statement Settings screen screen screen Sp. Cust. Settings screen Reward Pts. Rules screen Redemption Rules screen Discount Schemes Vendors Settings screen Add / Edit Vend. screen Summ. screen Vend. Statement screen Add / Edit Vend. Item screen Vend. Payment screen From any screen Search Order / Bill screen Order / Bill Filing Stock screen screen Up-sale Items Recurring Credit Card Up-sale Items Credit Trx Add / Edit screen Order screen Trx screen screen screen Cust. screen Fig 2.10 UI Diagram 49
  50. 50. Chapter3 Test Case and QA 3.1 Test Cases 1. Test case for Goods return Input for ‘Goods return test’ is Customer OrderID, Items, Units, Numbers, and Amount. When goods are returned we have variants of test cases in terms of 1. If goods are returned with no substituted item for the same and money is repaid back to the customer. Secondly, if items are returned, then returned goods are substituted by another item and difference amount is returned. So, outputs are either money or difference amount and substituted item. Entries in this colour are provided by tester as an input for the test. Test case 1 Inputs Goods returned Substituted Items OrderID Items Unit Nos. Rate Amount No 4367 Lux 75g 1 8.50 8.50 Tax 0 Discount 0 Total 1 8.50 Actual Output Return Cash Rs8.50 Expected Output Return Cash Rs8.50 Settlement Test case 2 Inputs Goods returned Substituted Items OrderID Items Unit Nos. Rate Amount OrderID Items Unit Nos. Rate Amount 4367 Lux 75g 2 8.50 17.00 4367 Rexona 75g 2 8.00 16.00 Amul 1 1 120.00 120.00 Britannia 1 1 110.00 110.00 Kg Kg Ghee Ghee Tax 0 0 Discount 0 0 Actual Total 3 137.00 1 126.00 Output Return Cash Rs 21.00 Expected Total 3 137.00 3 126.00 Output Return Cash Rs 11.00 Settlement 50
  51. 51. 2. Test case for Order Bill Inputs to this test case are Customer Order ID, Items, Units, Numbers, Rate and expected output is supposed be Total amount including tax and discount if any. Test case 1 Inputs Goods returned OrderID Items Unit Nos. Rate Amount 4367 Lux 75g 2 8.50 17.00 Amul Ghee 1Kg 1 120.00 120.00 Tax 0 Discount 0 Actual Output Total 3 137.00 Expected Output Total 3 137.00 3. Test case for Credit Transaction For credit transaction Inputs to the test case are OrderID, Total amount, Pay Mode, Amount Paid, Previous Outstanding and Expected output will be the Total amount due which should be less than performance measure specified. Here variants of pay mode may be cash, credit card or cheque. Performance measure is that the total credit limit that can be kept due is Maximum 1000. Test Case 1 Inputs OrderID Total Pay Amount Previous Total amount due amount Mode Paid Outstanding D=A+C-B A B C 4367 137.00 Cash 200.00 456.00 Actual Output 393.00 Expected Output 393.00 Test case 2 Inputs OrderID Total Pay Mode Amount Previous Total amount due amount Paid Outstanding D=A+C-B C A B 4367 600.00 CreditCard 300.00 800.00 Actual 1100.00 Output Expected 1100.00 Output 51

×