Chapter Page No

1. INTRODUCTION

1.1 SYSTEM SPECIFICATION

1.1.1 HARDWARE CONFIGURATION

1.1.2 SOFTWARE SPECIFICATION

2. SYSTEM STUDY

2.1 EXISTING SYSTEM

2.1.1 DESCRIPTION

2.1.2 DRAWBACKS

2.2 PROPOSED SYSTEM

2.2.1 DESCRIPTION

2.2.2 FEATURES

3. SYSTEM DESIGN AND DEVELOPMENT

3.1 FILE DESIGN

3.2 INPUT DESIGN

3.3 OUTPUT DESIGN

3.4 CODE DESIGN

3.5 DATABASE DESIGN

3.6 SYSTEM DEVELOPMENT

3.6.1 DESCRIPTION OF MODULES

4. TESTING AND IMPLEMENTATION

5. CONCLUSION

6. BIBLIOGRAPHY
APPENDICES

A. DATA FLOW DIAGRAM

B. TABLE STRUCTURE

C. SAMPLE CODING

D. SAMPLE INPUT

E. SAMPLE OUTPUT
 SYNOPSIS
This Online Electronic Shopping project in python was designed to manage the
Electronic information to produce the important Electronic Information. Business is one of
the most important economy generators for each country and since the dawn of the twentieth
century. All business companies turned to technology to improve their business chances and
qualities. Thus, such is the reason of the development of this system. This system is
developed for the Electronic business, where it will be implemented in each of the outlets of
an Electronic company. The system name is Online Electronic Shopping (OES). The system
is developed for making management of products much more systematic, secure and
efficient.
 1. INTRODUCTION

PROJECT AIMS AND OBJECTIVES

Managing your Online Electronic Shopping System may seem tricky, but a Online
Electronic Shopping System is a part of E-commerce Service System (Application support
direct contact with users).
 Existing sytems are not user friendly.
 Admin panel need improvement for getting more options for easy working.
 Online Electronic Shopping System searching option need more filters.

Aim:
“To Manage Online Electronic Shopping”.

Objective:
 To perform a thorough analysis of working of the whole System.
 To study the problems in the System through fact finding techniques.
 To follow SDLC to develop the system.
 To develop conceptual, logical and physical model for the system.
 To develop Graphical User Interface (GUI) as per convenience of the user.
 To implement the physical model, being tested as per the standards.
 To document our efforts and analysis in a proper comprehensible manner.
Goal:
∙ The project is basically targeted at those people who would like to have Online
Electronic Shop and have an Internet access.
 Electronic gadget lovers, who are curious in comparing the
prices for various glasses from their selected category.
 To make a database that is consistent, reliable and secure.
 To provide correct, complete, ongoing information.
 To develop a well-organized information storage system.
 To make good documentation so as to facilitate possible
future enhancements.
Need of the System:
There is always a need of a system that will perform to search and buy new
Electronics through Online Shopping.

Thus, there is a need of online Electronic Shopping services, which provides all the
Above- mentioned facilities and many more on their finger tips.

1.1 SYSTEM SPECIFICATION

1.1.1 HARDWARE CONFIGURATION

1.Pentium IV Processor
2.512 MB RAM
3.40GB HDD
4.1024 * 768 Resolution Color Monitor

1.1.2 SOFTWARE SPECIFICATION

1. Microsoft Windows 7/8.

2. HTML/Python/Django.
3. Apache Server
4. My SQL.
5. Ms-Office package.
 2. SYSTEM STUDY

2.1 EXISTING SYSTEM

2.1.1 DESCRIPTION

In the existing system, the management of electronic products is likely manual, with
limited or no use of technology. Traditional methods such as paper-based records or
basic computer systems may be in place to handle inventory, sales, and other business
processes.

2.1.2 DRAWBACKS

The drawbacks of the existing system includes:

Inefficiency: Manual systems can be time-consuming and error-prone, leading to

inefficiencies in managing electronic products.

Limited Accessibility: Access to information may be restricted, making it difficult to obtain

real-time updates on product availability, sales, and other critical data.

Security Concerns: Paper-based records and basic computer systems may lack robust
security measures, putting sensitive business information at risk.

Lack of Automation: Tasks such as inventory management, order processing, and customer
interactions may lack automation, leading to delays and potential errors.

2.2 PROPOSED SYSTEM

2.2.1 DESCRIPTION

The proposed system, Online Electronic Shopping (OES), is designed to address the
limitations of the existing system by leveraging modern technology and electronic commerce
principles. OES aims to streamline the management of electronic products through a
comprehensive online platform.
 2.2.2 FEATURES

Product Management: Efficient and systematic handling of electronic products,

including features for adding, updating, and removing items from the inventory.

User Authentication: Secure login system to ensure authorized access to the system,
protecting sensitive business information.

Order Processing: Automation of the order processing system, from order placement
to delivery, to enhance efficiency and reduce errors.

Inventory Tracking: Real-time monitoring of inventory levels, preventing stockouts

and facilitating timely restocking.

Sales Analytics: Generation of reports and analytics to provide insights into sales
trends, customer preferences, and overall business performance.

User-Friendly Interface: An intuitive and user-friendly interface to enhance the user

experience for both administrators and customers.

Security Measures: Implementation of robust security measures, including data

encryption and secure payment gateways, to protect against unauthorized access and data
breaches.

Multi-Platform Accessibility: Availability of the system on multiple platforms,

including web and mobile interfaces, to ensure accessibility from various devices.

The proposed system aims to revolutionize the electronic business by introducing

automation, enhancing security, and providing valuable insights through analytics. It is
designed to improve overall business efficiency and customer satisfaction in the rapidly
evolving electronic commerce landscape.
 3. SYSTEM DESIGN AND DEVELOPMENT

3.1 FILE DESIGN

The file design involves organizing the files within the project to ensure clarity,
maintainability, and scalability.

File Structure:

main.py: Main entry point of the application.

login.py: Handles user authentication and login functionality.

register.py: Manages user registration process.

products.py: Displays available electronic products, allows filtering and searching.

cart.py: Manages the shopping cart, allowing users to add, remove, or modify
product items.

checkout.py: Facilitates the checkout process, including selecting delivery options

and entering payment details.

order.py: Confirms the order and provides an order summary for the customer.

admin_panel.py: Provides administrative functionalities for managing products,

orders, and user accounts.

database.py: Handles database connectivity and operations.

utils.py: Contains utility functions used across the application.

config.py: Configuration file for storing database credentials and other settings.

templates/: Directory containing HTML templates for the frontend.

static/: Directory for static files such as CSS stylesheets, JavaScript files, and images.
3.2 INPUT DESIGN

Input design focuses on designing the user interface and mechanisms for entering data
into the system. It is essential for ensuring data accuracy, completeness, and user-friendliness.
Key aspects of input design include:
Input design focuses on creating user interfaces for data input, ensuring ease of use and
accurate data capture.

Input Components:

1. User Registration Form: Collects information such as name, email, password, etc.,
for user registration.

2. Login Form: Allows users to enter their credentials to log into the system.

3. Product Search and Filter: Enables users to search for electronic products by
keywords, category, or price range.

4. Add to Cart Button: Allows users to add selected product items to their shopping
cart.

5. Checkout Form: Collects delivery information, payment details, and other necessary
information to complete the order.

3.3 OUTPUT DESIGN

Output design focuses on how the system presents information to users. It is crucial for
delivering meaningful and relevant information in a clear and organized manner. Key aspects
of output design include:
 Report Design: Creating clear and well-structured reports, including tables, charts,
and graphs, to present data in a comprehensible format.
 User Interface Design: Designing user interfaces that display information in an
organized and user-friendly way. This includes font selection, color coding, and
layout design.
 Output Medium: Deciding whether output will be displayed on a screen, printed on
paper, or delivered in electronic formats (e.g., PDFs or email).
 Customization: Allowing users to customize their output preferences, such as
selecting the information they want to see and how it's presented.
 Output design involves presenting information to users in a meaningful and
comprehensible manner.
Output Components:
1. Product Listings: Displays available electronic products with details such as
name, description, price, and image.
2. Shopping Cart Summary: Shows a summary of items added to the shopping cart,
including quantity, price, and total cost.
3. Order Confirmation: Provides users with a confirmation message and order
details after completing a purchase.
4. Admin Dashboard: Displays statistics, reports, and tools for managing products,
orders, and user accounts.
3.4 CODE DESIGN

Code design involves structuring the backend codebase to ensure modularity, readability, and
maintainability.
Code Components:
1. User Authentication: Functions for user registration, login, logout, and session
management.
2. Product Management: Code for adding, updating, and deleting electronic products, as
well as managing categories and subcategories.
3. Shopping Cart Management: Functions for adding, removing, and updating items in
the shopping cart.
4. Order Processing: Code for creating and processing orders, calculating totals, and
updating inventory levels.
5. Database Connectivity: Utilizes SQLite database for storing product information, user
accounts, orders, etc., with Python's built-in SQLite library for database operations.

3.5 DATABASE DESIGN

Database design involves designing the structure of the database tables and defining
relationships between them to store and manage data efficiently.
Database Tables:

1. Users: Stores information about registered users, including user ID, username, email,
password hash, etc.

2. Products: Contains details of available electronic products, such as product ID, name,
description, price, category ID, etc.

3. Categories: Stores information about product categories, including category ID,

name, and parent category (if applicable).

4. Orders: Records information about orders placed by users, including order ID, user
ID, status, total amount, delivery address, etc.

5. Order_Items: Stores the relationship between orders and product items, including
quantity, price, and product ID.

3.6 SYSTEM DEVELOPMENT

System development encompasses the entire process of building and deploying the
system, including coding, testing, and deployment. Key aspects of system development
include:
 Coding and Implementation: Writing the software code according to the design
specifications and requirements.
 Testing: Conducting various testing phases, including unit testing, integration testing,
and system testing, to identify and rectify defects and ensure the system functions as
expected.
 Deployment: Installing the system in a production environment, configuring it, and
ensuring it is available to users.
 Documentation: Creating comprehensive documentation, including user manuals,
technical documentation, and training materials.
 User Training: Training end-users and administrators on how to use and maintain the
system.
 Ongoing Maintenance: Planning for ongoing system maintenance, updates, and
support to ensure its continued functionality and relevance.
Effective system development involves careful planning, design, and implementation to
create a system that meets user needs, is reliable, and can adapt to changing requirements.
 3.6.1 DESCRIPTION OF MODULES

This project have 2 module first is user and second one is admin. Firstly here admin
can login, after that admin can add items and view item details with delete option. You can
also delete the item through the deletion option. Admin can view orders placed by user. In
this Electronic shop management project application User can register account and then can
fill a login form after that, user can see different types of electronic products and purchase
them online over the internet and also make online payments.

This project has two modules i.e. admin and user.

User Module:
 Users can register themselves on the site.
 Users can sign in to their account and see items.
 Users can add items to their carts.
 Users can select items from various categories.
 Users can make payment online.
Admin Module:

 Admin is the super user that have access to login.

 He can add new products.
 Can view sales detail.
 Can manage products
 Can manage categories
 4. TESTING AND IMPLEMENTATION
4.1 SYSTEM TESTING
The purpose of testing is to discover errors. Testing is the process of trying to
discover every conceivable fault or weakness in a work product. It provides a way to check
the functionality of components, sub-assemblies, assemblies and/or a finished product. It is
the process of exercising software with the intent of ensuring that the Software system meets
its requirements and user expectations and does not fail in an unacceptable manner. There are
various types of tests. Each test type addresses a specific testing requirement.

TYPES OF TESTS:
4.1.1 Unit Testing:
Unit testing involves the design of test cases that validate that the internal program
logic is functioning properly, and that program inputs produce valid outputs. All decision
branches and internal code flow should be validated. It is the testing of individual software
units of the application .It is done after the completion of an individual unit before
integration. This is a structural testing that relies on knowledge of its construction and is
invasive. Unit tests perform basic tests at component level and test a specific business
process, application, and/or system configuration. Unit tests ensure that each unique path of a
business process performs accurately to the documented specifications and contains clearly
defined inputs and expected results.

4.1.2 Integration Testing:

Integration tests are designed to test integrated software components to determine if
they actually run as one program. Testing is event driven and is more concerned with the
basic outcome of screens or fields. Integration tests demonstrate that although the
components were individually satisfactory, as shown by successfully unit testing, the
combination of components is correct and consistent. Integration testing is specifically aimed
at exposing the problems that arise from the combination of components.
4.1.3 Functional Test:
Functional tests provide systematic demonstrations that functions tested are available as
specified by the business and technical requirements, system documentation, and user
manuals.
Functional testing is centered on the following items:
Valid Input : identified classes of valid input must be accepted.
Invalid Input : identified classes of invalid input must be rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must be exercised.
Systems/Procedures: interfacing systems or procedures must be invoked.
Organization and preparation of functional tests is focused on requirements, key
functions, or special test cases. In addition, systematic coverage pertaining to identifying
Business process flows; data fields, predefined processes, and successive processes must be
considered for testing. Before functional testing is complete, additional tests are identified
and the effective value of current tests is determined.
White Box Testing:
White Box Testing is a testing in which the software tester has knowledge of the inner
workings, structure and language of the software, or at least its purpose. It has a purpose. It is
used to test areas that cannot be reached from a black box level.
Black Box Testing:
Black Box Testing is testing the software without any knowledge of the inner workings,
structure or language of the module being tested. Black box tests, as most other kinds of tests,
must be written from a definitive source document, such as specification or requirements
document, such as specification or requirements document. It is a test in which the software
under test is treated as a black box .You cannot “see” into it. The test provides inputs and
responds to outputs without considering how the software works.
Test strategy and approach
Field testing will be performed manually and functional tests will be written in detail.
Test objectives:

❖ All field entries must work properly.

❖ Pages must be activated from the identified link.

 ❖ The entry screen, messages and responses must not be delayed.

Features to be tested:

❖ Verify that the entries are of the correct format

❖ No duplicate entries should be allowed

❖ All links should take the user to the correct page.

4.1.4 Acceptance Testing:

User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional
requirements.
Test Results: All the test cases mentioned above passed successfully. No defects
encountered.
 5. CONCLUSION
In conclusion, the development of the Online Electronic Shopping (OES) project in
Python signifies a pivotal step towards modernizing and optimizing the management of
electronic products within a business framework. The existing system's drawbacks, such as
inefficiency, limited accessibility, security concerns, and a lack of automation, have
prompted the conceptualization and design of a more advanced and user-centric platform.

The proposed system, OES, is poised to bring about a transformative change by

leveraging technology to enhance various facets of electronic business operations. With
features encompassing product management, user authentication, order processing
automation, inventory tracking, sales analytics, a user-friendly interface, and robust security
measures, OES is positioned to streamline and fortify the entire business process.

By embracing multi-platform accessibility and prioritizing data security, the OES

project not only addresses the limitations of the existing system but also aligns with the
contemporary demands of the electronic commerce landscape. The implementation of real-
time monitoring, analytics, and a secure payment gateway aims to provide a seamless and
secure experience for both administrators and customers alike.
 6. BIBLIOGRAPHY
The following books were referred during the analysis and execution phase of the project

 PHP and MySQL Web Development Book by Luke Welling

 Head First PHP & MySQL Book by Lynn Beighley and Michael Morrison
 PHP & MySQL for Dummies Book by Janet Valade

WEBSITES:

 www.google.com
 www.w3schools.com
 www.tutorialspoint.php
 http://stackoverflow.com

APPENDICES

A. DATA FLOW DIAGRAM

The DFD takes an input-process-output view of a system i.e. data objects flow into the
software, are transformed by processing elements, and resultant data objects flow out of the
software.
Data objects represented by labeled arrows and transformation are represented by
circles also called as bubbles. DFD is presented in a hierarchical fashion i.e., the first data
flow model represents the system as a whole. Subsequent DFD refine the context diagram
(level 0 DFD), providing increasing details with each subsequent level.
The DFD enables the software engineer to develop models of the information domain
& functional domain at the same time. As the DFD is refined into greater levels of details, the
analyst performs an implicit functional decomposition of the system. At the same time, the
DFD refinement results in a corresponding refinement of the data as it moves through the
process that embody the applications.
A context-level DFD for the system the primary external entities produce information
for use by the system and consume information generated by the system. The labeled arrow
represents data objects or object hierarchy.

RULES FOR DFD:

 Fix the scope of the system by means of context diagrams.

 Organize the DFD so that the main sequence of the actions
 Reads left to right and top to bottom.
 Identify all inputs and outputs.
 Identify and label each process internal to the system with Rounded circles.
 A process is required for all the data transformation and Transfers. Therefore, never
connect a data store to a data Source or the destinations or another data store with just
a Data flow arrow.
 Do not indicate hardware and ignore control information.
 Make sure the names of the processes accurately convey everything the process is
done.

 There must not be unnamed process.

 Indicate external sources and destinations of the data, with Squares.
 Number each occurrence of repeated external entities.
  Identify all data flows for each process step, except simple Record retrievals.
 Label data flow on each arrow.
 Use details flow on each arrow.
 Use the details flow arrow to indicate data movements.
Context Diagram 0

Customer
Management

Shopping Payment
Management Management
Shopping Portal

Order Products
Management Management

Login
Management

Context Diagram 1

Shopping
Management Generate Order
Report
Second Level DFD
 Check Roles of access
Login to system Manage
Admin Category

Manage Sub
Category

Manage
Products
Forgot Password Check Credential

Manage Order
Details

Generate Order
Report

Manage Modules

Generate Sales
Report

Update Profile

Change
Password

Signup/Login to system Check Roles of access

User Add to cart

Add to wishlist
ok
 E-R Diagrams:
The Entity-Relationship (ER) model was originally proposed by Peter in 1976
[Chen76] as a way to unify the network and relational database views. Simply stated the ER
model is a conceptual data model that views the real world as entities and relationships. A
basic component of the model is the Entity-Relationship diagram which is used to visually
represents data objects. Since Chen wrote his paper the model has been extended and today it
is commonly used for database design For the database designer, the utility of the ER model
is:
 it maps well to the relational model. The constructs used in the ER model can easily be
transformed into relational tables.
 it is simple and easy to understand with a minimum of training. Therefore, the model can be
used by the database designer to communicate the design to the end user.
 In addition, the model can be used as a design plan by the database developer to implement a
data model in a specific database management software.
Connectivity and Cardinality
The basic types of connectivity for relations are: one-to-one, one-to-many, and many-to-
many. A one-to-one (1:1) relationship is when at most one instance of a entity A is associated
 with one instance of entity B. For example, "employees in the company are each assigned
their own office. For each employee there exists a unique office and for each office there
exists a unique employee.
A one-to-many (1:N) relationships is when for one instance of entity A, there are zero, one, or
many instances of entity B, but for one instance of entity B, there is only one instance of
entity A. An example of a 1:N relationships is
a department has many employees
each employee is assigned to one department
A many-to-many (M:N) relationship, sometimes called non-specific, is when for one instance
of entity A, there are zero, one, or many instances of entity B and for one instance of entity B
there are zero, one, or many instances of entity A. The connectivity of a relationship
describes the mapping of associated
ER Notation
There is no standard for representing data objects in ER diagrams. Each modeling
methodology uses its own notation. The original notation used by Chen is widely used in
academics texts and journals but rarely seen in either CASE tools or publications by non-
academics. Today, there are a number of notations used, among the more common are
Bachman, crow's foot, and IDEFIX.
All notational styles represent entities as rectangular boxes and relationships as lines
connecting boxes. Each style uses a special set of symbols to represent the cardinality of a
connection. The notation used in this document is from Martin. The symbols used for the
basic ER constructs are:
 entities are represented by labeled rectangles. The label is the name of the entity. Entity
names should be singular nouns.
 relationships are represented by a solid line connecting two entities. The name of the
relationship is written above the line. Relationship names should be verbs
 attributes, when included, are listed inside the entity rectangle. Attributes which are
identifiers are underlined. Attribute names should be singular nouns.
 cardinality of many is represented by a line ending in a crow's foot. If the crow's foot is
omitted, the cardinality is one.
 existence is represented by placing a circle or a perpendicular bar on the line. Mandatory
existence is shown by the bar (looks like a 1) next to the entity for an instance is required.
Optional existence is shown by placing a circle next to the entity that is optional
ER DIAGRAM

B. TABLE STRUCTURE

Tables
The data in the system has to be stored and retrieved from database.
Designing the database is part of system design. Data elements and data
structures to be stored have been identified at analysis stage. They are structured
and put together to design the data storage and retrieval system.

A database is a collection of interrelated data stored with minimum

redundancy to serve many users quickly and efficiently. The general objective is
to make database access easy, quick, inexpensive and flexible for the user.
Relationships are established between the data items and unnecessary data items
are removed. Normalization is done to get an internal consistency of data and to
have minimum redundancy and maximum stability. This ensures minimizing
data storage required, minimizing chances of data inconsistencies and optimizing
for updates. The MySQL database has been chosen for developing the relevant
databases.

Admin Table :(Table name is tbladmin)

This table store admin personal and login details.

Address Table :(Table name is addresses)

This table store billing and shipping address of users.

Shopping Table :(Table name is shopping)

This table store shopping details of users.

Category Table :(Table name is category)

This table store the category of products.

Subcategory Table :(Table name is subcategory)

This table store the subcategory of products.

Orders Table :(Table name is orders)

This table store the orders of users.

Orders DetailsTable :(Table name is ordersdetails)

This table store the orders details of users.

Orders Tracking Table :(Table name is ordertrackhistory)

This table store the data of order tracking history.

ProductsTable :(Table name is products)

This table store the data of products.

User Table:(Table name is users)

This table store the data of registered users.

Wishlist Table:(Table name is wishlist)

This table store the wish listed products of users.

B. SAMPLE CODING.

Initial.py

# Generated by Django 2.1.5 on 2019-02-11 11:56

from django.db import migrations, models
class Migration(migrations.Migration):
initial = True
dependencies = []
operations = [
migrations.CreateModel(
name='Product',
fields=[
('id', models.AutoField(auto_created=True, primary_key=True,
serialize=False, verbose_name='ID')),
('product_name', models.CharField(max_length=120)),
('product_desc', models.CharField(max_length=200)),
('pub_date', models.DateField()),
],
),
]

Auto.py
# Generated by Django 2.1.5 on 2019-02-13 05:52
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('shop', '0001_initial'),
]
operations = [
migrations.RemoveField(
model_name='product',
name='product_desc',
),
migrations.AddField(
model_name='product',
name='category',
field=models.CharField(default='', max_length=50),
),
migrations.AddField(
model_name='product',
name='desc',
field=models.CharField(default='nothing is to describe', max_length=300),
),
migrations.AddField(
model_name='product',
name='image',
field=models.ImageField(default='', upload_to='shop/images'),
),
migrations.AddField(
model_name='product',
name='price',
field=models.IntegerField(default=0),
),
migrations.AddField(
model_name='product',
name='subcategory',
 field=models.CharField(default='', max_length=50),
),
migrations.AlterField(
model_name='product',
name='product_name',
field=models.CharField(max_length=50),
),
]
Contact.py

# Generated by Django 2.1.5 on 2019-02-19 03:33

from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('shop', '0002_auto_20190213_1122'),
]
operations = [
migrations.CreateModel(
name='Contact',
fields=[
('msg_id', models.AutoField(primary_key=True, serialize=False)),
('name', models.CharField(max_length=50)),
('email', models.CharField(default='', max_length=70)),
('phone', models.CharField(default='', max_length=70)),
('desc', models.CharField(default='', max_length=500)),
],
),
]
Orders.py

# Generated by Django 2.1.5 on 2019-02-22 03:01

from django.db import migrations, models

class Migration(migrations.Migration):

dependencies = [
('shop', '0003_contact'),
]

operations = [
migrations.CreateModel(
name='Orders',
fields=[
('order_id', models.AutoField(primary_key=True, serialize=False)),
('items_json', models.CharField(max_length=5000)),
('name', models.CharField(max_length=5000)),
('email', models.CharField(default='', max_length=70)),
('city', models.CharField(max_length=111)),
('address', models.CharField(max_length=11)),
('state', models.CharField(max_length=111)),
('zip_code', models.CharField(max_length=111)),
],
),
]
Orders_phone.py

# Generated by Django 2.1.5 on 2019-02-22 03:12

from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('shop', '0004_orders'),
]

operations = [
migrations.AddField(
model_name='orders',
name='phone',
 field=models.CharField(default='', max_length=70),
),
]

Product_cart.py

# Generated by Django 2.1.5 on 2019-02-24 06:34

from django.db import migrations, models

class Migration(migrations.Migration):

dependencies = [

('shop', '0007_auto_20190222_0908'),

operations = [

migrations.AddField(

model_name='product',

name='cart',

field=models.BooleanField(default=False),

),

Product_qty.php
# Generated by Django 2.1.5 on 2019-02-24 08:52
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('shop', '0008_product_cart'),
]
operations = [
migrations.AddField(
model_name='product',
name='qty',
field=models.CharField(default='0', max_length=1000),
),
]
Product_total.py
# Generated by Django 2.1.5 on 2019-02-24 11:41
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('shop', '0011_auto_20190224_1640'),
]
operations = [
migrations.AddField(
model_name='product',
name='total',
field=models.IntegerField(default=0),
),
]
 C. SAMPLE INPUT

Home Page

ADMIN LOGIN PAGE

 D. SAMPLE OUTPUT

ADMIN PAGE
CHANGE/ UPDATE PRODUCTS
ADD PRODUCT
SEE UPDATDED PRODUCTS
CHANGE ORDERS
VIEW PRODUCTS & ADD TO CARTS
REVIEW CART
COMPLETE THE CHECKOUT DETAILS