BIDDING MANAGEMENT SYSTEM

 

INTRODUCTION OF BIDDING MANAGEMENT SYSTEM:

Are you looking for Bidding management system for your final year project? We are here to help you. You can 

The Indian Premier League (IPL, officially Vivo Indian Premier League for sponsorship reasons) is a professional Twenty20 cricket league in India contested during April and May of every year by teams representing Indian cities. The league was founded by the Board of Control for Cricket in India (BCCI).

The IPL is the most-attended cricket league in the world and ranks sixth among all sports leagues. Before the start of every season, players are auctioned for teams. Currently, this system is not fully computerized. So, we are trying to develop fully computerized Bidding system for next IPL season.

This system would be fully cloud based system. Bidders can bid on players from their offices, homes, or place where they want to be. This system would be more transparent any one can view the IPL auction. But only registered team owner can bid on registered players. The system would be more available for bid for 24X7 when online bidding of IPL going on.

MODULES OF BIDDING MANAGEMENT SYSTEM:

There are several modules required to complete this system. Here we are discussing the main modules or core modules of the system.

ADMIN PROFILE:

Admin profile is profiled which is assigned to a super user having full access to the system. Admin module contains Admin Id, name, address, contact no. Admin can view player details, team owner details, bidding process etc.

PLAYER PROFILE:

Registered player details would be available for view. Player details would include player name, age, record, base price etc. Once any player goes in the auction. A team owner can bid on him. The player would able see the details of the owner who has won the bid. The player would also receive payment and bond to signed.

TEAM OWNER:

The team owner is someone who holds the maximum share of the team.A team owner can manage his/her team. Bid on a new player to join team squad.

SEARCH PLAYER DETAILS:

A team owner can search the details of each player. Sort them, add them to cart, bid on them. Once they won the bid they need to make payment to the player.

AVAILABILITY:

A team owner can check whether a player is available for bid or not. If a player is available for bid and player have not been sold. They wish to bid on a player they can.

BIDDING:

The bidding process is real time process. Data in the database would be updated in real time and visible to users in real time.

PAYMENT DETAILS:

After successful winning of bid Team owners needs to pay the money using cash/net banking/ATM card. Payment portal would use a payment gateway to clear payment. Once payment will clear receipt of payment will be generated automatically.

Add / update / delete Player’s Details.Only admin can add, update, and delete the player’s details and others user details. Admin has especial permission to do so.

USER AUTHENTICATION ACCORDING TO HIS/HER ROLE:

The system is strong enough to make authentication as per logged in user.

ADD TEAM OWNERS:

Admin can add team owner details, update owner’s budget. Team owner needs validate their profile before going in the bidding process.

SYSTEM DESIGN OF BIDDING MANAGEMENT SYSTEM:

The system basically needs very simple architecture. This is system is there main three users i.e. Admin, Player, And owners.

USE CASES FOR ADMIN OF BIDDING MANAGEMENT SYSTEM:

Bidding Management System has actor user (Admin). These actors would manage the Bidding management system and help the IPL committee to do auction process for easily and faster than previous. These users can log in to the system using user id and password.

When security is verified these users can make the change which needs to be done in the system. Users can manage player’s details. Admin can change the details of the owner if needed or if there are any changes.

Admin can verify the bid, player details, Owner details. Admin would manage the bidding process in real time using this system. Admin needs to logout system before leaving it for security purpose.

THE USE CASE FOR PLAYERS OF BIDDING MANAGEMENT SYSTEM:

Our second end user is a player. The player can log in the system and verify their identity. The player can view the listed team owner. The player can edit, update his information in the system. The player can view the bid. The player can find the owner details.

The player would able to accept the contract. Once they accept the contract, they would receive money. The player needs to logout system before leaving it for security purpose.

USE CASE FOR TEAM OWNER OF BIDDING MANAGEMENT SYSTEM:

Team owner is someone who bid on players. Owners need to log in in the system before they go in bid process. They can view players details, sort them. They can bid on player, increase bid. Once they won the bid successful.

They need to pay the price of the player to player’s manager. Team Owner needs to logout system before leaving it for security purpose.The team owner is someone who bid on players. Owners need to log in in the system before they go in the bid process.

They can view players details, sort them. They can bid on a player, increase the bid. Once they won the bid successful. They need to pay the price of the player to player’s manager. Team Owner needs to logout system before leaving it for security purpose.

USER INTERFACE OF BIDDING MANAGEMENT SYSTEM(UI):

The user interface is very important part of the system. A good and user-friendly interface attracts the user toward it. Whereas a bad one makes the user experience bad and they never return to system. As we have shown several use cases in this system.

We have developed these interfaces to interact with the system.

LOGIN PAGE:

Admin or client need to log in using login id and password.

OWNER PAGE:

The owner can view their details as well as player’s details. A team owner can participate in the bidding process, buy a player, pay the bidding amount to player’s manager.

PLAYER PAGE:

Player page includes player details, player records. The player can see owner details who is paying him. Team name of player would be updated as soon as they accept the contract.

SEARCH PAGE:

Search page allows the team owner to search for the player profile. Player records, name, type of player, base price, previous team everything would be visible to Owner.

BIDDING PAGE:

Bidding page allows the Team owner to bid on the player. If someone rises the bid. Another user can also rise the bidding prices.

PAYMENT PAGE:

This interface helps in paying the money via several modes.

ER-DIAGRAM OF BIDDING MANAGEMENT SYSTEM

There are mainly five entities Admin, Player, Team Owner, Bid, Payment. These five entities would manage the whole system. There are mainly five entities Admin, Player, Team Owner, Bid, Payment. These five entities would manage the whole system.

ADMIN:

Admin is a super user of the system. Admin has all right to view and modify the data in the system. Admin has followings attributes.

ADMINID:

This is numeric 14 digits number which is unique to every admin. AdminID is the primary key to admin table in the database.

NAME:

This attribute would hold the name of admin. The name is varchar type variable which holds the data length up to 250 characters.

EMAILID:

This is an essential attribute of the table. Every admin must have a working email id to keep in contact with employees. This field has validation only email formatted values will be stored.

CONTACTNO.:

This is multi valued attributes which mean every admin can have more the one mobile number in database.

ADDRESS:

This attribute would hold the address of admin. Each employee must provide the address. Admin address is verified via Human resource team.

PLAYER:

The player is the basic end user of our system most of the business is done thought them. The player can add details about himself. Player has following attributes.

PLAYERID:

This is numeric 14 digits number which is unique to every Client. PlayerID is the primary key to client table in the database.

NAME:

This attribute would hold the name of clients. The name is varchar type variable which holds the data length up to 250 characters.

BASE PRICE:

This is the price of a player decided by the player. Minimum this much amount is needed to buy a player.

PLAYER TYPE:

Player type is a player is batsman, bowler, all-rounder.

PLAYER RECORD:

Player record helps the owner to decide that whether they go for player or not.

CONTACTNO.:

This is multi valued attributes which mean every client can have more the one mobile number in database.

ADDRESS:

This attribute would hold the address of clients. Address of clients would help us to connect with them and visit the location. This would provide better services.

TEAM OWNER:

The team owner is the end user of our system most of the business is done thought them. A team owner can add details about himself. Team owner has following attributes.

OWNERID:

This is numeric 14 digits number which is unique to every Client. OwnerID is the primary key to client table in the database.

NAME:

This attribute would hold the name of team owners. Name is varchar type variable which hold the data length up to 250 characters.

TEAM NAME:

This attribute would hold the name of teams. Team Name is varchar type variable which hold the data length up to 50 characters.

CONTACTNO.:

This is multi valued attributes which mean every client can have more the one mobile number in database.

ADDRESS:

This attribute would hold the address of clients. Address of clients would help us to connect with them and visit the location. This would provide better services.

BID:

Bid table holds the complete information of bidding. The system is basically designed for the bidding process. Therefore, this table needs to be secure. Bid entity would have following attributes.

BIDID:

This is numeric 14 digits number which is unique to every property. BidID is the primary key to property table in the database. Each property is uniquely identified using this id.

OWNERID:

This is foreign key to Team owner table. Owner is also a user of the system. Owner field just holds the id of the owner and rest information is mapped with owner table.

PLAYERID:

This is a foreign key to the player table. the player is also a user of the system. PlayerID field just hold the id of player and rest information is mapped with owner table

STATUS.:

This attribute would able to hold the data about the current status of bid such as not started, over, or live.

FINAL BID:

This attribute would help to get the information of the final amount of bid.

PAYMENT:

Everyone is doing the job for money making. Whenever it comes to money we should make that our client’s money would be safe. In this, Entity every single transaction is recorded in the database. Our company would use a safe and secure payment gateway to clear the payment.  Followings are the attributes.

PAYMENTID:

PaymentID is the primary key to payment Entity. Every payment is uniquely identified using this ID or attribute. This is also a 14-digit natural number.

BIDID:

This is a foreign key to book entity. Every booking is redirected to the payment page. It carries bidding ID that would update the payment status in book table.

TRANSACTIONREFERENCENO.:

This is an attribute used to hold the transaction reference number provided by Payment Gateway Bank. Any issue with payment would be resolved using this number.

FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS OF BIDDING MANAGEMENT SYSTEM:

There are two types of requirement of system in any system, these are:

FUNCTIONAL REQUIREMENT OF BIDDING MANAGEMENT SYSTEM:

REGISTRATION:

Users can register their self in system. Admin will verify their profile to work properly. Once a user is registered with system. He/she can register his/her team to Bidding Management System. Admin will view the bids and verify that bid only if that would be above than base price.

VALIDATION:

Validation is very important in the system. Invalid data can corrupt the valid data. So, we need to apply validation in each module. Validation would ensure the safety and security of data.

PLAYER RECORD:

Player, Owner data should be secure. We should take care of clients’ data privacy in our mind. The client is basic unit of our business. Client data and record would help us to provide them better information.

ADD PLAYER, A TEAM OWNER:

This function allows the admin to add the player details. But only admin can verify the player’s details. Without verification, player details would not reflect in the system.

LIST OF PLAYERS WITH DETAILS:

All players should be listed and reflected team owner. A team owner can view these listed properties and book the desired property.

PAYMENT OPTIONS:

Clients can pay the money of property via any mode they wish to do. They can pay via cash, credit cards, debit cards, online net banking, online wallets etc. The system should not restrict them to some payment option.

FEEDBACK AND SUGGESTION:

Feedback and suggestions are key to improve in business. Therefore, we need to take the feedback from our customer to improve our services

NON-FUNCTIONAL REQUIREMENT OF BIDDING MANAGEMENT SYSTEM:

IMPROVE SEARCH OPTION:

Search option should be rich enough to provide the property details the to clients as per their requirement and wish. Search option should search in the whole database. Efficient search option attracts the client to buy and rent the property

SUPPORT MULTI USER:

Nowadays, every system work in an environment of multi users. As per requirement of the system, our system is developed in multi user’s environment.

FAST:

Search option should be fast enough to produce a result of the search in seconds. Every module should to compatible with other modules. There should not be any lag or delay in processing the data.

AVAILABLE(24X7):

Property Management System should be available to clients 24X7. The user can access the system whenever they need to access, wherever they want to access provided having an internet connection and device to access.

DESIGN DATA DICTIONARY FOR ER-DIAGRAM OF BIDDING MANAGEMENT SYSTEM:

The data dictionary is useful in case of development.

Table Name: AdminMaster

Primary Key: AdminID

Description: To store the details of admin

Serial No.	Fields	Datatype	Description
1.	AdminID	Integer	Primary key
2.	Name	varchar
3.	EmailID	varchar
4.	ContactNo.	Integer	Multiple contacts can exist for single admin
5.	Address	varchar

Table Name: PlayerMaster

Primary Key: PlayerID

Description: To store the details of players

Serial No.	Fields	Datatype	Description
1.	PlayerID	Integer	Primary key
2.	Name	varchar
3.	ContactNo.	Integer	Multiple contacts can exist for single client
4.	Address	varchar
5.	Base price	Float
6.	Player Type	Varchar
7.	Player record	Varchar