EMCOR Inventory System

BSU - External Studies Center
Gingoog City

EMCOR INVENTORY SYSTEM

An Undergraduate System Proposal

In Partial Fulfillment of
IT 113 - System Analysis and Design

Chapter 1: Project Description
1.1 Research Description
EMCOR is the no.1 retailer of computers, furniture’s, appliances, and motorcycles in the Philippines! We deliver nationwide! EMCOR is a 100% Filipino owned retail corporation specializing in appliances, furniture, computers & IT products and motorcycles. EMCOR was founded by Jesus V. Del Rosario in 1958 and we are currently under the JVR Foundation Inc-one of the many companies of the JVR Group of Companies. The modes of payment are either in cash or in an installment basis. When we say cash basis, the customer will immediately pay the full amount of the product. If its an installment basis, the customer will have an option on how the way he/she can fulfill his/her financial obligation. In EMCOR they offer four (4) options : (1) good for 3 months; (2) 6 months; (3) 12 months;(4) or 12 months of paying. Others include:
Kawasaki motors(Philippines)Corporation
K-servico Trade, Incorporated
Wodel Incorporated
Delsa Chemicals and Multi Products Incorporated
International Wiring Systems Philippines Incorporated
Hecny Forwarders Incorporated
JDel investments
Wodel Manpower Services
We have also patterned with Western Union for our money transfer services. The core of our existence is our ability to provide high quality service to our customers by providing the right products at the right time, in the right place and at the right price.
1.2 Research Objectives
To be able to provide and implement better and accurate inventory system that can handle a certain task in a much more time saving and fluent operation that would greatly help EMCOR in generating its daily operation.
To be able to provide an inventory system that is capable of recording all that daily transaction and to evaluate its results monthly.

1.3 Research Scope and Limitation
The EMCOR inventory system can be used in identity which items or products are most popular and those that are not. It can be used in tracking the availability of the product. It can also be used in evaluating in your savings.

1.4 Review of Related Literature

Gingoog City Comprehensive National High School Management Information System
There are two systems on this project, the Transaction Processing System which is reliable on all the transactions within the library and the Management Information System which saves and retrieve data and information gather from the transactions in the library.
This system will store and saves all the students information to the database. And for the user’s side, it will be easy to track whose students are incharge and responsible for the books that has been borrowed.

i.T SURAAN INVENTORY SYSTEM
This system calculates the business transaction of the flower being sold for day, week and months. The system keeps the record of the orders and purchases that ease accessible by the owner upon inventory time.

Chapter 2: Methodology and Requirements
2.1 Planning Requirements Gathering
There is a great need for EMCOR to upgrade its existing system to an efficient and more convenient one. We have determined the benefits and savings that are expected from candidate system and compare them with costs, and then the decisions are made to design and implement the system. The project is indeed feasible that the project costs will fall within the target budget or return the investments. The required time frame would be set by the group.
2.2 Analysis We conducted an investigation about the system of DESMARK CORPORATION and we decided to make a system same with the Desmark but instead of naming it Desmark we decided to name it as EMCOR inventory system with an objective of improving and developing a new concept for the proposed system.
2.3 Design
In this phase the requirements are identified as to which hardware, software and network infrastructure will be used. The systems will be developed outside the company. It would follow the category of system methodology which is the “extreme programming”. With extreme programming-based methodologies, the company will provide a shortlist of high-value requirements for the system.
The unified modeling language (UML) is used to describe system concepts as a collection of objects incorporating both data and processes.
2.4 Implementation
The proposed system will be implemented using MS Access 2007. In this phase, the proponents will decide whether it would be developed or be purchased in case of packing software.

2.5 Testing
Measures of effectiveness (MOE) will be used to evaluate how the system accomplished its system objective and goals. The proponents needs to assure the clients that the proposed system will meet their expectations and it match to the planned objectives and goals of groups.
The system will be built and tested to endure it performs as designed. In case of any installation process, the group needs the support the installed system.
2.6 Deployment
The system is dynamic in term of its application. On its first deployment it is to be used by the EMCOR. Once it will be installed, only the administrator can access the system.

Chapter 3: EMCOR Inventory System

3.1 System Description

This is an inventory management system that would greatly help you. This is a Visual Basic Based inventory sale and purchasing management system designed for small business, it addresses the entire warehouse as the employee’s list database. It also keeps personnel from wasting their time on counting supplies and trying to manually determine which products to buy and sell.
It keeps track of the material it has available. Though, it is possible to keep a record of the products coming into the business and products being sold. This system is invaluable tools for most business because it is capable of completing task quickly that would take much longer if done manually. It is capable of tracking remaining stocks, tracking when new orders should be made, tracking which products are most popular and something to help the business owner decide what products are most profitable and which to remove.
If you’re making sales, this system will help you generate the sales order and automatically decreases the inventory items number from the inventory list. It will also save your entire customer’s information to the database. When it comes with the business employee, it wills be easy to let you track your employee’s information and who’s responsible to the purchase of sales order
You can also report for all the sales record, purchase order record, inventory list records based on your need.

3.2 System Objectives
To compute accurate outcomes in terms of recorded purchases and sales.
To track which items are most popular and which items are needed to remove.

3.3 System Scope and Limitation
This is an inventory management system that would greatly help you. This is a Visual Basic Based inventory sale and purchasing management system designed for small business, it addresses the entire warehouse as the employee’s list database. It also keeps personnel from wasting their time on counting supplies and trying to manually determine which products to buy and sell.

3.4 Conceptual Framework Official receipt Payment

Product
Ordered Available Products

Official receipt Sales money collected Inquiry response from the debtors

List of debtors
Sales Inventory information on item record product Available items availability

3.5 Entity Relationship Diagram

3.6 Activity Diagram
3.5 Use Case Diagram

3.8 Use Case Narratives
1. Log in
USE CASE NAME:
Log in
USE CASE TYPE
USE CASE ID:
Login_ID
Business Requirements: 
PRIMARY BUSINESS ACTOR:
User
OTHER PARTICIPATING ACTORS:
Employee
OTHER INTERESTED STAKEHOLDERS:
Marketing –interested in sales activity in order to plan new promotion.
Procurement-interested in order to replenish inventory.
Upper management-interested in order activity to evaluate company performance and client’s satisfaction.
DESCRIPTION:
This use case describes the event of the user logging-in to access the system. The user’s username and password is validated. Once his/her account is verified the user can perform all the necessary interaction he/she wishes to do in the system. But of its invalidated the system would require the user to enter the correct by username and password.
PRE-CONDITION:
The user logging-in in the system must be an employee of the company specially the one assigned to handle the system.
TRIGGER:
This use case is initiated when the user logs in.
TYPICAL COURSE
Actor Action
System Response
OF EVENTS:

Step 1: The user provides his/her username and password to access the system.
Step 2: Systems responds by verifying the inputted username and password.

Step 3: For every incorrect username, the system will require the user to input the correct username.

Step 4: For every incorrect username, the system will require the user to input the correct password.

Step 5: once the username and password has been validated, the system displays the main form.
ALTERNATE COURSES:

Alt Step 2: If the user has not provided the necessary information to access the system, the user needs to input the correct username and password.
CONCLUSION:
This use case concludes when the user has log-on to the system and displays the main form.
POST-CONDITION:
The user must enter the valid username and password.
BUSINESS RULES
Only the employee in charge can access the system.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
GUI to be Provided to the specified user.

2. Manage Employee
USE CASE NAME:
Manage Employee
USE CASE TYPE
USE CASE ID:
Emp_ID
Business Requirements: 
PRIMARY BUSINESS ACTOR:
User
OTHER PARTICIPATING ACTORS:
Employee
OTHER INTERESTED STAKEHOLDERS:
Marketing –interested in sales activity in order to plan new promotion.
Procurement-interested in order to replenish inventory.
Upper management-interested in order activity to evaluate company performance and client’s satisfaction.
DESCRIPTION:
This use case describes the event of the user managing all the necessary employee information. You can see the mange employee button on the main form. In here the user can add, edit, delete, and search employee on the system.
PRE-CONDITION:
The user managing employee must be the one assign to handle the system. The user must log in.
TRIGGER:
This use case is initiated when the user logs in.
TYPICAL COURSE
Actor Action
System Response
OF EVENTS:

Step 1: The user clicks the manage employee button.
Step 2: The system responds by displaying the employee list form which has 6 buttons. The add employee, search employee, home, view, next and exit buttons.

Step 3: The user clicks the next button.
Step 4: The system responds by displaying the next list of employees.

Step 5: The user clicks the add employee button.
Step 6: The system responds by displaying the add employee form.

Step 7: The user clicks the view button.
Step 8: The system responds by displaying the employee information form.
ALTERNATE COURSES:

Alt-Step 2: If the user changes his/her mind and doesn’t want to go to the list of employees but to the main form, the user will simply click the home button.
Alt-Step 3: If the user changes his/her mind and want to end the program, the user will simply click the exit button.
Alt-Step 5: If the user changes his/her mind and doesn’t want to add new employee, the user will simply click the back button.
Alt-Step 6: If the user changes his/her mind and doesn’t want to view the information about the employee, the user will simply click the back button.
Alt-Step 6: If the user wants to automatically view the information about the employee faster, the user will simply user will simply enter the Employee ID of the employee and then click the search employee button.
CONCLUSION:
This use case concludes when the user has returned to the main form.
POST-CONDITION:
The user must log in.
BUSINESS RULES
Only the employee in charge can access the system.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
GUI to be Provided to the specified user.

3. Manage Client
USE CASE NAME:
Manage Client
USE CASE TYPE
USE CASE ID:
Client_ID
Business Requirements: 
PRIMARY BUSINESS ACTOR:
User
OTHER PARTICIPATING ACTORS:
Employee
OTHER INTERESTED STAKEHOLDERS:
Marketing –interested in sales activity in order to plan new promotion.
Procurement-interested in order to replenish inventory.
Upper management-interested in order activity to evaluate company performance and client’s satisfaction.
DESCRIPTION:
This use case describes the event of the user managing all the necessary clients’ information. You can see the manage client button on the main form. In here can add, edit, delete and search client information on the system.
PRE-CONDITION:
The user managing client information must be the one assigned to handle the system. The user must log on.
TRIGGER:
This use case is initiated when the user logs in.
TYPICAL COURSE
Actor Action
System Response
OF EVENTS:

Step 1: The user clicks the manage client button.
Step 2: The system responds by displaying the client list form which has 6 buttons. The add client, search client, home, view, next and exit buttons.

Step 3: The user clicks the next button.
Step 4: The system responds by displaying the next list of clients.

Step 5: The user clicks the add client button.
Step 6: The system responds by displaying the add client form

Step 7: The user clicks the view button.
Step 8: The system responds by displaying the client information form.
ALTERNATE COURSES:

Alt-Step 2: If the user changes his/her mind and doesn’t want to go to the list of client but to the main form, the user will simply click the home button.
Alt-Step 3: If the user changes his/her mind and want to end the program, the user will simply click the exit button.
Alt-Step 5: If the user changes his/her mind and doesn’t want to add new client, the user will simply click the back button.
Alt-Step 6: If the user changes his/her mind and doesn’t want to view the information about the client, the user will simply click the back button.
Alt-Step 6: If the user wants to automatically view the information about the client faster, the user will simply user will simply enter the Client ID of the client and then click the search employee button.
CONCLUSION:
This use case concludes when the user has returned to the main form.
POST-CONDITION:
The user must log in.
BUSINESS RULES
Only the employee in charge can access the system..
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
GUI to be provided to the specified user and a web-screen to be provided for the clients.

4. Manage Product
USE CASE NAME:
Manage Product
USE CASE TYPE
USE CASE ID:
Prod_ID
Business Requirements: 
PRIMARY BUSINESS ACTOR:
User
OTHER PARTICIPATING ACTORS:
Employee
OTHER INTERESTED STAKEHOLDERS:
Marketing –interested in sales activity in order to plan new promotion.
Procurement-interested in order to replenish inventory.
Upper management-interested in order activity to evaluate company performance and client’s satisfaction.
DESCRIPTION:
This use case describes the event of the user managing all the necessary product information. You can see the mange product button on the main form. H the user can add, edit, delete, and search employee on the system.
PRE-CONDITION:
The user managing product information must be the one assigned to handle the system. The user must log on.
TRIGGER:
This use case is initiated when the user logs in.
TYPICAL COURSE
Actor Action
System Response
OF EVENTS:

Step 1: The user clicks the manage product button.
Step 2: The system responds by displaying the product list form which has 6 buttons. The add product, search product, home, view, next and exit buttons.

Step 3: The user clicks the next button.
Step 4: The system responds by displaying the next list of products.

Step 5: The user clicks the add product button.
Step 6: The system responds by displaying the add product form.

Step 7: The user clicks the view button.
Step 8: The system responds by displaying the product information form.
ALTERNATE COURSES:

Alt-Step 2: If the user changes his/her mind and doesn’t want to go to the list of products but to the main form, the user will simply click the home button.
Alt-Step 3: If the user changes his/her mind and want to end the program, the user will simply click the exit button.
Alt-Step 5: If the user changes his/her mind and doesn’t want to add new product, the user will simply click the back button.

Alt-Step 6: If the user changes his/her mind and doesn’t want to view the information about the product, the user will simply click the back button.

Alt-Step 8: If the user wants to automatically view the information about the product faster, the user will simply user will simply enter the Product ID of the employee and then click the search product button.
CONCLUSION:
This use case concludes when the user has returned to the main form.
POST-CONDITION:
The user must log in.
BUSINESS RULES
Only the employee in charge can access the system.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
GUI to be provided to the specified user.

5. Manage Order
USE CASE NAME:
Manage Order
USE CASE TYPE
USE CASE ID:
None
Business Requirements: 
PRIMARY BUSINESS ACTOR:
User
OTHER PARTICIPATING ACTORS:
Employee
OTHER INTERESTED STAKEHOLDERS:
Marketing –interested in sales activity in order to plan new promotion.
Procurement-interested in order to replenish inventory.
Upper management-interested in order activity to evaluate company performance and client’s satisfaction.
DESCRIPTION:
This use case describes the event of the user managing all the necessary order information from the client. You can see the manage order button on the main form. In here the user can add cancel
PRE-CONDITION:
The user managing employee information must be the one assigned to handle the system. The user must logs in.
TRIGGER:
This use case is initiated when the user logs in.
TYPICAL COURSE
Actor Action
System Response
OF EVENTS:

Step 1: The user clicks the manage order button.
Step 2: The system responds displaying the order form. The user can input customer order details on the form provided.

Step 3: For each product ordered, the system verifies the products identity.

Step 4: For each product ordered the system verifies the products identity.

Step 5: For each available product’s the system determines the price to be charge to the client.

Step 6: Once all ordered products the system determines the total cost of order.

Step 7: The system checks the clients account.
ALTERNATE COURSES:

Alt-Step 2: If the changes his/her mind and wants to cancel his/her order, the user can always went back to the main form by clicking the back button.

Alt-Step 4: If the quantity of the product is not available back order is created.

Alt-Step 7: If the status of the clients account is not good standing, record the entire payment information and send client a notice regarding his financial discrepancy.

Alt-Step 5: If the payment provided by the client cannot be validated, notify the client an request an alternative means of payment. If the client cannot provide an alternative means, cancel the order and terminate the use case.
CONCLUSION:
This use case concludes when the system generated the official receipt and the client has received it.
POST-CONDITION:
The user must log in.
BUSINESS RULES
Only the assigned person can access the system.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
GUI to be provided specified user.

6. Generate Sales Report
USE CASE NAME:
Generate Sales Report
USE CASE TYPE
USE CASE ID:
None
Business Requirements: 
PRIMARY BUSINESS ACTOR:
User
OTHER PARTICIPATING ACTORS:
Employee
OTHER INTERESTED STAKEHOLDERS:
Marketing –interested in sales activity in order to plan new promotion.
Procurement-interested in order to replenish inventory.
Upper management-interested in order activity to evaluate company performance and client’s satisfaction.
DESCRIPTION:
This use case describes the event of the user viewing the product sales report of the system. Through the recorded order from the client the system can product and print sales report.
PRE-CONDITION:
The user viewing sales report must be the one assigned to handle the system. The user must log in.
TRIGGER:
This use case is initiated when the user logs in.
TYPICAL COURSE
Actor Action
System Response
OF EVENTS:

Step 1: The user clicks the product Sales reports button.
Step 2: system responds by displaying the sales report form. The user cannot input customer order details on the form provided because it is product automatically.

Step 3: The user wants to print the report.
Step 4: The system prints the sales report.
ALTERNATE COURSES:

Alt-step 2: If the user changes his/her mind and doesn’t want to view the print report, the user can always went back to the main form by clicking the home button.

Alt-step 3: If the user changes his/her mind and doesn’t want to print the sales report, the user can always cancel the process by clicking the home button.
CONCLUSION:
This use case concludes when the system generated and printed the sales report.
POST-CONDITION:
The user must log in.
BUSINESS RULES
Only the assigned person can access the system.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
GUI to be provided to the specified user.

3.9 Use Case Glossary
Use Case Name
Use Case Description
Participating Actors
Log in
This use case describes the event of the user logging in to access the system.
User (Primary Business)
Add Employee
This use case describes the event of the user requesting to add employee.
User (Primary Business)
Employee
Edit Employee
This use case describes the event of the user requesting to edit existing employee info.
User (Primary Business)
Employee
Delete Employee
This use case describes the event of the user requesting to delete an existing employee.
User (Primary Business)
Employee
Search Employee
This use case describes the event of the user requesting to search an employee.
User (Primary Business)
Employee
Add Client
This use case describes the event of the user requesting to add client.
User (Primary Business)
Employee
Edit Client
This use case describes the event of the user requesting to edit existing client information.
User (Primary Business)
Employee
Delete Client
This use case describes the event of the user requesting to delete an existing client.
User (Primary Business)
Employee
Search Client
This use case describes the event of the user requesting to search a client.
User (Primary Business)
Employee
Add Product
This use case describes the event of the user requesting to add new product.
User (Primary Business)
Employee
Edit Product
This use case describes the event of the user requesting to edit an information about the product.
User (Primary Business)
Employee
Delete Product
This use case describes the event of the user requesting to delete an existing product.
User (Primary Business)
Employee
Search Product
This use case describes the event of the user requesting to search a product.
User (Primary Business)
Employee
Save Order

This use case describes the event of the user requesting to save newly added order of the client.
User (Primary Business)
Employee
New Order

This use case describes the event of the user requesting to generate a new order
User (Primary Business)
Employee
Generate Official Receipt
This use case describes the event of the user requesting to generate an official receipt of the sold product.
User (Primary Business)
Employee
Print O.R
This use case describes the event of the user requesting to print the official receipt.
User (Primary Business)
Employee
Print Sales Report
This use case describes the event of the user requesting to print sales report.
User (Primary Business)
Employee

3.10 Sequence Diagram

Figure 1.1 Login

Figure 1.2 Search Employee

Figure 1.3 Add Employee

Figure 1.4 Edit Employee

Figure 1.5 Delete Employee

Figure 1.6 Search Client

Figure 1.7 Add Client

Figure 1.8 Edit Client

Figure 1.9 Delete Client

Figure 1.10 Search Product

Figure 1.11 Add Product

Figure 1.12 Edit Product

Figure 1.13 Delete Product

Figure 1.14 Save Order

Figure 1.15 New Order

Figure 1.16 Generate Official Receipt (O.R)

Figure 1.17 Print O.R (Official Receipt)

Figure 1.18 Print Sales Report

3.11 Interface Design

Figure 1: Log in Form

Figure 2: Main Form

Figure 3: Message for Reminder for Viewing Employee’s Information

Figure 4: Employee List Form

Figure 5: Employee Information Form

Figure 6: Message for Deleting Employee

Figure 7: Add Employee Form

Figure 8: Message for Saving Added Employee

Figure 9: Message for Reminder for Viewing Client’s Information

Figure 10: Client List Form

Figure 11: Client Information Form

Figure 12: Message for Deleting Client

Figure 13: Add Client Form

Figure 14: Message for Saving Added Client

Figure 15: Message for Reminder for Viewing Product’s Information

Figure 16: Product List Form

Figure 17: Product Information Form

Figure 18: Message for Deleting Product

Figure 19: Add Product Form

Figure 20: Message for Saving Added Product

Figure 21: Order Form

Figure 22: Message for Saving Order

Figure 23: Official Receipt Form
Figure 24: Sales Report Form

Chapter 4: Conclusion and Recommendation
4.1 Conclusion
It is not easy to do this project without accurate information about the proponent, wide imagination of the possibilities and the social consequences of the system, patience and determination in designing the system, and most of all the cooperation and open-mindedness between the members of the group. It is proven to through the implementer of the EMCOR inventory system the reduction of stress, man-power and time taken to generate inventories than doing it manually, and the accurate data of sales report of the business. It really needs a lot of patience and extra strength in order to finish this said proposal. 4.2 Recommendation
Since EMCOR inventory system shows that a computer-based inventory system cans reduce the time needed to execute or perform inventory as well as increasing the accuracy of the results, it is recommended that the researcher should further study and gather information the high-end technology with this project. To recap, EMCOR inventory system can be a great advantage because it helps a lot not only to the staffs but also to the customer.