កិច្ចការសិកាស្រាវស្រាវ

ល ស្រើ រធានរទ

Building a POS System Project

រលស្ររៀនលោយាស្រ្ាាចារយ

ជួរ ភារ ិនទ

សិកាស្រាវស្រាវលោយនិសស ិតល្មោះ

១. រស់ ច្រ ិយា

២. ល ឿរ ថារ

ថាាក់ ររ ិញ្ញ
ា រស្រត

ឯកលទស វិទាាស្រ្សាកុំព្យទ័
ូ រ

ជុំនាន់ទី២០ ឆ្ា ុំទី៤ ឆមាសទី១

ឆ្ា ុំសិកា ២០២៥_២០២៦

 Contents
I. Introduction 1-4
1. Purpose and preparing project 1-2
[Link] and Technologies Used 2-4
II. System Analyse and Design 5-7
1. System Analyse 5-6
2. System Design 6-7
III. Functional and Non- Functional Requirements 8-10
3.1. Functional Requirements 8-9
3.2. Non- Functional Requirements 9-10
IV. Database Overview 11-13
4.1. Database Overview 11-12
4.2. Database Table and Description 12-13
V. API Overview 14-18
1. Definition 14-15
[Link] concept 15-16
3. Role of API in POS 16-17
4. Benefit of API 16-17
5. Example of API Request in POS 17-18
VI. Implementation 19-23

6.1 Implementation Overview 19-20

6.2 Project Structure 19-20

6.3 Models 19-20

6.4 Database Context 20-21

6.5 Controllers Implementation 21-22

6.6 Implementation Notes 22-23

6.7 Next Steps 22-23

VII. Testing, Result and Conclusion 24

Reference 25
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Unit1

Introduction

1. Purpose and Project preparing

1.1. Purpose / Motivation

The purpose of this project is to design and develop a web-based Point of Sale (POS)
system using [Link] Web API (.NET) to manage sales transactions in a retail or
service environment such as a shop or café.
For small businesses, manual sales handling can be time-consuming and error prone.
This POS system aims to automate core business operations, including sales
registration, inventory management, receipt generation, and daily sales tracking.
The main objective of this project is to build a Minimum Viable Product (MVP) POS
system that is:

• Reliable and stable

• Easy to use for cashiers and managers
• Maintainable and extensible for future enhancements

1.2. Project Scope

The proposed POS system will provide the following core functionalities through an
[Link] Web API backend and a web-based frontend:

➢ Included Features

• Product catalog management

• Sales transactions (cash and card payments)
• Receipt generation and printing
• Basic inventory tracking (stock in/out)
• Daily sales reports
• User authentication and role management (cashier, manager)

➢ Excluded Features (Initial Phase)

• Loyalty or membership programs

• Multi-store synchronization
• Advanced analytics and dashboards
• Marketing or third-party service integrations

These advanced features may be added in future versions of the system.

1
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

1.3. Stakeholders

The key stakeholders involved in this POS system project include:

• Store Owner / Manager – oversees operations and views reports

• Cashiers / POS Operators – perform daily sales transactions
• IT / Maintenance Staff – manage system setup, updates, and troubleshooting
• Accountants (optional) – use sales reports for financial analysis

1.4. Constraints and Assumptions

• The POS system will run as a web application using [Link] Web API,
accessible on desktop terminals or tablets.
• The system may operate on a local machine or small LAN environment.
• Supported hardware includes:
o Barcode scanner
o Receipt printer
o Cash drawer
• The target user base is small, typically a few POS terminals.
• Internet connectivity may be limited or intermittent; therefore, the system should
remain stable and handle failures gracefully without data corruption.

1.5. Risks

Potential risks identified in this project include:

• Hardware compatibility issues, especially with receipt printers and barcode

scanners
• Data loss due to system crashes or improper shutdowns
• Transaction consistency problems, such as incomplete payment processing
• Security risks, including unauthorized access, data tampering, or weak
authentication

Proper error handling, validation, and security mechanisms will be considered to

minimize these risks.

2. Tools and Technologies Used

2.1. Visual Studio

Visual Studio is an Integrated Development Environment (IDE) developed by Microsoft.

It provides a complete platform for developing, testing, and debugging applications. In
this project, Visual Studio is used to build the POS System Web API using [Link]
(.NET) and to manage the frontend and backend code.

2
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Visual Studio is suitable for this POS system project because it supports modern web
development and API-based architectures.

Key Features:

• Powerful code editor with IntelliSense for C# and [Link]

• Built-in debugging and error-handling tools
• Easy creation of [Link] Web API projects
• Integration with SQL Server and Entity Framework
• Git and GitHub integration for version control

In summary, Visual Studio provides an efficient and reliable environment to develop,

test, and maintain the POS System Web API.

2.2 SQL Server

SQL Server is a Relational Database Management System (RDBMS) developed by

Microsoft. In this POS System project, SQL Server is used as the backend database to
store and manage all system data.

The database stores important POS-related information such as:

• Products
• Categories
• Users (Cashiers, Managers)
• Sales transactions
• Inventory records
• Payment details

Reasons for Using SQL Server:

• Structured Data Storage: Data is stored in tables with relationships, making

management efficient.
• Data Integrity: Ensures accuracy and consistency of sales and inventory data.
• Security: Supports authentication, authorization, and data protection.
• Scalability: Can handle increasing transactions as the business grows.

The POS System performs CRUD operations using SQL Server:

• Create – Add new products, users, and sales records

• Read – Retrieve product lists, transaction history, and reports
• Update – Modify product prices, stock levels, and user details
• Delete – Remove obsolete or incorrect records.

3
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

2.3. C# Programming Language

C# is an object-oriented programming language developed by Microsoft and fully

supported by the .NET framework. It is used to implement the business logic and API
controllers of the POS System.

In this project, C# is responsible for:

• Creating RESTful API endpoints (GET, POST, PUT, DELETE)

• Processing sales transactions
• Validating user input and business rules
• Handling authentication and authorization
• Communicating with SQL Server using Entity Framework Core

C# enables clean, secure, and maintainable code, making it an ideal language for
building a scalable POS System Web API.

2.4. [Link] Web API (.NET)

[Link] Web API is a framework used to build HTTP-based services. In this POS
system, it serves as the core backend, allowing the frontend to communicate with the
database through API requests.

Benefits:

• Supports RESTful architecture

• Returns data in JSON format
• Easy integration with web or mobile frontends
• High performance and security

4
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Unit2

System Analyze and Design

1. System Analyze

1.1 System Overview

The Point of Sale (POS) System is a web-based application developed using

[Link] Web API (.NET). The system is designed to automate sales transactions and
inventory management for small retail businesses such as shops and cafés.

The POS system allows authorized users to manage products, process sales, generate
receipts, and view sales reports through a web interface. The backend logic is handled
by [Link] Web API, which communicates with a relational database to store and
retrieve data efficiently.

1.2 Existing System Analysis

In many small businesses, sales and inventory are managed manually using notebooks
or spreadsheets. This traditional approach has several limitations:

• High risk of human error

• Difficulty in tracking daily sales
• No real-time inventory updates
• Time-consuming report generation
• Data loss due to poor record keeping

These problems create a need for an automated POS system.

1.3 Proposed System

The proposed POS system replaces the manual process with a digital, web-based
solution. The system improves accuracy, speed, and data security.

Advantages of the Proposed System:

• Faster sales processing

• Accurate inventory tracking
• Secure data storage
• Easy access to sales reports
• Reduced paperwork

5
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

1.4 System Architecture

The system follows a three-tier architecture:

1. Presentation Layer

• Web-based user interface (HTML, CSS, Bootstrap, JavaScript)

• Used by cashiers and managers to interact with the system

2. Application Layer

• [Link] Web API (.NET)

• Handles business logic, validation, and API endpoints

3. Data Layer

• SQL Server database

• Stores products, users, sales, and inventory data

2. System Design
2.1
Data Flow Diagram (DFD – Level 0)

Entities:

• Cashier
• Manager

Processes:

• Login Authentication
• Sales Transaction
• Product Management
• Inventory Update
• Report Generation

Data Stores:

• User Database
• Product Database
• Sales Database

6
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

2.2 Use Case Description

Actors:

• Cashier
• Manager (Admin)

Main Use Cases:

• Login to system
• Manage products
• Perform sales transaction
• Print receipt
• View daily sales report
• Manage users

2.3 Security Considerations

• User authentication using login credentials

• Role-based access control (Cashier / Manager)
• Secure API endpoints
• Input validation to prevent data manipulation

2.4 Feasibility Study

Technical Feasibility

• Uses widely supported technologies (.NET, SQL Server)

• Can run on standard desktop or tablet devices

Economic Feasibility

• Reduces operational costs by automating processes

• Low maintenance cost

Operational Feasibility

• Simple interface suitable for non-technical users

• Minimal training required

7
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Unit3
Functional and Non-Functional Requirements

3.1 Functional Requirements

Functional requirements describe what the POS system must do. These requirements
define the main features and operations of the system.

3.1.1 User Authentication

• The system shall allow users to log in using a username and password.
• The system shall support different user roles:
o Cashier
o Manager (Admin)
• The system shall restrict access based on user roles.
• The system shall allow users to log out securely.

3.1.2 Product Management

• The system shall allow the manager to add new products.

• The system shall allow the manager to update product details such as:
o Product name
o Price
o Quantity
o Category
• The system shall allow the manager to delete products.
• The system shall display a list of available products.

3.1.3 Sales Transaction Management

• The system shall allow cashiers to create a new sales transaction.

• The system shall automatically calculate:
o Total price
o Discounts (if any)
• The system shall support multiple payment methods:
o Cash
o Card
• The system shall generate a receipt for each transaction.

8
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

3.1.4 Inventory Management

• The system shall automatically update product stock after each sale.
• The system shall notify the manager when stock levels are low.
• The system shall allow managers to view inventory status.

3.1.5 Reporting Module

• The system shall generate daily sales reports.

• The system shall display sales history by date.
• The system shall allow managers to view total revenue.

3.1.6 User Management

• The system shall allow the manager to create new user accounts.
• The system shall allow the manager to update user information.
• The system shall allow the manager to delete users.
• The system shall assign roles to users.

3.2 Non-Functional Requirements

Non-functional requirements describe how the system performs.

3.2.1 Performance

• The system shall respond to user requests within an acceptable time.

• The system shall support multiple users simultaneously.

3.2.2 Security

• The system shall protect user data using authentication and authorization.
• Passwords shall be stored securely.
• The system shall prevent unauthorized access.

3.2.3 Reliability

• The system shall not crash during normal operation.

• The system shall handle errors gracefully.
• Sales data shall not be lost during transactions.

9
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

3.2.4 Usability

• The system shall be easy to use for cashiers with minimal training.
• The user interface shall be clear and simple.

3.2.5 Maintainability

• The system shall be easy to update and maintain.

• Code shall follow clean and modular design principles.

3.3 System Constraints

• The system is developed using [Link] Web API (.NET).

• The database used is SQL Server.
• The system is intended for small-scale retail businesses.
• Internet connectivity may be limited.

3.4 Assumptions

• Users have basic computer skills.

• Hardware devices such as barcode scanners and receipt printers are available.
• The system is deployed on a local machine or small network.

10
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Unit4
Database Overview

4.1 Database Overview

The POS System uses a relational database to store and manage all application data.
The database is designed using SQL Server and follows normalization principles to
reduce data redundancy and ensure data integrity.

The database stores information related to:

• Users and roles

• Products and categories
• Sales transactions
• Sales details
• Inventory

4.2 Database Tables Description

4.2.1 Users Table

This table stores information about system users such as cashiers and managers.

Field Name
UserId INT (PK)
Username VARCHAR(50)
PasswordHash VARCHAR(255)
Role VARCHAR(20)
CreatedAt DATETIME

4.2.2 Categories Table

This table stores product categories:

Field Name Data Type

CategoryId INT (PK)

CategoryName VARCHAR(100)

11
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

4.2.3 Products Table

This table stores product information.

Field Name Data Type

ProductId INT (PK)

ProductName VARCHAR(100)

Price DECIMAL(10,2)

Quantity INT

CategoryId INT (FK)

CreatedAt DATETIME

4.2.4 Sales Table

This table stores each sales transaction.

Field Name Data Type

SaleId INT (PK)

SaleDate DATETIME

TotalAmount DECIMAL(10,2)

PaymentMethod VARCHAR(20)

UserId INT (FK)

4.2.5 SaleDetails Table

This table stores products included in each sale.

SaleDetailId INT (PK)

SaleId INT (FK)

ProductId INT (FK)

12
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Quantity INT

UnitPrice DECIMAL(10,2)

4.3 Entity Relationship (ER) Diagram Description

• One Category can have many Products

• One User can create many Sales
• One Sale can have many SaleDetails
• Each SaleDetail references one Product

This relationship ensures accurate tracking of sales and inventory.

4.4 Database Constraints

• Primary keys ensure each record is unique.

• Foreign keys enforce relationships between tables.
• NOT NULL constraints prevent missing important data.
• Referential integrity ensures valid data connections.

4.5 Sample SQL Table Creation

CREATE TABLE Products (

ProductId INT IDENTITY PRIMARY KEY,
ProductName VARCHAR(100) NOT NULL,
Price DECIMAL(10,2) NOT NULL,
Quantity INT NOT NULL,
CategoryId INT,
CreatedAt DATETIME DEFAULT GETDATE(),
FOREIGN KEY (CategoryId) REFERENCES Categories(CategoryId)
);

4.6 Database Access Method

The database is accessed using Entity Framework Core, which allows:

• Object-oriented data manipulation

• Reduced SQL complexity
• Secure and efficient database operations

13
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Unit5
API Overview

1. Definition

An API (Application Programming Interface) is a set of rules and protocols that

allows different software applications to communicate with each other.
In the context of the POS System, the API allows the frontend (web or mobile
application) to communicate with the backend (database and business logic).

2. Key Concepts

1. Endpoint – A specific URL where the API can be accessed.

o Example: /api/products returns a list of all products.
2. HTTP Methods – Define the type of operation:
o GET – Retrieve data
o POST – Add new data
o PUT – Update existing data
o DELETE – Remove data
3. Request & Response – Data sent to and received from the API, usually in
JSON format.
o Request: Contains data from the client
o Response: Contains data from the server
4. Status Codes – Indicate the result of an API request:
o 200 OK – Success
o 201 Created – New data successfully added
o 400 Bad Request – Invalid input
o 401 Unauthorized – Authentication failed
o 404 Not Found – Data not found
o 500 Internal Server Error – Server error
5. Authentication & Authorization – Security mechanisms to ensure only
authorized users can access certain endpoints.
o Example: Cashiers can create sales but cannot delete users.

3. Role of API in POS System

• Connects frontend and backend efficiently.

• Handles CRUD operations on products, users, categories, and sales.
• Ensures data integrity and security.
• Returns data in a standard format (JSON), making it easy for frontend
developers to display information.

14
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

• Supports scalability for future integrations like mobile apps, reporting

dashboards, or third-party payment systems.

4. Benefits of Using API in POS System

1. Separation of Concerns – Backend logic and frontend display are independent.

2. Reusability – The same API can be used for multiple platforms (web, mobile,
tablet).
3. Security – Sensitive operations are protected via authentication.
4. Flexibility – Easy to expand or integrate new features in the future.
5. Efficiency – Reduces redundant database operations and improves
performance.

5. Example API Request in POS System

GET Products End1point:

GET [Link]
Headers:
Authorization: Bearer <token>

Response:

[
{
"productId": 1,
"productName": "Coffee",
"price": 2.50,
"quantity": 100,
"categoryId": 1
},
{
"productId": 2,
"productName": "Tea",
"price": 1.50,
"quantity": 80,
"categoryId": 1
}
]

15
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

5.4.1 Authentication API

Method Endpoint Description

POST /api/auth/login User login

5.4.2 Users API

Method Endpoint Description

GET /api/users Get all users

POST /api/users Add new user

PUT /api/users/{id} Update user

DELETE /api/users/{id} Delete user

5.4.3 Categories API

Method Endpoint Description

GET /api/categories Get all categories

POST /api/categories Add category

PUT /api/categories/{id} Update category

DELETE /api/categories/{id} Delete category

5.4.4 Products API

Method Endpoint Description

GET /api/products Get all products

GET /api/products/{id} Get product by ID

POST /api/products Add new product

PUT /api/products/{id} Update product

DELETE /api/products/{id} Delete product

16
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

5.4.5 Sales API

Method Endpoint Description

POST /api/sales Create sales transaction

GET /api/sales Get sales history

GET /api/sales/{id} Get sale details

5.4.6 Reports API

Method Endpoint Description

GET /api/reports/daily Daily sales report

GET /api/reports/monthly Monthly sales report

5.5 Sample API Controller Code

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
private readonly AppDbContext _context;

public ProductsController(AppDbContext context)

{
_context = context;
}

[HttpGet]
public IActionResult GetProducts()
{
return Ok(_context.[Link]());
}

[HttpPost]
public IActionResult AddProduct(Product product)
{
_context.[Link](product);
_context.SaveChanges();
return Ok(product);

17
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

5.6 API Security

• User authentication via login

• Role-based authorization (Admin / Cashier)
• Protected endpoints using authorization attributes
• Input validation to prevent invalid data

5.7 Error Handling

• Uses HTTP status codes for responses

• Handles invalid input and server errors gracefully
• Prevents system crashes during transactions

5.8 API Testing Tools

• Postman – Testing API endpoints

• Swagger UI – API documentation and testing
• Visual Studio Debugger

18
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Unit6
Implementation

6.1 Implementation Overview

This unit describes how the POS System Web API is implemented using [Link]
Web API (.NET) and Entity Framework Core. The implementation focuses on creating
models, database context, controllers, and connecting the API to the SQL Server
database.

6.2 Project Structure

The project is organized as follows:

19
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

6.3 Models

Models define the structure of the database tables using C# classes.

6.3.1 User Model

public class User
{
public int UserId { get; set; }
public string Username { get; set; }
public string PasswordHash { get; set; }
public string Role { get; set; }
public DateTime CreatedAt { get; set; }
}
6.3.2 Product Model
public class Product
{
public int ProductId { get; set; }
public string ProductName { get; set; }
public decimal Price { get; set; }
public int Quantity { get; set; }
public int CategoryId { get; set; }
public Category Category { get; set; }
public DateTime CreatedAt { get; set; }
}
6.3.3 Category Model
public class Category
{
public int CategoryId { get; set; }
public string CategoryName { get; set; }
public ICollection<Product> Products { get; set; }
}
6.3.4 Sale Model
public class Sale
{
public int SaleId { get; set; }
public DateTime SaleDate { get; set; }
public decimal TotalAmount { get; set; }
public string PaymentMethod { get; set; }
public int UserId { get; set; }
public User User { get; set; }
public ICollection<SaleDetail> SaleDetails { get; set; }
}

20
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

6.3.5 SaleDetail Model

public class SaleDetail
{
public int SaleDetailId { get; set; }
public int SaleId { get; set; }
public Sale Sale { get; set; }
public int ProductId { get; set; }

public Product Product { get; set; }

public int Quantity { get; set; }
public decimal UnitPrice { get; set; }
}

6.4 Database Context

The DbContext manages database connections and maps models to tables.

using [Link];

public class AppDbContext : DbContext

{
public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

public DbSet<User> Users { get; set; }

public DbSet<Product> Products { get; set; }
public DbSet<Category> Categories { get; set; }
public DbSet<Sale> Sales { get; set; }
public DbSet<SaleDetail> SaleDetails { get; set; }
}

6.5 Controllers Implementation

6.5.1 ProductsController Example

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
private readonly AppDbContext _context;

public ProductsController(AppDbContext context)

{
_context = context;
}

[HttpGet]
public IActionResult GetAllProducts()

21
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

{
var products = _context.[Link](p => [Link]).ToList();
return Ok(products);
}

[HttpPost]
public IActionResult AddProduct(Product product)
{
_context.[Link](product);
_context.SaveChanges();
return Ok(product);
}

[HttpPut("{id}")]
public IActionResult UpdateProduct(int id, Product product)
{

var existingProduct = _context.[Link](id);

if (existingProduct == null) return NotFound();

[Link] = [Link];
[Link] = [Link];
[Link] = [Link];
[Link] = [Link];

_context.SaveChanges();
return Ok(existingProduct);
}

[HttpDelete("{id}")]
public IActionResult DeleteProduct(int id)
{
var product = _context.[Link](id);
if (product == null) return NotFound();

_context.[Link](product);
_context.SaveChanges();
return Ok();
}
}

6.6 Implementation Notes

• Entity Framework Core handles CRUD operations automatically.

• Controllers use dependency injection to access AppDbContext.
• API endpoints return JSON responses suitable for frontend consumption.
• Relationships between models (e.g., Product → Category, Sale → SaleDetail)
are implemented using navigation properties.

22
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

6.7 Next Steps

• Implement other controllers (SalesController, UsersController, ReportsController)

similarly.
• Test API endpoints using Postman or Swagger UI.
• Connect the API to a web-based frontend to create a full POS system

23
CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Unit7
Testing, Results, and Conclusion

Testing Overview: Ensured the POS System is reliable, accurate, and user-friendly
through unit testing, integration testing, and user acceptance testing (UAT).

Key Test Cases:

• User login and authentication

• Add, update, delete products
• Create sales transactions and update inventory
• Generate daily and monthly sales reports

Testing Tools: Postman, Swagger UI, SQL Server Management Studio (SSMS),
Visual Studio Debugger

Results:

• All functionalities worked correctly

• Inventory updates automatically after sales
• Role-based access control functioned as expected
• API returned correct JSON data and HTTP status codes

Observations:

• Fast API response and simple, user-friendly interface

• Reports are accurate and reliable
• Minor enhancements, such as offline mode or barcode integration, are possible

Conclusion:

• The POS System meets project objectives: automates sales, manages inventory,
and provides accurate reports
• System is secure, maintainable, and ready for small business use
• Future improvements could include loyalty programs, advanced analytics, and
mobile integration

24
 CAMBODIAN UNIVERSITY FOR SPECIALTIES COMPUTER SCIENCE

Reference:
1. [Link]
web-api-project-using-net-core-cli-a-step-by-step-guide-
44699c03c3c5

2. Book: Ultimate [Link] Core Web API by: CodeMaze

3. [Link]

4. [Link]

5. [Link]

25