Galla – the Small Shop ERP Product

Galla – the Small Shop ERP Product Date: November 13, 2005

Team Members:

Palwencha Nagraj Krishna([email protected]) (project manager, documentation)

Anirudha Joshi ([email protected]) (domain specialist, product and human-interaction

design)

Gulavani Bhargav Subhash ([email protected]) (software architect, system interface

design and development)

Avinash Gupta ([email protected]) (quality assurance)

Nilesh Nalnikar ([email protected]) (tooling, system interface design and

development)

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

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.

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.

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.

Customer Vendors

Gall

a

Small

Shopkeeper

Interne

t

galla.com

service

Shop

Gall

a

Cashier

other

services

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

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:



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:



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.


In case the shop supports home delivery, the system should enable the shop manager

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:



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.


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:



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:



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.


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:



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

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.


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:



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:


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:



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.


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:



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:

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:



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.


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:



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:



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:



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:



The system should record all expenses such as salaries of employees, rent, etc.

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.

11

1.2.2 Preliminary Use Cases

Includes

Includes

Includes

Includes Includes

Includes

Includes

Shop

Manager

Phone

Operator

Cashier

Shop

Employe

Customer

Session

Ordering

Normal

Order Recurring

Order

Order

Settlement

Extends

Includes

Goods

Returns

Cash

Credit

Card

Credit

Account

Settlement

Cash

Credit

Card

Includes

Vendor

Session

Accepting Delivery

and Billing

Includes

Vendor

Returns

Includes Vendor

Settlement

Includes

Placing

Orders

Includes Administratio

n

Includes

Discounts

and Sales

Demand

Forecasting

Start-up /

Shut-down

Filing

Stock

Galla – the Small Shop ERP

Product

Includes

Cash Flow

Forecasting

Customer Credit

Tracking

Stock

Taking

Setting Customer

Loyalty Benefits

Create New

Account

Delivery

Person

Order

Change

Includes

Create New

Account

Expenses

12

1. Administration



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.


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.


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

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.


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.


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.

14

1.5 Cash Flow Forecasting Users: Shop Manager, Consultant.



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.


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.



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.

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.


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.


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.


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.

16

2. Vendor Session



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.


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.


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.


Requirements: 9.1

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.


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.


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.

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.


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.


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



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.

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.

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



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



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.


Requirements: 2

Note: Order Settlement is an abstract generalization.

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.



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



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



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.

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.


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.


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



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.

23

3.4.2 Credit Card Account Settlement



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.


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.

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.

25

Chapter2. Architecture

2.1 Overall Architecture The layered view of the overall Architecture is as shown:

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.

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

D e vic e sD e vic e s

O S

D B M SU I M g r

A + B + C


O S

D B M SU I M g r

A + B + C

M a s t e r B a c k u p

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


O S

C a c h eU I M g r

A + B + C


O S

C a c h eU I M g r

A + B + C

Devices

OS

UI Mgr A + B + C

A = Customer Management

B = Vendor Management

C = Administrative Activities

Fig 2.1 Layered architecture

diagram

DB Management System

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:

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.

a

b

c

d

e

f

Fig 2.3 Dependence

Graph

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

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)


3. Category-Code (foreign key)

6. Vendor Payment


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


3. Date

4. IsPending

5. Delivery Date

8. Purchase Details

1. Order-Id (foreign key)



4. Quantity (for each of the ordered item)

9. Delivery Discrepancy

1. Discrepancy-Id




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

29

5. Cost

6. Tax

7. Payment-Mode (enum data {cash, credit, credit card})

12. CO Contents




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



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 different

screens

CustomerOrderScreen

DisplayWidgets CustomerOrderSettlementScreen

Create the different screens navigable from

this screen

CustomerGoodsReturnScreen

CustomerPaymentScreen

NewCustomerScreen

CustomerOrderSearchScreen

PendingCustomerOrderScreen

CustomerCreditSumaryScreen

Class CustomerOrderScreen

30


DisplayWidgets CustomerOrder

Pass on the values for Customer details to

CustomerOrder object

CustomerOrderSettlementScreen

Pass on the details(or just item id) of each

item entered to CustomerOrder object as

each item is added

NewCustomerScreen

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


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


31


Pass on the credit card information to the

CreditCardHandler object

CustomerOrder

Send the message to perform the credit card

transaction to CreditCardTransaction object

Prompt the status of credit card transaction CreditCardHandler

Class CreditCardHandler


Contact the credit card transaction gateway

Perform the credit card transaction for the

indicated amount

Set the status of the transaction

Class CustomerPaymentScreen


Display Widgets CustomerPayment

Pass on the credit card information to the

CreditCardHandler object

CreditCardHandler

Prompt the status of credit card transaction, if

credit card opted for

Class CustomerPayment


Set the customer identifier

Set the amount paid

Set the mode of paymennt

Commit the Payment

Class GoodsReturnScreen


Display Widgets CustomerGoodsReturn

Pass on the Order Identifier against which the

returns are made to CustomerGoodsReturn

object

32


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


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


Display Widgets Customer

Pass on the details of the customer to the

Customer object

Class Customer


Set the detials of Customer

Commit the details

The CRC cards for the Vendor activities are as follows:

Class VendorSummaryScreen


Display Widgets VendorSumary

Display the list of all vendors and optionally

vendor details

VendorStatementScreen

For any selected vendor show the list of items

supplied by him in a collapsible fashion / new

screen

VendorStatement

Create the VendorStatementScreen NewVendorScreen

33


Create the NewVendorScreen Vendor

Create the Vendor object PendingVendorOrderScreen

Cerate the VendorStatement object PendingVendorOrder

Class VendorSummary


Get the set of all registered vendors

For each vendor get the set of items supplied

by that vendor

Class VendorOrderScreen


DisplayWidgets VendorOrder

Pass on vendor details to VendorOrder object

Pass on each item added to the VendorOrder

object

Class VendorOrder


Set Vendor details

Check each item added for consistency


Compute taxes

Commit the vendor order details

Class VendorGoodsReturnScreen


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

34

Class VendorGoodsReturn


Set the vendor order identifier

Set the amount and mode of payment

Check each item for validity of return


Commit the vendor goods return details

Class VendorPaymentScreen


Display Widgets VendorPayment

Pass on the amount and mode of payment to

the VendorPayment object

Class VendorPayment


Set the vendor identifier

Set the amount paid

Set the mode of payment

Commit the details

Class NewVendorScreen


Display Widgets Vendor

Pass on the details of Vendor to the Vendor

object

Pass on each item entered to the Vendor object

Class Vendor


Set the detials of Vendor

Add an item supplied by vendor

Commit the vendor details

35

Class VendorStatementScreen


Display Widgets VendorStatement

Pass on the VendorId to the VendorStatement

object

VendorOrderScreen

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


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


DisplayWidgets Authentication

Pass on the username and password to the

Authentication object

LoggedUser

Display error message in case of failure

Pass on the username and role of that user to

the LoggedUser object

Class Authentication


Set the username

Set the password

Check whether the pair (username, pasword)

is valid

36


Get the role associated with username

Class LoggedUser


Set the logged username

Set the logged user role

Class AdministrativeActivitiesScreen


Provide a navigation interface for different

screens

StockSummaryScreen

Display Widgets ExpensesScreen

SalesTrendScreen

DemandForecastScreen

CashFlowScreen

LoyaltyProgramsSettingScreen

DiscountsSettingsScreen

RewardPointSettingsScreen

Class StockSummaryScreen


Display the list of items with their existing

quantities

StockSummary

Display Widgets

Class StockSummary


Get the list of items with their respective

existing quantities

Provide an iterator for the list

Class ExpensesScreen


Display Widgets Expenses

Provide input combos for entering date range

37


Display all the expense items between the date

range mentioned in this screen

Class Expenses


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


Display Widgets CustomerCreditSummary

List for each customer who has outstanding

credit, the credit amount and the earliest date

of outstanding credit

Class CustomerCreditSummary


Get the list of customers that have outstanding

credit from the database


Class PendingVendorOrderScreen


Display Widgets PendingVendorOrder

VendorOrderScreen

VendorOrder

Class PendingVendorOrder


Get the list of pending vendor orders from the

database


38

Class PendingCustomerOrderScreen


Display Widgets PendingCustomerOrder

CustomerOrderScreen

CustomerOrder

Class PendingCustomerOrder


Get the list of pending customer orders from

the database


Class SalesTrendScreen


Send the parameters on which trends are to be

computed to the AnalyzerAdapter object

SalesTrendAnalzer

Ask the analyzer to compute the results

Get and display the results

Class SalesTrendAnalyzer


Receive the data to be processed

Process the data

Send the results in standard format

Class DemandForecastScreen


Send the parameters on which trends are to be

computed to the AnalyzerAdapter object

AnalyzerAdapter

Ask the analyzer to compute the results

Get and display the results

Class AnalyzerAdapter


Set the data to be sent SalesTrendAnalyzer

39


Send the data in standard format DemandForecastAnalyzer

Receive the results in standard format RemoteAnalyzer

Class DemandForecastAnalyzer



Process the data

Send the results in standard format

Class RemoteAnalyzer


Read the remote address + port

Establish connection to remote service


Send the data to the remote processor

Convert the results in standard format

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

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:

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

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

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

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


� Accepting delivery and billing


� Vendor returns


� Vendor settlement

� (same as Vendor Payment screen)

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


� Goods Returns

o Search Order / Bill screen


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

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 Vendors Summary screen

� Add / Edit Vendor screen

• Add / Edit Vendor Item screen

� Vendor Statement screen

• Vendor Payment screen


o (same Add / Edit Vendor screen as above)




� (same as Vendor Payment screen)

o Order / Bill screen

� Up-sale Items screen

� Recurring Order screen

48

� Credit Card Transaction screen

� Credit Transaction screen

� Add / Edit Customer screen


� (same Add / Edit Customer screen as above)

o Customer Statement screen


o Search Order / Bill screen





49

Fig 2.10 UI Diagram

Admin

screen

Settings

screen

Trends and

Forecasts screen

Expense

Voucher screen

Filing Stock

screen

Vendors

Summ. screen

Vend. Statement

screen Add / Edit Vend.

Item screen

Vend. Payment

screen

Add / Edit

Vend. screen

Order / Bill

screen

Up-sale Items

screen

Recurring

Order screen

Credit Card

Trx screen

Up-sale Items

screen

Credit Trx

screen

Add / Edit

Cust. screen

Search Order

/ Bill screen

Authentication

screen

Loyalty Prog.

Settings screen

Sp. Cust.

Settings screen

Reward Pts.

Rules screen

Sales Trends

screen

Stock Summary

screen

From any

screen

Pending

Orders screen

Cust. Credit

Summ. screen

Cust. Statement

screen

Discount Schemes

Settings screen

Cash Flow

Forecast screen

Redemption

Rules screen

Demand

Forecast screen

Vend. Order

screen

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

4367 Lux 75g 1 8.50 8.50

Tax 0

Discount 0

Total 1 8.50

No

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

Ghee

1

Kg

1 120.00 120.00 Britannia

Ghee

1

Kg

1 110.00 110.00

Tax 0 0

Discount 0 0

Actual

Output

Total 3 137.00 1 126.00

Return Cash Rs 21.00

Expected

Output

Total 3 137.00 3 126.00

Return Cash Rs 11.00

Settlement

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

amount

A

Pay

Mode

Amount

Paid

B

Previous

Outstanding

C

Total amount due

D=A+C-B

4367 137.00 Cash 200.00 456.00

Actual Output 393.00

Expected Output 393.00

Test case 2


amount

A

Pay Mode Amount

Paid

B

Previous

Outstanding

C

Total amount due

D=A+C-B

4367 600.00 CreditCard 300.00 800.00

Actual

Output

1100.00

Expected

Output

1100.00

52

So, here for a given order the total amount due though Rs. 1100.00 but the fact that total amount

paid that can be due should not be more than 1000.00 as constrained by the administrator the

above test case is used to check this consistency.

Test case 3


amount

A

Pay

Mode

Amount

Paid

B

Previous

Outstanding

C

Total amount

due

D=A+C-B

4367 137.00 Cheque 393.00

Actual Output 200.00

Expected Output 200.00

4. Test case for Add Customer

Input to this test case is Name of new customer; Address, phone number and output to this add

customer case is the Customer ID with stored inputs.

Test case 1

Inputs Add Customer

Name Address Phone Customer ID

Vikas Kumar #42, LBS Marg,

Mumbai-76

022-23456578

Actual

Output


Mumbai-76

022-23456578 3426

Expected

Output


Mumbai-76

022-23456578 3426

Input to this test case is Name of new customer, Address, phone number and output to this

delete customer case is the Deleted Customer ID and allied information.

Test case 2

Inputs Delete Customer

3426

Actual Output

Expected Output

5. Test case for Sales trends

Inputs to the sales trend test case is the previous demand information for few months and

Expected output will be the sales trend for next three months

53

Test Case 1

Inputs Sales trends

Previous demand (say last 12 months) Sales Forecast for next 3 months

200; 234; 300 250; 310; 330

Actual Output 250; 310; 330

Expected Output 250; 310; 330

6. Test case for Vendor Statement

Input for this test case is Vendor ID. Expected output to this is a whole statement for that

particular vendor.

Test case 1

Input VendorID

2453

Vendor Statement

VendorID Items Qty. Unit Rate Amount

Mode of

payment

Amount

paid

Balance

2453 Lux 1 100X100g 900.00 900.00

Cash

Actual

Output

Britania

Ghee

5 10X1Kg 1100.00 5500.00

5000.00 1400.00

2453 Lux 1 100X100g 900.00 900.00

Cash

5000.00 1400.00

Britania

Ghee

5 10X1Kg 1100.00 5500.00

Expected

Output

Total 6400.00 5000.00 1400.00

7. Test case for Vendor order screen (for order preparation for the particular vendor)

Inputs for this test case are Vendor ID, Item name, Units which is expected is total amount to be

given to the vendor.

Test Case 1

Input Vendor ID Items Ordered Units

4500 Lux Soap 10 0

Britania Ghee 50 Kg

54

Actual Output

Expected Output

4501 Chana Daal 100 Kg

Actual Output

Expected Output

8. Test case for Vendor Summary screen

Vendor summary screen will have the input Vendor ID. Output in this case will be Order

pending, Amount of order pending, and mode of payment etc.

Test Case 1

Input Vendor ID

4500

Actual Output Vendor ID Order

Pending

Amount of order

pending

A

Amount

Paid

B

Previous

Balance

C

Mode of

payment

Outstanding

Due

A-B+C

4500 Oil (50Lit) 2500.00 2500.00

Sugar(100Kg) 1400.00 1000.00

0 Cash 400.00

Total 3900.00 3500.00 0 400.00

Expected Output Vendor ID Order

Pending

Amount of order

pending

A

Amount

Paid

B

Previous

Balance

C

Mode of

payment

Outstanding

Due

A-B+C

4500 Oil (50Lit) 2500.00 2500.00

Sugar(100Kg) 1400.00 1000.00

0 Cash 400.00

Total 3900.00 3500.00 0 400.00

3.2 Testing Method and Test Optimization

Next the Method used for testing is BLACK BOX TESTING and technique under this heading

will be the Orthogonal array of size L5 method.

One example of the orthogonal testing is as follows-

Say Authentication to the system test case.

Pi = 1, Allow authentication

= 2, Allow authentication if failed in earlier login attempt

55

TEST CASES Authentication

TEST PARAMETER

User ID & Pswd

P1

Thumb

P2

Both

P3

1 1 1 1

2 1 2 2

3 1 1 2

4 2 2 2

5 2 2 1

3.3 Quality Assurance Review

1. There is no provision of workforce scheduling screen. There may be the case where some

shop may have many staff for operation. In that case workforce scheduling (algorithm)

screen would help manager and cut down the cost arises due to inefficient scheduling.

2. There is only VendorID. There should also be VendorOrderID created each time the

order is placed to the vendor so that every order can be grouped in one screen for each

vendor.

3. There is provision of only OrderID. Many orders can be placed by single customer. So

there should also be provision for CustomerID.

4. Vendor should be categorized on the basis of company/brand/make/category of goods.

This will help when implementing this package in the retail stores.

5. Customers can also be categorized on basis of buying behavior like recurring orders,

food grains orders, etc.

6. In AddCustomerScreen e-mail ID field is missing.

7. There should also be daily/weekly/monthly sales/inventory/pending order/cash flow

summary screens.

8. Vendor order Screen should be differentiated whether it is meant for order preparation

for particular vendor or for inquiring about the last order placed with the vendor.

Quality Performance Measures

1. Switching from one screen to other screen should happen within 2 sec.

2. Operator should able to switch from any screen to bill screen within a fraction of second,

say half second.

3. Booting time of the system should be less than (<) 5 Sec.

4. Maximum credit privilege given to the regular customer should be maximum up to

Rs.1000 (Can be modified by manager depending upon the creditability of the customer.)

5. System down time should not be more than half an hour and particularly should not be

during 5.00-9.00pm (Peak time).

6. Minimum inventory level for each item should be defined in order to avoid the stock -

outs.

7. Reliability of the system should be high.

8. Other issues that may be considered are-

56

• Usability of the system

• Traceability of requirements

• Understandability – this can be assured from extensive documentation externally

as well as internally to the program so as to help in maintenance.

• Maintainability

• Availability

57

Chapter4 Estimation

Functional Point Analysis:

It’s a unit to measuring the size of a application. It is used it estimating the work content of any

software application and covers all stages of project and counts function points around a single

application boundary. It is independent of technology and the system/program design.

Identification of counting boundary:

♦ Boundary indicates the border between the applications.

♦ Boundary establishes:

o Scope of the application

o Data ownership of the appliacation

o Processing relationships, eg where it occurs.

Schematic depication of components of function point count

EI- External Input

EO – External output

EQ – External Enquiries

ILF-Internal Logical Files

EIF – External Interface files

Users

ILF EIF

Other system

EO EQ

System

boundary

58

♦ Unadjusted Function Point Count Method

Transfer Type DET(data

element type)

RET(record

element type)

Complexity Weight

Customer Details EI 15 3 H 6

Customer order EI 3 1 L 6

Credit Card Details EI 5 1 L 6

Customer mode of payment EI 5 1 L 6

Order identifier EI 3 1 L 6

Mode of return payment EI 5 1 L 6

Vendor details EI 15 3 H 6

Authentication EI 3 1 L 6

Pending vendor order EI 5 1 L 6

Demand forecasting EI 5 1 L 6

Discount setting EI 5 1 L 6

Order statement EQ 5 1 L 4

Vendor statement EQ 15 1 L 4

Item details EO 19 3 A 5

Status of credit card

availability

EO 5 1 L 5

Details of user EO 19 3 A 5

Expense EO 5 1 L 5

Customer credit summary EO 5 1 L 5

Sales trend screen EO 5 1 L 5

Cashflow screen EO 5 1 L 5

Order statement EO 5 1 L 5

Status of customer order ELF 5 1 L 5

Item details file ELF 19 3 A 5

Customer details file ILF 19 1 L 7

Customer order ILF 19 1 L 7

Vendor information file ILF 19 1 L 7

Vendor payment file ILF 19 1 L 7

Cash memo/recipt ILF 19 1 L 7

UFPA=159

59

*DET – Data Element Type is a unique user-recognizable, non-recursive field in ILF/EIF

*RET – Record Element Type is a unique user recognizable subgroup of data element within an

ILF/EIF

* A stands for average

* H stands for high

* L stands for low

Suggested work norms for FPA

For CPP - 12 hours/FP

So, total no. of man-hrs=159 * 12 = 1908 man-hrs

If 6 developer works for 8 hours daily then no. of days required is

= 1908/(6*8)=40 days

Therefore two months of effort required by 6 developer working 8 hrs daily and 20 days per

month.

60

5. Bibliography

1. Pressman, R., S., Software Engineering - A Practioner's Approach (6th en), McGraw Hill

International Edition, 2005.

2. Kelkar, S., A., Software Project Management, Prentice Hall India, New Delhi, 2004.

Galla – the Small Shop ERP Product

Documents

Transcript of Galla – the Small Shop ERP Product