TABLE OF CONTENTS

1. Introduction ............................................................................................................................ 12
1.1. Brief ................................................................................................................................. 12
1.2. Relevance to Course Modules.......................................................................................... 12
1.3. Project Background ......................................................................................................... 12
1.4. Literature Review ............................................................................................................ 12
1.5. Analysis from Literature Review ...................................................................................... 13
1.6. Methodology and Software Lifecycle for This Project ...................................................... 14
1.6.1. Rationale behind Selected Methodology ................................................................. 14
2. Problem Definition .................................................................................................................. 15
2.1. Problem Statement.......................................................................................................... 15
2.2. Deliverables and Development Requirements ................................................................. 15
2.3. Current System (if applicable to your project) ................................................................. 16
3. Requirement Analysis ............................................................................................................. 16
3.1. Use Cases Diagram(s)....................................................................................................... 17
3.2. Detailed Use Case ............................................................................................................ 18
3.3. Functional Requirements ................................................................................................. 36
3.4. Non-Functional Requirements ......................................................................................... 39
4. Design and Architecture .......................................................................................................... 40
4.1. System Architecture ........................................................................................................ 40
4.2 . Data Representation ...................................................................................................... 41
4.2.1. DFD Level 0 .................................................................................................................. 41
4.2.2. DFD Level 1 ........................................................................................................................ 42
4.3. Process Flow/Representation............................................................................................... 44
4.4. Design Models ................................................................................................................. 44
5. Implementation ...................................................................................................................... 45
5.1. Algorithm ........................................................................................................................ 45
5.2. External APIs ................................................................................................................... 46
5.3. User Interface .................................................................................................................. 46
6. Testing and Evaluation ............................................................................................................ 51
6.1. Manual Testing ................................................................................................................ 51
6.1.1. System testing .......................................................................................................... 51
6.1.2. Unit Testing .............................................................................................................. 51
6.1.3. Functional Testing .................................................................................................... 62
6.1.4. Integration Testing ................................................................................................... 65
 6.2. Automated Testing: ......................................................................................................... 66
6.2.1. Tools used: ................................................................................................................... 66
7. Conclusion............................................................................................................................... 66
8. Future Work ............................................................................................................................ 67
9. References .............................................................................................................................. 68

LIST OF FIGURES

Fig 3.1 Use Case Diagram .......................................................................................................... 17

Fig 4.1 System Architecture ....................................................................................................... 40
Fig 4.3 Process Flow/Representation ......................................................................................... 44

LIST OF TABLES

Table 1.1 Table1 .......................................................................................................................... 8

Table 2.1 ..................................................................................................................................... 9
Table 5.1 ................................................................................................................................... 47

 Introduction
This chapter provides the overview of the project. The first paragraph of every chapter
should provide the chapter summary.

 Brief
The ERP (Enterprise Resource Planning) System presented in this thesis serves as a
comprehensive solution designed to meet the specific needs of suppliers, addressing a
critical gap in the market. This chapter offers an introductory glimpse into the ERP
System, summarizing its outcomes, tools, methodologies, and key discussions covered
throughout this report.
 Relevance to Course Modules
The development of this ERP System project is directly tied to the coursework
undertaken during our BSE program. This project draws inspiration from various course
modules, incorporating the knowledge and skills acquired over the academic journey.

 Project Background
This project started when we realized the challenges faced by small-scale suppliers, who
often grapple with manual record-keeping and management processes. This ERP System
aims to streamline their daily operations by offering a tailored solution. It addresses the
question of what ERP (Enterprise Resource Planning) is and how it can revolutionize
supplier management.

 Literature Review
Cloud Based ERP System for SME Industry
The Enterprise resource planning (ERP) system has become the necessity of nearly all
businesses. ERP architecture incorporates and defines a multitude of business
processes and facilitates information transfer between them. An ERP system prevents
duplication of information and ensures data integrity by gathering shared transactional
shared data from multiple sources of an enterprise. There is a range of ERP systems
available providing solutions to large businesses, however ERP systems for small and
medium-sized businesses are obligatory. (Ijcsis, 2020)
The Impact of Enterprise Resource Planning Systems on Small and Medium
Enterprises
The deployment of ERP systems is common practice in today’s business environment.
Kumar and Hillegersber (2000) described the impact of ERP systems on corporations,
and confirmed that ERPs were becoming so common in today’s business environment
that they were described as “the price of entry for running a business” (p.24). Kumar
and Hillegersber highlighted the significance and importance of medium-size
corporations in the ERP marketplace, and confirmed that small and medium-size
corporations are beginning to embrace ERP technologies. The number of small and
medium-sized businesses retiring legacy systems in favor of ERP systems is increasing
exponentially. Esteves (2009) explained that in recent years SMEs are in a better
position to acquire and implement ERP systems, which in the past were only available
to larger corporations due to financial limitations as well as other factors. (Buleje, 2014)
The usefulness of ERP systems for effective management
Enterprise resource planning (ERP) systems offer distinct advantages in this new
business environment as they lower operating costs, reduce cycle times and (arguably)
increase customer satisfaction. (Spathis & Constantinides, 2003)

 Analysis from Literature Review

In the preceding literature review, several key insights regarding ERP systems,
particularly within the context of small and medium-sized enterprises (SMEs), were
presented. These insights offer valuable perspectives that inform the development and
objectives of our ERP System project tailored for suppliers. Here, we analyze and
 contextualize these findings within the scope of our project:
ERP Systems as a Necessity for Businesses
The literature highlights the growing indispensability of ERP systems across various
business sectors. ERP architecture streamlines critical business processes and ensures
data integrity by consolidating transactional data from multiple sources within an
enterprise (Ijcsis, 2020). This aligns with our project's core objective of enhancing
operational efficiency and data management for small-scale suppliers through a
specialized ERP system.
Impact of ERP on Small and Medium Enterprises
Kumar and Hillegersber (2000) assert that ERP systems have become essential in the
modern business landscape, describing them as "the price of entry for running a
business" (p. 24). This recognition underscores the significance of ERP adoption for
small and medium-sized enterprises (SMEs) (Buleje, 2014). As our project focuses on
catering to the needs of small suppliers, this literature aligns with our aim to empower
SMEs with the tools and capabilities necessary to thrive in today's competitive
marketplace.
Accessibility of ERP Systems for SMEs
Esteves (2009) observes a shift in the ERP landscape, with SMEs increasingly well-
positioned to acquire and implement ERP systems, which were previously
predominantly available to larger corporations (Buleje, 2014). This trend supports our
project's premise that a specialized ERP system can be accessible and beneficial to small
suppliers. We aim to address the financial and operational constraints that SMEs often
encounter when adopting ERP technology.
Enhancing Efficiency and Customer Satisfaction
Spathis and Constantinides (2003) note that ERP systems offer advantages such as
reduced operating costs, shorter cycle times, and potentially improved customer
satisfaction. These benefits align with our project's objectives, as we aim to provide
small-scale suppliers with the tools to streamline their operations, optimize resource
utilization, and ultimately enhance their competitiveness in the market.
The analysis of the literature review underscores the relevance and importance of our
ERP System project. It validates the need for a supplier-focused ERP system tailored to
the unique requirements of small-scale businesses. By drawing on these insights, our
project strives to bridge the gap in the ERP landscape for SMEs, offering a
comprehensive and accessible solution that empowers suppliers to thrive in today's
dynamic business environment.

 Methodology and Software Lifecycle for This Project

The chosen design methodology is Function-Based Programming with React,
emphasizing the use of pure functions and functional composition. This approach is
well-suited for creating a streamlined and efficient ERP solution for small-scale
 suppliers. We have also opted for the Scrum agile methodology as our SDLC model,
characterized by iterative development.

 Rationale behind Selected Methodology

The chosen design methodology for our ERP System is Function-Based
Programming with React, primarily driven by the emphasis on pure functions and
functional composition in software design. This approach promotes modularity
and maintainability, aligning with our goal of creating an efficient ERP solution for
small-scale suppliers.
 Rationale behind Selected Methodology
The adoption of the Scrum agile methodology as our Software Development Life
Cycle (SDLC) model is rooted in its iterative approach. Scrum's emphasis on
collaboration, flexibility, and risk management aligns with our project's
objectives. By breaking the project into manageable sprints and allowing for
frequent inspection and adaptation, Scrum ensures that our ERP System remains
adaptable to changing requirements and market dynamics.


 Problem Definition
Small-scale suppliers often encounter operational inefficiencies and data management
challenges due to the lack of tailored ERP solutions. The problem lies in the absence of ERP
systems specifically designed to cater to their unique needs, leading to manual and
disjointed processes that hinder productivity and decision-making capabilities.
The outcome we aspire to achieve with our ERP System is to empower small-scale suppliers
by offering them a user-friendly, modular, and scalable solution that streamlines their
operations, enhances data integrity, and enables informed decision-making. By addressing
these challenges, our project aims to contribute to the improved efficiency and
competitiveness of small-scale suppliers in the business landscape.

 Problem Statement
Small-scale suppliers, despite their critical role in the supply chain, often face significant
challenges due to the lack of efficient ERP systems. Manual and disjointed processes,
data duplication, and limited decision support tools hinder their operational efficiency
and competitiveness in the market.
Small-scale suppliers require a dedicated ERP system that streamlines their operations,
ensures data integrity, and empowers them to make informed decisions.

 Deliverables and Development Requirements

The deliverables for our ERP System project encompass a fully functional and user-
friendly web-based ERP system designed exclusively for small-scale suppliers. This
system will comprise modules for finance management, customer relationship
 management (CRM), inventory management, and human resource management (HRM).
It will enable users to perform tasks such as recording financial transactions, managing
accounts payable and receivable, tracking customer interactions, updating product
inventory, and overseeing employee details, including attendance.
Development requirements include the utilization of the MERN stack, comprising
MongoDB for the database, Express.js for the web application framework, React.js for
the user interface, and Node.js for the server-side runtime environment. Additionally,
the system must operate seamlessly across various web browsers and devices, ensuring
global accessibility for users from different geographical locations.

 Current System (if applicable to your project)

Figure 2.1: SAP ERP

Table 2.1: Sample Table

Existing System Weaknesses Solutions
SAP ERP Complex implementation The ERP System offers
simplified and streamlined
implementation processes,
reducing complexity.
SAP ERP High Costs A cost-effective
alternative, tailored to the
needs of small-scale
suppliers, is provided by
the ERP System.
SAP ERP Challenging for Small The ERP System is
Suppliers designed to cater
specifically to the
requirements and
resources of small-scale
suppliers, ensuring
usability and affordability.
 Requirement Analysis
The requirement analysis phase of the ERP System project involves in-depth examination
and documentation of the specific needs and expectations of small-scale suppliers.
This section encompasses the identification of functional and non-functional requirements
essential for the successful development and implementation of the ERP system.

 Use Cases Diagram(s)

Fig 3.1 Use Case Diagram

 Detailed Use Case

Use Case 1: Login
Column Description
Identifier UC-1
Use Case Name Login
Actors Primary Actor: User
Description This use case allows the user to log in to the system.
Trigger The user initiates the login process.
Preconditions None
Postconditions The user is successfully logged in, granting access to the system.
Normal Flow 1. The user provides valid credentials. 2. The system validates the
credentials. 3. The system grants access to the user.
Alternative None
Flows
Exceptions Invalid credentials: The system displays an error message.
Business Rules None

Use Case 2: Signup

Column Description
Identifier UC-2
Use Case Name Signup
Actors Primary Actor: User
Description This use case allows a new user to create an account.
Trigger The user initiates the signup process.
Preconditions None
Postconditions The user account is successfully created.
Normal Flow 1. The user provides necessary information for signup. 2. The system
 validates the information. 3. The system creates a new user account.
Alternative None
Flows
Exceptions Existing username or email: The system prompts the user to choose
different credentials.
Business Rules None

Use Case 3: Add Product

Column Description
Identifier UC-3
Use Case Add Product
Name
Actors Primary Actor: User
Description This use case allows the user to add a new product to the inventory.
Trigger The user indicates the need to add a new product.
Preconditions The user is authenticated and has access to the product management
functionality.
Postconditions The new product is added to the inventory.
Normal Flow 1. The user selects the option to add a new product. 2. The user
provides necessary details for the product. 3. The system validates the
information. 4. The system adds the new product to the inventory.
Alternative None
Flows
Exceptions Incomplete or incorrect product details: The system prompts The user to
provide valid information.
Business Rules None

Use Case 4: Update Product

Column Description
Identifier UC-4
Use Case Update Product
Name
Actors Primary Actor: User
Description This use case allows the user to update product information in the
inventory.
Trigger The user indicates the need to update product information.
Preconditions The user is authenticated and has access to the product management
functionality.
Postconditions The product information is successfully updated.
Normal Flow 1. The user selects the option to update a product. 2. The user selects
the product to be updated. 3. The user modifies the necessary product
details. 4. The system validates the updated information. 5. The system
updates the product information.
Alternative None
Flows
Exceptions Unauthorized user: The system denies access to Unauthorized users.
 Business Rules None

Use Case 5: Delete Product

Column Description
Identifier UC-5
Use Case Delete Product
Name
Actors Primary Actor: User
Description This use case allows the user to delete a product from the inventory.
Trigger The user indicates the need to delete a product.
Preconditions The user is authenticated and has access to the product management
functionality.
Postconditions The selected product is successfully deleted from the inventory.
Normal Flow 1. The user selects the option to delete a product. 2. The user chooses
the product to be deleted. 3. The system prompts for confirmation. 4.
The user confirms the deletion. 5. The system removes the product from
the inventory.
Alternative None
Flows
Exceptions Unauthorized user: The system denies access to Unauthorized users.
Business Rules None

Use Case 6: View Product

Column Description
Identifier UC-6
Use Case View Product
Name
Actors Primary Actor: User
Description This use case allows the user to view details of a product in the
inventory.
Trigger The user indicates the need to view product details.
Preconditions The user is authenticated and has access to the product management
functionality.
Postconditions The product details are displayed to the user.
Normal Flow 1. The user selects the option to view products. 2. The system retrieves
and displays a list of products. 3. The user selects a specific product to
view details. 4. The system shows detailed information about the
selected product.
Alternative None
Flows
Exceptions None
Business Rules None

Use Case 7: View Vendor

Column Description
Identifier UC-7
Use Case View Vendor
Name
Actors Primary Actor: User
Description This use case allows the user to view details of a vendor.
Trigger The user indicates the need to view vendor details.
Preconditions The user is authenticated and has access to vendor information.
Postconditions The vendor details are displayed to the user.
Normal Flow 1. The user selects the option to view vendors. 2. The system retrieves
and displays a list of vendors. 3. The user selects a specific vendor to
view details. 4. The system shows detailed information about the
selected vendor.
Alternative None
Flows
Exceptions None
Business Rules None

Use Case 8: Add Vendor

Column Description
Identifier UC-8
Use Case Add Vendor
Name
Actors Primary Actor: User
Description This use case allows the user to add a new vendor to the system.
Trigger The user indicates the need to add a new vendor.
Preconditions The user is authenticated and has access to vendor management
functionality.
Postconditions The new vendor is successfully added to the system.
Normal Flow 1. The user selects the option to add a new vendor. 2. The user provides
necessary details for the vendor, such as name and contact information.
3. The system validates the vendor details. 4. The system adds the new
vendor to the system.
Alternative None
Flows
Exceptions Incomplete or Invalid vendor information: The system prompts The user
to provide valid details.
Business Rules Vendor data should be complete and accurate, including contact
information.

Use Case 9: Vendor Payment System

Column Description
Identifier UC-9
Use Case Vendor Payment Status
Name
Actors Primary Actor: User
Description This use case allows the user to view payments to vendors.
Trigger The user indicates the need to view vendor payments.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The vendor payment is processed and recorded.
Normal Flow 1. The user selects the option to view vendor payments status. 2. The
system displays a list of outstanding payments and cleared payments of
vendors.
Alternative None
Flows
Exceptions None
Business Rules All vendor payments should be accurately recorded in The system.

Use Case 10: Add Customer

Column Description
Identifier UC-10
Use Case Add Customer
Name
Actors Primary Actor: User
Description This use case allows the user to add a new customer to the system.
Trigger The user indicates the need to add a new customer.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The new customer is added to the system.
Normal Flow 1. The user selects the option to add a new customer. 2. The user
provides necessary details for the customer, such as name, contact
information, and additional relevant data. 3. The system validates the
customer details. 4. The system adds the new customer to the system.
Alternative None
Flows
Exceptions Incomplete or Invalid customer information: The system prompts The
user to provide valid details.
Business Rules customer data should be complete and accurate, including contact
information.

Use Case 11: Update Customer

Column Description
Identifier UC-11
Use Case Update Customer
Name
Actors Primary Actor: User
Description This use case allows the user to update customer information.
Trigger The user indicates the need to update customer information.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The customer information is updated in the system.
Normal Flow 1. The user selects the option to update customer information. 2. The
user selects the customer to be updated. 3. The user modifies the
 necessary customer details. 4. The system validates the updated
information. 5. The system updates the customer information.
Alternative None
Flows
Exceptions Only authorized users can update customer data.

Use Case 12: Delete Customer

Column Description
Identifier UC-12
Use Case Delete Customer
Name
Actors Primary Actor: User
Description This use case allows the user to delete a customer from the system.
Trigger The user indicates the need to delete a customer.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The customer is successfully removed from the system.
Normal Flow 1. The user selects the option to delete a customer. 2. The user chooses
the customer to be deleted. 3. The system prompts the user for
confirmation. 4. The user confirms the deletion. 5. The system removes
the customer from the system.
Alternative Cancel Deletion: If The user decides not to delete The customer, The
Flows system cancels The Deletion process.
Exceptions Only authorized users can delete a customer.

Use Case 13: View Customer

Column Description
Identifier UC-13
Use Case View Customer
Name
Actors Primary Actor: User
Description This use case allows the user to view detailed information about a
customer.
Trigger The user indicates the need to view customer details.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The user views the detailed information about the selected
customer.
Normal Flow 1. The user selects the option to view customer details. 2. The system
displays list of customers with all the information about the customer.
Alternative None
Flows
Exceptions None

Use Case 14: Add Sales

Column Description
 Identifier UC-14
Use Case Add Sales
Name
Actors Primary Actor: User
Description This use case allows the user to add sales transactions to the system.
Trigger The user indicates the need to add a new sales transaction.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The new sales transaction is successfully added to the system.
Normal Flow 1. The user selects the option to add a new sales transaction. 2. The user
provides details for the sales, including product, quantity, and pricing
information. 3. The system validates the sales transaction details. 4. The
system adds the new sales transaction to the records.
Alternative None
Flows
Exceptions Incomplete or Invalid sales transaction details: The system prompts The
user to provide valid information.

Use Case 15: View Sales

Column Description
Identifier UC-15
Use Case View Sales
Name
Actors Primary Actor: User
Description This use case allows the user to view a list of sales transactions.
Trigger The user indicates the need to view sales transactions.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The user views the list of sales transactions.
Normal Flow 1. The user selects the option to view sales transactions. 2. The system
retrieves and displays the list of sales transactions.
Alternative None
Flows
Exceptions None

Use Case 16: Sale Payment Status

Column Description
Identifier UC-16
Use Case Sale Payment Status
Name
Actors Primary Actor: User
Description This use case allows the user to check the payment status of a sales
transaction.
Trigger The user indicates the need to check the payment status of a sale.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The user views the payment status of the selected sales
transaction.
Normal Flow 1. The user selects the option to check sale payment status. 2. The
system displays the list of the payment status.
Alternative None
Flows
Exceptions None

Use Case 17: Add Employees

Column Description
Identifier UC-17
Use Case Add Employees
Name
Actors Primary Actor: User
Description This use case allows the user to add new employees to the system.
Trigger The user indicates the need to add a new employee.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The new employee is successfully added to the system.
Normal Flow 1. The user selects the option to add a new employee. 2. The user
provides necessary details for the new employee, including personal
information and role. 3. The system validates the employee details. 4.
The system adds the new employee to the records.
Alternative None
Flows
Exceptions Incomplete or Invalid employee details: The system prompts The user to
provide valid information.

Use Case 18: Update Employees

Column Description
Identifier UC-18
Use Case Update Employees
Name
Actors Primary Actor: User
Description This use case allows the user to update information about existing
employees.
Trigger The user indicates the need to update employee information.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
employees in the system.
Postconditions POST-1: The employee information is successfully updated in the
system.
Normal Flow 1. The user selects the option to update employee information. 2. The
user chooses the specific employee to update. 3. The user modifies the
necessary details for the selected employee. 4. The system validates the
updated information. 5. The system updates the employee information
in the records.
Alternative Cancel update: If The user decides not to proceed with The updates, The
Flows system cancels The process.
Exceptions Incomplete or Invalid updated information: The system prompts The
user to provide valid information.
Use Case 19: Delete Employees
Column Description
Identifier UC-19
Use Case Delete Employees
Name
Actors Primary Actor: User
Description This use case allows the user to remove employees from the system.
Trigger The user indicates the need to delete an existing employee.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
employees in the system.
Postconditions POST-1: The selected employee is successfully removed from the
system.
Normal Flow 1. The user selects the option to delete an employee. 2. The user
chooses the specific employee to delete. 3. The system confirms the
deletion with the user. 4. The system removes the selected employee
from the records.
Alternative Cancel Deletion: If The user decides not to proceed with The Deletion,
Flows The system cancels The process.
Exceptions Invalid selection: If The selected employee is not found in The system,
The system notifies The user.

Use Case 20: Add Attendance

Column Description
Identifier UC-20
Use Case Add Attendance
Name
Actors Primary Actor: User
Description This use case allows the user to record attendance for employees.
Trigger The user indicates the need to add attendance records.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
employees in the system.
Postconditions POST-1: The attendance records are successfully added to the system.
Normal Flow 1. The user selects the option to add attendance. 2. The user chooses
the specific date and employees for attendance. 3. The user marks the
attendance for the selected employees. 4. The system validates the
attendance records. 5. The system adds the attendance records to the
database.
Alternative None
Flows
Exceptions Incomplete or Invalid attendance records: The system prompts The user
to provide valid information.

Use Case 21: View Attendance

Column Description
 Identifier UC-21
Use Case View Attendance
Name
Actors Primary Actor: User
Description This use case allows the user to view attendance records for employees.
Trigger The user indicates the need to view attendance records.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The user views the attendance records.
Normal Flow 1. The user selects the option to view attendance. 2. The user chooses
the specific date or date range for attendance records. 3. The system
retrieves and displays the attendance records.
Alternative None
Flows
Exceptions None

Use Case 22: Update Attendance

Column Description
Identifier UC-22
Use Case Update Attendance
Name
Actors Primary Actor: User
Description This use case allows the user to modify attendance records for
employees.
Trigger The user indicates the need to update attendance records.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
attendance records in the system.
Postconditions POST-1: The attendance records are successfully updated in the system.
Normal Flow 1. The user selects the option to update attendance. 2. The user chooses
the specific date and employees for attendance update. 3. The user
modifies the attendance status for the selected employees. 4. The
system validates the updated attendance records. 5. The system updates
the attendance records in the database.
Alternative None
Flows
Exceptions Incomplete or Invalid updated attendance records: The system prompts
The user to provide valid information.

Use Case 23: Payroll

Column Description
Identifier UC-23
Use Case Payroll
Name
Actors Primary Actor: User
Description This use case allows the user to manage payroll for employees.
Trigger The user indicates the need to process payroll.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
 employees with recorded attendance in the system.
Postconditions POST-1: The payroll is successfully processed, and employees are
compensated accordingly.
Normal Flow 1. The user selects the option for payroll processing. 2. The user chooses
the month. 3. The system calculates salaries based on attendance
records and predefined salary structures. 4. The system generates a
payroll report for the selected period.
Alternative None
Flows
Exceptions None

Use Case 24: Sale Trails

Column Description
Identifier UC-24
Use Case Sale Trails
Name
Actors Primary Actor: User
Description This use case allows the user to view and pay trails of sales transactions.
Trigger The user indicates the need to clear sale trails.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing sales
transactions in the system.
Postconditions POST-1: The user confirms the sales.
Normal Flow 1. The user selects the option to view sale trails. 2. The system retrieves
and displays a list of sales transactions with details. 3. The user can
confirm the payment. 4. The system validates and confirms the
payment.
Alternative None
Flows
Exceptions None

Use Case 25: Vendor Trails

Column Description
Identifier UC-25
Use Case Vendor Trails
Name
Actors Primary Actor: User
Description This use case allows the user to pay trails of vendor transactions.
Trigger The user indicates the need to pay vendor trails.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
vendor transactions in the system.
Postconditions POST-1: The user pays the vendor orders.
Normal Flow 1. The user selects the option to view vendor trails. 2. The system
retrieves and displays a list of vendor transactions with details. 3. The
user can pay the remaining payment. 4. The system confirms the
payment.
Alternative None
 Flows
Exceptions None

Use Case 26: General Ledger

Column Description
Identifier UC-26
Use Case General Ledger
Name
Actors Primary Actor: User
Description This use case allows the user to view all the transactions in the general
ledger.
Trigger The user indicates the need to view general ledger transactions.
Preconditions PRE-1: The user is logged into the system.
Postconditions POST-1: The user views the general ledger transactions.
Normal Flow 1. The user selects the option for the general ledger from the finance
module. 2. The system retrieves and displays all transactions recorded in
the general ledger.
Alternative None
Flows
Exceptions None

Use Case 27: Payables

Column Description
Identifier UC-27
Use Case Payables
Name
Actors Primary Actor: User
Description This use case allows the user to view payables for vendors.
Trigger The user indicates the need to view payables.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
vendor transactions in the system.
Postconditions POST-1: The payables are successfully viewed.
Normal Flow 1. The user selects the option for payables view. 2. The system retrieves
and displays a list of vendor transactions with all payments.
Alternative None
Flows
Exceptions None

Use Case 28: Receivables

Column Description
Identifier UC-28
Use Case Receivables
Name
Actors Primary Actor: User
 Description This use case allows the user to view receivables for sales transactions.
Trigger The user indicates the need to view receivables.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing sales
transactions in the system.
Postconditions POST-1: The receivables are successfully viewed.
Normal Flow 1. The user selects the option for receivables view. 2. The system
retrieves and displays a list of sales transactions.
Alternative None
Flows
Exceptions None

Use Case 29: Profit/Loss

Column Description
Identifier UC-29
Use Case Profit/Loss
Name
Actors Primary Actor: User
Description This use case allows the user to view the profit and loss statement.
Trigger The user indicates the need to view the profit and loss statement.
Preconditions PRE-1: The user is logged into the system. PRE-2: There are existing
financial transactions in the system.
Postconditions POST-1: The user views the profit and loss statement.
Normal Flow 1. The user selects the option for the profit and loss statement from the
finance module. 2. The system calculates and displays the profit and loss
statement based on financial transactions.
Alternative None
Flows
Exceptions None

Use Case 30: Profit Prediction

Column Description
Identifier UC-30
Use Case Profit Prediction
Name
Actors Primary Actor: User
Description This use case allows the user to predict future profits.
Trigger The user indicates the need to predict future profits.
Preconditions PRE-1: The user is logged into the system. PRE-2: There is sufficient
historical financial data available in the system.
Postconditions POST-1: The system generates and displays the predicted profit using
the Prophet Model.
Normal Flow 1. The user selects the option for profit prediction from the finance
module. 2. The system utilizes the Prophet Model to analyze historical
financial data and generates a prediction for future profits.
Alternative None
Flows
 Exceptions None

Use Case 31: View Employees

Column Description
Identifier UC-31
Use Case View Employees
Name
Actors Primary Actor: User
Description This use case allows the user to view a list of employees and their
relevant details.
Trigger The user indicates the need to access and view employee information.
Preconditions PRE-1: The user is logged into the system. PRE-2: Employee records exist
in the system.
Postconditions POST-1: The user successfully views the list of employees and their
details.
Normal Flow 1. The user selects the option to view employees from the employees
module. 2. The system retrieves and displays a list of employees along
with their relevant details.
Alternative None
Flows
Exceptions No employee records: If there are No Existing employee records, The
system notifies The user that there is No information to display.

 Functional Requirements
FR1: Authentication for Login
 The system shall authenticate users during the login process using secure credentials.
 Only registered users with valid credentials shall be allowed to log in.
FR2: Secure User Registration for Signup
 The system shall provide a secure user registration process for new users.
 User registration shall require valid and unique information, including email and
password.
FR3: Add Product to Inventory
 The system shall allow users to add new products to the inventory.
 Product information, including name, description, quantity, and price, must be captured
during the addition process.
FR4: Update Product Information
 Users with appropriate privileges shall be able to update product information in the
inventory.
 The system shall validate and apply the modifications to ensure accurate and up-to-date
 product records.
FR5: Delete Product from Inventory
 The system shall allow authorized users to delete products from the inventory.
 Deletion must be performed securely, and the system shall confirm the removal of the
product.
FR6: View Product Details
 Users shall be able to view detailed information about products in the inventory.
 The system shall display product details, including name, description, quantity, and
price.
FR7: View Vendor Information
 The system shall provide a view of vendor details.
 Users should be able to access information about vendors associated with products.
FR8: Add Vendor to System
 Authorized users shall be able to add new vendors to the system.
 Vendor information, including name and contact details, must be captured during the
addition process.
FR9: Vendor Payment Status
 The system shall include a vendor payment status.
 Users should be able to view payments to vendors.
FR10: Add Customer Information
 The system shall allow users to add new customer records.
 Customer information, including name, contact details, and sales history, must be
captured.
FR11: Update Customer Information
 Users with appropriate privileges shall be able to update customer information.
 The system shall validate and apply modifications to ensure accurate and up-to-date
customer records.
FR12: Delete Customer Record
 Authorized users shall be able to delete customer records securely.
 The system shall confirm the deletion and remove the customer from the system.
FR13: View Customer Details
 Users shall have the ability to view detailed information about customers.
 The system shall display customer details, including name, contact information, and
 sales history.
FR14: Add Sales Transaction
 The system shall allow users to add new sales transactions.
 Sales details, including customer information and transaction amount, must be
captured.
FR15: View Sales Records
 Users shall be able to view a list of sales records.
 The system shall display sales information, including details and amounts.
FR16: Sale Payment Status
 The system shall track and display the payment status of sales transactions.
 Users should be able to identify whether a sale has been paid or is pending.
FR17: Add Employees to HRM
 Authorized users shall be able to add new employees to the Human Resource
Management (HRM) module.
 Employee details, including personal information and job roles, must be captured.
FR18: Update Employee Information
 Users with appropriate privileges shall be able to update employee information.
 The system shall validate and apply modifications to ensure accurate and up-to-date
employee records.
FR19: Delete Employee Record
 The system shall allow authorized users to delete employee records securely.
 The system shall confirm the deletion and remove the employee from the HRM module.
FR20: Add Attendance Record
 Users shall be able to add attendance records for employees.
 The system shall capture attendance details, including day and month.
FR21: View Employee Attendance
 Users shall have the ability to view attendance records for employees.
 The system shall display attendance information, including dates and attendance status.
FR22: Update Attendance Record
 Users with appropriate privileges shall be able to update attendance records.
 The system shall validate and apply modifications to ensure accurate and up-to-date
attendance information.
FR23: Payroll Processing
 The system shall include functionality for payroll processing.
 Users should be able to calculate and process payroll based on employee attendance
and salary information.
FR24: Sale Trails
 Users shall be able to view trails of sales transactions and get paid for them.
FR25: Vendor Trails
 Users shall have the ability to pay for vendor-related activities.
FR26: General Ledger Management
 The system shall include a general ledger for financial transactions.
 Users should be able to view ledger transactions.
FR27: Payables
 The system shall provide functionality for viewing payables.
 Users should be able to track amounts payable to vendors.
FR28: Receivables
 The system shall include functionality for viewing receivables.
 Users should be able to track amounts receivable from customers.
FR29: Profit/Loss Calculation
 The system shall calculate and display profit/loss statements.
 Users should be able to view the financial performance of the organization.
FR30: Profit Prediction using Prophet Model
 The system shall include a prediction model, such as the Prophet Model, for forecasting
profits.
 Users should be able to view predicted financial outcomes based on historical data and
trends.

 Non-Functional Requirements
Usability
USE-1: The system shall have a consistent and intuitive user interface across all modules and
screens.
USE-2: The system shall adhere to accessibility guidelines.
USE-3: The system shall provide clear and informative error messages and feedback to users for
effective error handling and task completion.
Performance
PER-1: The system shall maintain fast response times less than 1 second.
PER-2: The system should be capable of handling a high volume of concurrent user requests.
PER-3: The system shall provide efficient search and retrieval capabilities, enabling users to
quickly find and access relevant information.
PER-4: The system shall minimize network latency to ensure responsive communication
between client and server components.
Security
SEC-1: The system shall enforce strict access control measures to ensure that only authorized
personnel have the appropriate privileges to access and modify data.

 Design and Architecture

This chapter encompasses the critical elements of the Software Design Description (SDD)
report, providing a comprehensive overview of the design and architectural aspects of the
ERP System.

 System Architecture
We adopted a Client-Server Architecture, where the system is divided into two distinct
components: the client and the server.
The client represents the user interface, providing a web-based platform accessible from various
devices and web browsers. It serves as the point of interaction for users, enabling them to input
data, access information, and perform tasks seamlessly.
The server component hosts the core system functionalities, including data processing, storage,
and business logic.
Fig 4.1 System Architecture

 . Data Representation

4.2.1. DFD Level 0

4.2.2. DFD Level 1

Customer Relationship Management (CRM)
 Manages customer records with information like names and contact details.
 Tracks customer interactions and sales history.
 Customer data is stored in a database for easy access.
Human Resource Management (HRM)
 Maintains employee records containing personal info, and roles.
 Supports attendance tracking.
 Employee data is organized in a structured database.
Inventory Management
 Handles product information such as name, description, quantity, and price.
 Uses an inventory database to track stock levels accurately.
 Ensures efficient stock management.
Database System
 MongoDB is the chosen database system.
 Adopts a document-oriented data modeling approach.
 Utilizes JSON-like documents for data representation.
 Provides flexibility for data storage and retrieval.
 Enables scalability and adaptability of the ERP System.
 4.3. Process Flow/Representation
Fig 4.3 Process Flow/Representation

 Design Models
In the development of our ERP System, we employ several design models to structure and
organize the software components effectively. These design models include:
Component-Based Design
Component-based design is central to our system architecture. It involves breaking down the
ERP system into modular components, each responsible for specific functionalities such as
finance management, CRM, HRM, and inventory management. This design approach promotes
reusability, making it easier to maintain and extend the system in the future.
Document-Oriented Data Modeling
To structure and manage data efficiently, we employ a document-oriented data modeling
approach. This design model aligns with our use of MongoDB as the database system.
MongoDB's flexibility in handling JSON-like documents allows us to store and retrieve data in a
way that suits the specific requirements of our ERP System.
Agile Design
We embrace an agile design approach, aligned with the Scrum methodology, to accommodate
changing requirements and evolving user needs. Agile design allows for flexibility and
adaptability throughout the development process, ensuring that the ERP System remains
responsive to emerging challenges and opportunities.

 Implementation

 Algorithm
1. Authentication using JWT Tokens
The system employs JWT Tokens to authenticate users, ensuring secure access to individual
accounts. This authentication mechanism enables multiple users to utilize the system
concurrently while maintaining distinct and protected user sessions.
2. Main Modules
The system is structured around four core modules: Inventory, Customers, Employees, and
Finance. These modules serve as the primary organizational units, each focusing on specific
aspects of the system's functionalities.
3. Inventory Module
The Inventory module encompasses key features such as View Products, View Vendors, Vendor
Payment Status, Add Product, and Add Vendor. These functionalities enable users to manage
and monitor product information, vendor details, and payment statuses efficiently.
4. Customer Module
Within the Customer module, users can access features such as View Customers, View Sales,
Sale Payment Status, Add Customer, and Add Sale. This module facilitates the management of
customer-related data, sales information, and payment statuses associated with sales
transactions.
5. Employees Module
The Employees module incorporates functionalities like Add Employees, Add Attendance, View
Employees, View Attendance, and Payroll. These features empower users to handle employee-
related tasks, including attendance tracking and payroll management.
6. Finance Module
The Finance module provides a comprehensive set of features, including Sales Trails, View
Vendor Trails, General Ledger, Payables, Receivables, Profit/Loss Analysis, and Profit Prediction
utilizing the Prophet Model. This module focuses on financial aspects, offering insights into
sales and vendor histories, ledger management, and advanced analytics for profit forecasting.

 External APIs
Table 5.1 shows the APIs we used in our ERP System
 Table 5.1: Details of APIs used in the project

Name of API Description of Purpose of Function/Class Name

API Usage
REST APIs Communication Facilitates data Various functions across
interface exchange and modules.
allowing system
interaction with integration.
external
systems/devices.
Flask API for Flask API Integrates ‘ProfitPrediction’ class
Prophet Model implementation Prophet Model in Finance module.
for serving for profit
Prophet Model prediction in
predictions. the Finance
module.

 User Interface
Login Page

Sign Up Page

Dashboard Light Mode

Dashboard Dark Mode

View Products

Add Vendor

View Customers
 Payroll

General Ledger

Profit Forecast

 Testing and Evaluation

This chapter describes the overall testing of our system “The ERP System”

 Manual Testing
Manual testing includes unit testing and functional testing of the system.

 System testing
After the successful development of the system, rigorous testing is imperative to
ensure that the system functions as intended and meets the predefined
requirements. System testing serves the critical purpose of unveiling any hidden
errors that may not be apparent to users. This testing phase comprises several
essential types, including unit testing, functional testing, and integration testing.
Each type of testing plays a unique role in ensuring the robustness and reliability
of the ERP system.

 Unit Testing
Once the system has been successfully developed

Unit Testing 1: Login

Testing Objective: To ensure the login form is working correctly
No. Test case/Test Attribute and value Expected result Result
script
1 Verify user login email: Store Password: Successfully log into the Pass
with correct data Store@gmail.com main page of the system
2 Verify user login email: Store Password: Display an error message Pass
with incorrect Store@gmail indicating invalid
password credentials
3 Verify user login email: Display an error message Pass
with empty fields prompting to fill in both
Password: fields

Unit Testing 2: Signup

Testing Objective: To ensure the signup form is working correctly
No. Test case/Test Attribute and value Expected result Result
script
1 Verify user signup Username: abc Successfully create a new user Pass
with valid data account
Email:
abc@gmail.com
Password:
abc@gmail.com
2 Verify user signup email: Display an error message Pass
with existing email Store@gmail.com indicating username already
exists
Password:
Store@gmail.com
3 Verify user signup email: Store Display an error message Pass
with weak indicating password strength
password Password: Store requirements

Unit Testing 3: Add Product

Testing Objective: To ensure the add product is working correctly
No. Test case/Test Attribute and value Expected result Result
script
1 Verify adding a Product Name: [valid Product is successfully Pass
product with valid name] Quantity: [valid added to the inventory
data quantity]
2 Verify adding a Product Name: [empty] Display an error message Pass
product with empty Quantity: [empty] prompting to fill in
fields required fields
3 Verify adding a Product Name: [existing Display an error message Pass
duplicate product name] Quantity: [valid indicating duplicate
quantity] product
 Unit Testing 4: Update Product
Testing Objective: To ensure the update product is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify updating a Product Product quantity is successfully Pass
product with valid data name: Lux updated
New Quantity:
100
2 Verify updating a Product Display an error message Pass
product with empty name: prompting to fill in required
fields fields
New Quantity:
3 Verify updating a non- Product Display an error message Pass
existing product name: indicating product not found
New Quantity:
50

Unit Testing 5: View product

Testing Objective: To ensure the view product is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify viewing a specific Product name: Product details are displayed Pass
product Mouse correctly
2 Verify viewing all No specific List of all products is displayed Pass
products attributes
3 Verify viewing a non- Product name: Display an error message Pass
existing product Car indicating product not found

Unit Testing 6: View Vendor

Testing Objective: To ensure the view vendor is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify viewing a Vendor name: Vendor details are displayed Pass
specific vendor Abdullah correctly
2 Verify viewing all No specific List of all vendors is displayed Pass
vendors attributes
3 Verify viewing a non- Vendor name: Display an error message Pass
existing vendor Shakeel indicating vendor not found

Unit Testing 7: Add Vendor

Testing Objective: To ensure the add vendor is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify adding a Vendor Name: Saqib Vendor is successfully added Pass
vendor with valid Contact: 1234567897
data
2 Verify adding a Vendor Name: [empty] Display an error message Pass
vendor with empty Contact: [empty] prompting to fill in required
fields fields

Unit Testing 8: Vendor Payment System

Testing Objective: To ensure the Vendor Payment System is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify recording Vendor ID: [valid ID] Payment is successfully Pass
payment for an Amount: [valid amount] recorded
existing vendor
2 Verify recording Vendor ID: [non-existing Display an error message Pass
payment for a non- ID] Amount: [valid indicating vendor not
existing vendor amount] found
3 Verify recording Vendor ID: [valid ID] Display an error message Pass
payment with invalid Amount: [invalid indicating invalid amount
amount amount]

Unit Testing 9: Signup

Testing Objective: To ensure the signup form is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify adding a Customer Name: [valid Customer is successfully Pass
customer with valid name] Contact: [valid added
data contact]
2 Verify adding a Customer Name: Display an error message Pass
customer with [empty] Contact: prompting to fill in
empty fields [empty] required fields
3 Verify adding a Customer Name: Display an error message Pass
duplicate customer [existing name] Contact: indicating duplicate
[valid contact] customer

Unit Testing 10: Add Customer

Testing Objective: To ensure the Add Customer is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify updating a Customer ID: [valid ID] Customer contact is Pass
customer with valid New Contact: [valid successfully updated
data contact]
2 Verify updating a Customer ID: [valid ID] Display an error message Pass
customer with New Contact: [empty] prompting to fill in
empty fields required fields
3 Verify updating a Customer ID: [non- Display an error message Pass
non-existing existing ID] New Contact: indicating customer not
customer [valid contact] found
 Unit Testing 11: Delete Customer
Testing Objective: To ensure the delete customer is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify deleting an existing Customer ID: Customer is successfully Pass
customer [valid ID] deleted
2 Verify deleting a non-existing Customer ID: Display an error message Pass
customer [non-existing ID] indicating customer not found
3 Verify deleting a customer Customer ID: Display a warning message Pass
with associated transactions [valid ID] indicating associated
transactions

Unit Testing 12: View Customer

Testing Objective: To ensure the view customer is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify viewing a specific Customer ID: [valid Customer details are displayed Pass
customer ID] correctly
2 Verify viewing all No specific List of all customers is displayed Pass
customers attributes
3 Verify viewing a non- Customer ID: [non- Display an error message Pass
existing customer existing ID] indicating customer not found

Unit Testing 13: Add Sale

Testing Objective: To ensure the add sale is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify adding a sale Sale details: [valid Sale is successfully added Pass
with valid data data]
2 Verify adding a sale Sale details: [empty] Display an error message Pass
with empty fields prompting to fill in required fields
3 Verify adding a Sale details: Display an error message indicating Pass
duplicate sale [existing sale data] duplicate sale

Unit Testing 14: View Sale

Testing Objective: To ensure the view sale working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify viewing a specific Sale ID: [valid ID] Sale details are displayed correctly Pass
sale
2 Verify viewing all sales No specific List of all sales is displayed Pass
attributes
3 Verify viewing a non- Sale ID: [non- Display an error message indicating Pass
existing sale existing ID] sale not found
 Unit Testing 15: Payment Status
Testing Objective: To ensure the payment system is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify checking payment status Sale ID: [valid ID] Display payment status as Pass
of a paid sale 'Paid'
2 Verify checking payment status Sale ID: [valid ID] Display payment status as Pass
of an unpaid sale 'Unpaid'
3 Verify checking payment status Sale ID: [non- Display an error message Pass
of a non-existing sale existing ID] indicating sale not found

Unit Testing 16: Add Employee

Testing Objective: To ensure the add employee form is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify adding an Employee details: [valid Employee is successfully added Pass
employee with valid data]
data
2 Verify adding an Employee details: Display an error message Pass
employee with empty [empty] prompting to fill in required
fields fields
3 Verify adding a Employee details: Display an error message Pass
duplicate employee [existing employee indicating duplicate employee
data]

Unit Testing 17: Update Employee details

Testing Objective: To ensure the update employee details form is working
correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify updating Employee ID: [valid ID] Employee details are Pass
employee details with New Role: [valid role] successfully updated
valid data
2 Verify updating Employee ID: [valid ID] Display an error message Pass
employee details with New Role: [empty] prompting to fill in required
empty fields fields
3 Verify updating a non- Employee ID: [non- Display an error message Pass
existing employee existing ID] New Role: indicating employee not
[valid role] found
 Unit Testing 18: Delete Employee
Testing Objective: To ensure the signup form is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify deleting an existing Employee ID: [valid Employee is successfully Pass
employee ID] deleted
2 Verify deleting a non- Employee ID: [non- Display an error message Pass
existing employee existing ID] indicating employee not found
3 Verify deleting an employee Employee ID: [valid Display a warning message Pass
with associated data ID] indicating associated data

Unit Testing 19: Add Attendance

Testing Objective: To ensure the add attendance is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify adding attendance Employee ID: [valid ID] Attendance is successfully Pass
for an existing employee Date: [valid date] added
2 Verify adding attendance Employee ID: [non- Display an error message Pass
for a non-existing existing ID] Date: [valid indicating employee not
employee date] found
3 Verify adding attendance Employee ID: [valid ID] Display an error message Pass
with an invalid date Date: [invalid date] indicating invalid date

Unit Testing 20: View attendance

Testing Objective: To ensure the view attendance is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify viewing attendance for Employee ID: [valid Attendance details are Pass
a specific employee ID] displayed correctly
2 Verify viewing attendance for No specific List of all attendance records is Pass
all employees attributes displayed
3 Verify viewing attendance for Employee ID: [non- Display an error message Pass
a non-existing employee existing ID] indicating employee not found

Unit Testing 21: Update Attendance

Testing Objective: To ensure the update attendance is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify updating Employee ID: [valid ID] Date: Attendance status is Pass
attendance for an [valid date] New Status: [valid successfully updated
existing employee status]
2 Verify updating Employee ID: [non-existing ID] Display an error message Pass
 attendance for a non- Date: [valid date] New Status: indicating employee not
existing employee [valid status] found
3 Verify updating Employee ID: [valid ID] Date: Display an error message Pass
attendance with an [valid date] New Status: indicating invalid status
invalid status [invalid status]

Unit Testing 22: Payroll

Testing Objective: To ensure the payroll is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify generating payroll Employee ID: [valid ID] Payroll details are Pass
for an existing employee successfully generated
2 Verify generating payroll Employee ID: [non- Display an error message Pass
for a non-existing existing ID] indicating employee not
employee found
3 Verify generating payroll Employee ID: [valid ID] Display an error message Pass
with invalid data Payroll details: [invalid indicating invalid data
data]

Unit Testing 23: sale trails

Testing Objective: To ensure the view sale trails is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify viewing sale trails for a sale ID: [valid ID] Sale trails for the product are Pass
specific sale displayed correctly
2 Verify viewing sale trails for Sale IDs List of sale trails for all products Pass
all sale is displayed
3 Verify viewing sale trails for a sale ID: [non- Display an error message Pass
non-existing sale existing ID] indicating product not found

Unit Testing 24: Vendor trails

Testing Objective: To ensure the view vendor trails is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify viewing vendor trails for Purchase ID: [valid Vendor trails are displayed Pass
a specific purchase ID] correctly
2 Verify viewing vendor trails for Purchase IDs List of vendor trails for all Pass
all purchase purchases are displayed
3 Verify viewing vendor trails for Purchase ID: [non- Display an error message Pass
a non-existing purchase existing ID] indicating vendor not found

Unit Testing 25: General Ledger

Testing Objective: To ensure the general ledger is working correctly
No. Test case/Test Attribute and value Expected result Result
script
1 Verify viewing Journal entry, Amount, General ledger entries for the Pass
general ledger date , description specified time period are displayed
correctly

Unit Testing 26: Payables

Testing Objective: To ensure the payables is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify viewing payables for Journal entry, Amount, Payables for the vendor are Pass
a specific purchase date ,description displayed correctly
2 Verify viewing payables for Journal entry, Amount, List of payables for all Pass
all unpaid purchase date ,description vendors is displayed
3 Verify viewing payables for Journal entry, Amount, Display an error message Pass
a non-existing purchase date ,description indicating vendor not found

Unit Testing 27: Receivables

Testing Objective: To ensure the receivables is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify viewing receivables for Journal entry, Amount, Receivables for the sale Pass
a specific unpaid sale date ,description are displayed correctly
2 Verify viewing receivables for Journal entry, Amount, List of receivables for all Pass
all unpaid sales date ,description sales is displayed
3 Verify viewing receivables for Journal entry, Amount, Display no data Pass
a non-existing sale date ,description

Unit Testing 28: Profit/Loss

Testing Objective: To ensure the calculation of profit/loss is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify calculating Month:[valid Profit/loss for the specified time Pass
profit/loss for a specific month] period is calculated and displayed
month correctly
2 Verify calculating overall No specific Overall profit/loss is calculated and Pass
profit/loss attributes displayed correctly

Unit Testing 29: Prediction of Profit

Testing Objective: To ensure the prediction of profit is working correctly
No. Test case/Test script Attribute and value Expected result Result
1 Verify predicting profit profit data: [valid Profit prediction is generated Pass
using valid data data] and displayed correctly
2 Verify predicting profit with profit data: Display an error message Pass
incomplete data [incomplete data] indicating incomplete data
3 Verify predicting profit with profit data: [invalid Display an error message Pass
invalid data data] indicating invalid data

Unit Testing 30: Logout

Testing Objective: To ensure the logout is working correctly
No. Test case/Test script Attribute and Expected result Result
value
1 Verify logging out from the No specific User is successfully logged out Pass
system attributes
2 Verify attempting to access No specific Display a login page, indicating Pass
secured pages after logout attributes unauthorized access
3 Verify attempting to perform No specific Display a login page, indicating Pass
actions after logout attributes unauthorized access

 Functional Testing
The functional testing will take place after the unit testing. In this functional
testing, the functionality of each of the module is tested. This is to ensure that
the system produced meets the specifications and requirements.

 Functional Testing 1: Inventory Module

Objective: To ensure that the inventory module of the system is working
correctly with all the functionalities
No. Test Case/Test Attribute and Value Expected Result Result
Script
1.1 View Products - Successfully view the list of Pass
products.
1.2 View Vendors - Successfully view the list of Pass
vendors.
1.3 Vendor Vendor ID - V001 View the payment status of the Pass
Payment specified vendor.
Status
1.4 Add Product Product Name - NewProduct, Successfully add a new product Pass
Quantity - 50 to the inventory.
1.5 Add Vendor Vendor Name - NewVendor, Successfully add a new vendor Pass
Contact - VendorContact to the system.
1.6 Update Product ID - P001, New Successfully update the Pass
 Product Quantity - 100 quantity of an existing product.
1.7 Update Vendor ID - V002, New Successfully update the contact Pass
Vendor Contact - UpdatedContact information of an existing
vendor.
1.8 Delete Product Product ID - P002 Successfully delete an existing Pass
product from the inventory.
1.9 Delete Vendor Vendor ID - V003 Successfully delete an existing Pass
vendor from the system.

 Functional Testing 2: Customers Module

Objective: To ensure that the customers module of the system is working
correctly with all the functionalities
No. Test Case/Test Attribute and Value Expected Result Result
Script
2.1 View - Successfully view the list of Pass
Customers customers.
2.2 View Sales - Successfully view the list of sales Pass
transactions.
2.3 Sale Payment Sale ID - S001 View the payment status of the Pass
Status specified sale.
2.4 Add Customer Customer Name - NewCustomer, Successfully add a new Pass
Contact - CustomerContact customer to the system.
2.5 Add Sale Product ID - P003, Customer ID - Successfully add a new sale Pass
C001, Quantity - 10 transaction to the system.
2.6 Update Customer ID - C002, New Successfully update the contact Pass
Customer Contact - UpdatedContact information of an existing
customer.
2.7 Update Sale Sale ID - S002, New Quantity - 20 Successfully update the quantity Pass
of an existing sale transaction.
2.8 Delete Customer ID - C003 Successfully delete an existing Pass
Customer customer from the system.
2.9 Delete Sale Sale ID - S003 Successfully delete an existing Pass
sale transaction from the
system.

 Functional Testing 3: Employees Module

Objective: To ensure that the employees module of the system is working
correctly with all the functionalities
No. Test Case/Test Attribute and Value Expected Result Result
Script
3.1 Add Employee Name - Successfully add a new Pass
Employees NewEmployee, Role - employee with the specified
Manager role.
3.2 Add Employee ID - E001, Date - Successfully record the Pass
Attendance 2023-03-01, Status - attendance of an employee
 Present for a specific date.
3.3 View - Successfully view the list of Pass
Employees employees.
3.4 View Employee ID - E002 Successfully view the Pass
Attendance attendance record of a specific
employee.
3.5 Update Employee ID - E003, New Successfully update the role of Pass
Employees Role - Supervisor an existing employee.
3.6 Update Attendance ID - A001, New Successfully update the Pass
Attendance Status - Absent attendance status for a
specific record.
3.7 Payroll Employee ID - E004, Month Successfully generate the Pass
- March 2023 payroll for an employee for
the specified month.
3.8 Delete Employee ID - E005 Successfully delete an existing Pass
Employees employee from the system.

 Functional Testing 4: Finance Module

Objective: To ensure that the finance module of the system is working
correctly with all the functionalities
4. View Sales - Successfully view the sales trails, including Pass
1 Trails transaction details.
4. View Vendor - Successfully view the vendor trails, including Pass
2 Trails transaction details.
4. General Ledger - Successfully view the general ledger, Pass
3 including all financial transactions.
4. Payables Vendor ID - V001, Successfully record a payable transaction for Pass
4 Amount - $500 a specific vendor.
4. Receivables Customer ID - C001, Successfully record a receivable transaction Pass
5 Amount - $700 for a specific customer.
4. Profit/Loss - Successfully view the overall profit/loss Pass
6 statement for the business.
4. Profit Month - April 2023 Successfully predict the profit for the Pass
7 Prediction specified month using the Prophet Model.

 Integration Testing
 Integration Testing 1: To ensure the Customer Module integrated with
Inventory Module and Finance Module is working correctly.
No. Test Case/Test Attribute Expected Result Result
Script and Value
1.1 Add Customer and - Successfully add a new customer and Pass
Add Sale in record a sale transaction. Check if the
Customer Module customer information is updated in the
Finance Module.
 1.2 View Customer in - View customer details from the Pass
Inventory Module Inventory Module, ensuring data
consistency between modules.
1.3 View Customer - View the trails in the Finance Module to Pass
Trails in Finance verify that customer-related
Module transactions are correctly logged.

 Integration Testing 2: To ensure the Product Module integrated with Finance

Module and Customers Module is working correctly.
No. Test Case/Test Attribute Expected Result Result
Script and Value
2.1 Add Product and - Successfully add a new product and Pass
Add Sale in record a sale transaction. Check if the
Product Module product information is updated in the
Finance Module.
2.2 View Product in - View product details from the Customers Pass
Customers Module Module, ensuring data consistency
between modules.
2.3 View Product Trails - View the trails in the Finance Module to Pass
in Finance Module verify that product-related transactions
are correctly logged.

 Integration Testing 3: To ensure the Employees Module with Finance Module

is working correctly.
No. Test Case/Test Script Attribute Expected Result Result
and Value
3.1 Add Employee and - Successfully add a new employee and Pass
Record Payroll in record payroll. Check if the employee
Employees Module payroll information is updated in the
Finance Module.
3.2 View Employee Trails - View the trails in the Finance Module Pass
in Finance Module to verify that employee-related
transactions and payroll records are
correctly logged.

 Automated Testing:

 Tools used:
The following table shows the tools used in automated testing
Tools used
1 Thunder A REST client extension for Visual API Testing - REST APIs and Pass
. Client Studio Code. Flask API
 Conclusion
The development and implementation of the ERP System represent a significant milestone in
addressing the organizational needs for streamlined processes, efficient data management, and
improved decision-making. The adoption of a Client-Server Architecture, component-based
design, and agile methodologies has contributed to the creation of a robust and flexible system.
The ERP System's comprehensive modules, including Inventory, Customers, Employees, and
Finance, ensure that key aspects of business operations are seamlessly integrated.
The testing phase, encompassing manual and automated testing, has been instrumental in
ensuring the system's reliability, functionality, and performance. Through unit, functional, and
integration testing, potential issues were identified and addressed, guaranteeing a high-quality
software product.
As the ERP System moves from development to deployment, its success will be measured by its
impact on organizational efficiency and productivity. User feedback and continuous
improvement will be essential in refining the system's performance and addressing any
emerging requirements.