Retail Store Management Information System

B9IS123 (CA-TWO)

Module Information:

Module Title: PROGRAMMING FOR INFORMATION SYSTEMS

Module Code: B9IS123

Module Instructor: Paul laird

Group Members (4 members):

1. Boddu Lakshmi Durga - 20006343

2. Tharun Bheemarthi - 20003066

3. Siva Satyanarayana kamani -10637051

4. Bandoju Brahma chary -20015269

1
 Table of Contents

1. Introduction.....................................................................................3
2. Case Study........................................................................................3
3. Requirements Specification............................................................5
4. Analysis and Design........................................................................9
5. Implementation..............................................................................15
6. Testing the Application.................................................................29
7. Conclusion.......................................................................................40
8. References........................................................................................41

2
1. Introduction

In the dynamic and competitive landscape of the retail industry, efficient and effective management is
crucial for success. The Retail Store Management Information System (RSMIS) emerges as a
comprehensive solution to streamline and optimize the various facets of retail operations. This system
integrates advanced technology to enhance decision-making processes, inventory management, customer
engagement, and overall organizational efficiency.

2. Case Study
This project sets out to develop a retail store management system. In-order to develop this system, we
sought to understand how a typical retail store management system works. From our research, a typical
retail store management system usually consists of several components which are outlined below.

2.1 Staff Management Component

This component allows the retail store to manage all their employees. This component can be split into
the following functionalities. (Treadgold & Reynolds, 2020)
- Viewing and updating of employee personal and professional information
- Tracking of employee’s payrolls
- Managing employee feedback and engagement
- Tracking employees’ attendances
- Tracking employees’ sales

2.2 Analytic and Reporting Component

This component allows the retail store to generate different reports which monitor the day-to-day
operations and then allow the analysis and insights generation based on the reports to identify the trends
and allow the management to make informed decisions. This component can be split into the following
functionalities.
- Generation of different reports such as sales reports, inventory reports, retails reports, customer
reports and point of sale analytics
- Generation of analytics such as trends on the store performance, preferred items by the customers
within the locality.

2.3 Inventory Management component

This component usually allows the store to account for all the incoming and outgoing stock in an effort to
allow for efficient operations to meet customer demand and at the same time avoiding the occurrence of
overstocking or business losses through stock-outs. This component can be split into the following
functionalities.
- Stock and backorder management
- Demand forecasting

3
- Cycle counting

2.4 Supplier management component

This component allows the retails store to manage their suppliers. This component can be split into the
following functionalities:
- Viewing of receipts, contract status, purchase orders
- Viewing of invoices, billing information and payment status
- Responses to queries and Request for proposals.

2.5 Point of sale component

A point-of-sale component usually consists of several activities which work together to sync and track
sales and payments. These activities can be broadly classified into the following functionalities.
- Payment processing
- Customer management
- Receipts and order history

2.6 Analytic and Reporting Component

This component allows the retail store to generate different reports which monitor the day-to-day
operations and then allow the analysis and insights generation based on the reports to identify the trends
and allow the management to make informed decisions. This component can be split into the following
functionalities.
- Generation of different reports such as sales reports, inventory reports, retails reports, customer
reports and point of sale analytics
- Generation of analytics such as trends on the store performance, preferred items by the customers
within the locality.

2.7 Overall Administration Component

This component allows for the full control and administration of all the other components. This
component can be split into the following functionalities
- Management of the employees and their credentials
- Management of stock ins and stock outs
- Management of suppliers.

4
3. Requirements Specification

3.1 System Users

Based on the components identified in the case study, the users of the system can be identified as the
following
- Employees
- Managers
- Owner
- Suppliers

3.2 Software Requirements

Based on the components identified in the case study, the software requirements for the retail store
information system can be split into the following functional and non-functional requirements

3.2.1 Functional
1. The system should allow for the creation of accounts for the relevant system users.
2. The system should allow the relevant system users to log-in.
3. The system should allow for the capture and storage of the relevant employee’s personal information
4. The system should allow recording and storage of product information (updated)
5. The system should allow the recording and storage of product in stock and out of stock.
6. The system should allow for the products in stock to be organized by their type, volume or value.
7. The system should allow for the capture of the relevant supplier’s personal information
8. The system should allow for the recording of the product orders which have been supplied by
the suppliers.
9. The system should allow for the generation of invoices or receipts for the suppliers.
10. The system should capture and store the personal information of a customer for
identification purposes.
11. The system should capture and store the order details of a customer during the purchase process.
12. The system should allow a user to pay for their purchase using their preferred payment method.
13. The system should allow for generation of receipts after customers have made their purchases.
14. The system should allow customers to access their order purchase history
15. The system should allow for the capture and storage of employee’s sales
16. The system should allow for the generation of pay-checks for the employees.
17. The system should allow a manager or an owner to generate a sales report
18. The system should allow a manager or an owner to generate an inventory report
19. The system should allow a manager or an owner to generate a customer report
20. The system should allow a manager or an owner to generate a point-of-sales report
21. The system should allow the owner to add, update or remove employee information

5
22. The system should allow the owner to add, update or remove customer information
23. The system should allow the owner to add, update or remove supplier information
24. The system should allow the owner to add, update or remove stock information.
25. The system should allow the owner to add, update or remove the credentials

3.2.2 Non-Functional Requirements

1. The system should be modular to allow for extension of features in the future
2. Each of the users should have a set of roles which govern the type of data that they access.

3.3 Data Requirements

3.3.1 Data entities and Attributes

The functional requirements outlined in the requirement specification section identified different types
of information that will be collected by the system. From this information, a set of entities and their
associated attributes can be generated as shown in the table below:

Information Type Entity Attributes

1. Employee Information Employee
- Name
- Address
- Phone number
- Date of birth
- Employee type
- Email
- username
- password

2. Product Information Product - Name

- Description
- Supply price
- Retail price
- Quantity
- Date of entry
- Invoice status
- Supplier details

3. Supplier Information Supplier - Name

- Address
- Phone number
- Location
- Email
- username
- password

6
 4. Transaction Information Transaction
- Date and Time
- Amount
- Payment Method
- Purchased products
- employee recording the transaction
- Customer whose transaction has been processed
5. Customer Information Customer - Name
- Address
- Email
- Phone number
- Location
- Date of birth
- Payment Preference
- Order purchase history
- username
- password

3.3.2 Data Relationship Rules

The entities identified above need to have a set of relationship rules that govern how they interact with
one another. This can be summarized as shown in the table below:

Relationship Entities Rule

Type
One – to - One None None
One -to – Many - Transaction and products - A transaction can have multiple products
- Customer and Transactions - A customer can have multiple transactions
- Employee and Transactions - An employee can have multiple transactions

Many-to-Many Product and Supplier - A product can have multiple suppliers and
each supplier can have multiple products

7
3.3.3 Data Validation Rules

For each of the entities and attributes identified a set of validation rules will be applied as outlined below:
1. Entity level validation
All entities will need to have a unique identifier
2. Attribute level validation
3. Product quantity validation – the validation rule here is that every product quantity must be a
whole number which is positive.
4. Email validation – the validation rule here is that every email has to follow the
default [email protected] format.
5. Date range validation – all transaction dates during transactions handling will reflect the current
date and time

3.4 Data storage and Access

For the storage and access of the data the following are the requirements
- The data should be preferably be stored using a relational database which captures the entities and
attributes into the appropriate tables, columns and relationships defined in the form of a primary
key, foreign key structure
- The create, read, update and read operations (CRUD) with additional searching and sorting should
be implemented in the form of an API.

8
4. Analysis and Design

4.1 Database Design

4.1.1 Entity Relationship Diagram

To generate the entity relationship diagram, the entities and attributes identified in the data requirements
section have been used in accordance with the rules identified in the data relationship section.

9
4.2 Relational Schema

To generate the relational schema, the following steps have been applied:
Conversion of the entities into relational database tables
- For each of the entities, in the entity relationship diagram, a table with the attributes as fields has been
generated as follows
Table Fields
Employee
- Name
- Address
- Phone number
- Date of birth
- Employee type
- Email
- username
- password

Product - Name
- Description
- Supply price
- Retail price
- Quantity
- Date of entry
- Invoice status
- Supplier details
Supplier - Name
- Address
- Phone number
- Location
- Email
- username
- password
Transaction
- Date and Time
- Amount
- Payment Method
- Purchased products
- employee recording the transaction
- Customer whose transaction has been processed

10
 Customer - Name
- Address
- Email
- Phone number
- Location
- Date of birth
- Payment Preference
- Order purchase history
- username
- password

4.2.1 Generation of business rules from the data relationship rules

With the creation of the additional tables in the database normalization step, the following business rules
have been generated to guide how relationships will be created:
- A customer, employee or a supplier can only have one authentication credential
- A customer can have multiple transactions
- An employee can server multiple transactions
- A product can be in multiple transactions
- A customer can have multiple receipts
- Multiple products can be recorded in stock
- A supply can supply multiple products to stock

4.2.2 Generation of primary key and foreign keys to establish relationships

A set of primary key and foreign keys have been generated for each related tables using the identified
business rules as shown in the table below:

Table Primary Key Foreign Key Related Table Relationship Type

Authenticatio AuthenticationID None None None
n
Employee EmployeeID AuthenticationID Authentication One-to-One
(Mandatory)
Product ProductID None None
Stock None ProductID Product Many-to-Many
SupplierID Supplier (Optional)
Many-to-Many
(Optional)
Supplier SupplierID AuthenticationID Authentication One-to-One
(Mandatory)

11
 Transaction None CustomerID Customer Many- to- Many
EmployeeID Employee (Optional)
ProductID Product Many- to- Many
(Optional)
Many- to- Many
(Optional)
Customer CustomerID AuthenticationID Authentication One-to-One
(Mandatory)
Receipt None CustomerID Customer Many- to- Many
(Optional)

The final relational schema represented using the crow foot’s notation is shown in the diagram
below:

12
4.3 Process Design
4.3.1 Flowchart

13
4.3.2 Class Diagram

To generate the tables mapped out in the relational schema have been represented in the UML notations
as a class diagram. To represent the schema in the UML notation, the following steps have been taken:
- Tables and fields are the same but are now represented as classes and their attributes and an
additional component which is the data type.
- Functions / Methods for interacting with the classes have been added
- The relationships are represented as associations. Here all the associations are of the composition type
in the sense that any instance of a class used in another class ceases to exist when the class of origin is
deleted.
- The relationship types are now represented as multiplicities. The multiplicities remain the same
as defined in the relationship types.

14
The final UML class diagram is shown below:

5. Implementation

5.1 Development Environment

The chosen development environment is the Python / JS approach implemented as follows:

Backend
- The MySQL database engine using XAMPP server
- The Pony ORM relationship mapper to interact with MySQL database engine
- Python flask framework for implementing the API.
- Postman application for API testing

15
Frontend
- HTML, CSS, JS
- Python Flask framework for serving the HTML, CSS, JS pages

5.2 High level Application Architecture – Python / JS logic

The architecture of the retail store application illustrated in the diagram above contains two levels,
basically the frontend and the backend. The code for the backend is organized in a package, module, and
class structure. This backend is accessed using a REST API. The REST API works by receiving a request
and sending back a response using the popular HTTP verbs namely the POST, GET, PUT and DELETE
verb. The POST verb is used to send data to the API, the GET verb is used to fetch data from the API, the
PUT verb is used to send data which is created or updated depending on whether it already exists. The
DELETE verb usually removes information from the API. These verbs then send the received data to the
underlying database engine.
For the retail store application. Once the requests are received by the API endpoints, they interact with the
database engine through the ponyORM object relational mapper in the form of entities. The pony ORM
mapper allows easy interaction with the underlying database by minimizing the need to run the SQL
queries necessary for performing the CRUD (Create, Read, Update and Delete) operations.

16
The frontend contains the HTML and CSS files which represent the user interface which is loaded when
the application is accessed on the web browser. To send the required data between the flask application
and the frontend, the Jinja template engine which exists in flask is used to get and serve these web files on
the browser. On the frontend, to interact with the API endpoints, JavaScript is used to send the requests
and process the response from the API.
To interact with the application, the application is activated by running the command python app.py on
the python prompt and then accessing the front end on the browser on the address http://127.0.0.1:105

5.3 File Structure

5.3.1 Packages
The packages act a container for holding the modules. Using packages allows for the extension of the
code in the case where new features need to be added to the retail store application. The basic code
structure of the package is as follows:

The package is named after the database table and contains a module which has the same name and an
empty init .py file which allows python to identify the directory as a package. There are 8 packages
namely
- authentication
- customer
- employee
- product
- receipt
- stock
- supplier
- transaction

17
Modules
Each package contains a module. The module contains the standalone classes which the application uses
to interact with the API. The modules are named the same as the package but their first letters are
Capitalized. This ensures that there are no conflicts when importing the modules in the main app.py file.
(Ashley, 2020)

Standalone classes
Each module contains a standalone class which has the same name as the module. All the standalone
classes have the same standard structure shown and explained below:
- There is an import statement for importing all the objects from the pony ORM python module.

- There is a class definition with the name corresponding to a database table.

- There is a class constructor which takes in a model which is an pony ORM entity as described in the
Pony ORM entities section, a connection dictionary which is simply a python dictionary containing
the host, username, password, database and port for the MySQL database engine alongside entity
specific attributes

- The class then has methods for adding, updating, and removing data. These methods are called by
the API endpoints which then send and retrieve data from the database

18
5.4 API Endpoints (app.py)
The API endpoints are defined in the app.py file. The app.py file has several definitions which governs
how the app operates these definitions are outlined below: (Kore et al., 2022)

There is the import section which imports all the objects from the pony ORM module, the config module
which is described in the MySQL database engine section, the date time module to allow for operations
with dates, the flask module which is base framework used to create the web application, the model’s
module described in the pony ORM entities section the 8 packages and their respective standalone
classes.

- There is the Pony ORM database object instantiation which allows tables from the models in the
pony ORM entities section to be created into the database

19
- There is the creation of a test user which allows the user to login as the store owner

- There is the instantiation of the application as a flask app

- There is the definition of the API endpoints using the (@route flask decorator). Each of the API
endpoint has a method corresponding to a REST API verb. These endpoints follow the /api
notation

- There is the definition of non-API endpoints which are used to server the html web page interfaces

20
- Lastly there is the final code that starts the application on 127.0.01 on port 105

5.5 PonyORM Entities (models.py)

The pony ORM entities defined in the models.py are a set of classes which correspond to the 8
standalone classes which inherit from the pony model Entity definition that automates the creation of
tables by mapping python class entities into database tables. The entity definitions follow the following
structure

21
- A class named as the database table which is to be created which inherits from the Entity class of
the pony object
- Several table fields which may include a primary key
- Several table fields which may include a foreign key defined using the Set or Optional followed by
a table name
- Several non-foreign key fields which contain an optional or Required option followed by the data
type which is can be str, datetime or int depending on the data that the
The basic structure is the same for all the 8 entities

5.6 MySQL Database Engine (config.py)

Once the installation of an appropriate MySQL database engine is done in this case the XAMPP server
which was used as the test server, a host, username, password, database and ports needs to be defined.
Since these credentials remain the same through out the lifecycle of the application, they are defined in
the config.py file as shown below:

22
5.7 HTML CSS and JS
The HTML, CSS and JS files are the frontend section of the web application. The html files in flask are
stored in the templates directory while the CSS and JS files are stored in the static directory. The files in
the static directory remain unchanged during the life cycle of the web application. The directory structure
is shown below:

In the templates folder, we have the html files which follow the flask Jinja template engine structure.
This template structure allows python data structures and variables to be run and interfaced into the html
code. Any python code inside the html is inside curly brace {{ }} for variables and inside percentage
marks
{% in the case of control structures such as (for or if) as shown below:

23
5.8 Making changes to the code

To make changes to the code, the above workflow is applied. As an example, a change in a supplier
information to change the location attribute to city would be as follows:

24
1. Drop and recreate the target database.
2. Update the Supplier entity changing the location to city from models.py file

3. update the stand-alone class Supplier.py on all the instances of location to city.

25
● Update any methods that rely on the location variable to city

4. Update the relevant endpoints in app.py (api/addsupplier)

5. Update the relevant front-end sections(templates/owner.html) as follows:

● adding information – html form attributes

● adding information – js api function

26
● viewing information – html form attributes

27
28
6. Testing the Application

Testing the frontend and backend of an application is crucial to ensure that both components work
seamlessly together and that the application functions as intended. Below are some general steps and
considerations for testing the frontend and backend of your Retail Store Management Information
System application.

Running the flask App

6.1 Backend
Model Creation using a local MysQL instance

29
6.2 API Endpoints

1. Adding data to the Authentication table – api/adduser

endpoint Code Sample

Calling the endpoint using Postman

30
Added Data

2. Adding data to the employee table – api/addemployee endpoint

Code Sample

Calling the endpoint using Postman

31
Added Data

3. Adding data to the Supplier table – api/addsupplier endpoint

Code Sample

Calling the endpoint in Postman

32
Added Data

4. Adding data to the Product table – api/addproduct

endpoint Code Sample

Calling the endpoint in Postman

33
Added Data

Adding data to the Stock table – api/addstock endpoint

Code Sample

Calling the endpoint in Postman

34
Added Data

6.3 Front-End

1. Login Page

35
2. Owner Dashboard

3. Calling the API using JS

36
4. Adding or Viewing user credentials using the web interface

37
Added Data

5. Adding or Viewing employee information using the web interface

Added Data

6. Adding or Viewing supplier information using the web interface

38
Added Data

Added Data

7. Adding or Viewing products information using the web interface

Added Data

8. Adding or Viewing stock information

39
Added Data

7. Conclusion

40
In conclusion, the Retail Store Management Information System (RSMIS) project aims to address the
complex needs of the retail industry by providing a comprehensive solution for efficient store
management. The system is designed to encompass various components, including staff management,
analytics and reporting, inventory management, supplier management, point of sale, and overall
administration.

The requirements specification outlines the system users, software requirements, and data requirements,
including entities, attributes, relationship rules, and validation rules. The system's data storage and access
are proposed to be implemented using a relational database, with CRUD operations facilitated through an
API.

The analysis and design phase delve into the database design, presenting an Entity Relationship Diagram
(ERD), relational schema, and process design through flowcharts and class diagrams. The system's
implementation details include the development environment, high-level application architecture, file
structure, and the structure of backend modules, API endpoints, and frontend components.

Testing the application is crucial to ensure its functionality. The testing phase includes backend testing,
API endpoint testing using tools like Postman, and frontend testing to validate the user interface.

The references section acknowledges various sources that contributed to the project, covering areas such
as Flask development, API testing, and business intelligence.

In summary, the Retail Store Management Information System aims to enhance retail operations through
advanced technology and efficient management practices, providing a robust solution for the challenges
faced by the retail industry. The detailed documentation and implementation plan provide a roadmap for
the development and deployment of the system.

8. References

41
1. Ashley, D. (2020). Using flask and jinja. Foundation Dynamic Web Pages with Python, 159–
181. https://doi.org/10.1007/978-1-4842-6339-6_5

2. Ilmudeen, A. (2022). Business Intelligence and decision support systems: Business applications in
the Modern Information System Era. Knowledge Engineering for Modern Information Systems, 156–
172. https://doi.org/10.1515/9783110713633-009

3. Jain, J. (2022). Introduction to API testing. Learn API Testing, 1–

9. https://doi.org/10.1007/978-1-4842-8142-0_1

4. Kore, P. P., Lohar, M. J., Surve, M. T., & Jadhav, S. (2022). API testing using Postman Tool.
International Journal for Research in Applied Science and Engineering Technology, 10(12), 841–
843. https://doi.org/10.22214/ijraset.2022.48030

5. Nicholus, R. (2016). Understanding the web API and “vanilla” JavaScript. Beyond jQuery, 19–
29. https://doi.org/10.1007/978-1-4842-2235-5_3

6. Peters, C., & Bodkin, C. D. (2021). Retail store community and its impact on store
success. International Journal of Retail & Distribution Management, 49(6), 735–751.
https://doi.org/10.1108/ijrdm-05-2020-0165

7. Python orm with Beautiful query syntax. PonyORM. (n.d.).

https://ponyorm.org/ Relan, K. (2019). Beginning with flask. Building REST
APIs with Flask, 1–26. https://doi.org/10.1007/978-1-4842-5022-8_1

8. Taylor, L. (2019). Experiential learning through concept and pop-up retailing. Bloomsbury
Fashion Business Cases. https://doi.org/10.5040/9781350996014.0030

9. Treadgold, A., & Reynolds, J. (2020). Reimagining the retail store. Navigating the New
Retail Landscape, 206–241. https://doi.org/10.1093/oso/9780198868767.003.0009

10. Yen, D. C., & Davis, W. S. (2019). Expert system analysis and design. The Information
System Consultant’s Handbook, 47–54. https://doi.org/10.1201/9781420049107-7

42
43