Property management system database

Pro-Manage Consulting Services

Apartment Management Relational Database System

MIS 6326

Summer 2014

Dr. Ryu

Kyra Detwiler, Pragati Bora, Priya Narayanan, Peter Bellino

Pro-Manage Apartment Management System – MIS6326 – Y. Ryu - Summer 2014

2

TABLE OF CONTENTS

Page No. Content

02 Table of Contents

03 Problem Description

03 Problem Statement

03 Organizational Description

03 Company Overview

03 Client Overview

04 Employees

04 Units

04 Residents

05 Workorders

05 Suppliers

05 Leases

06 Scope of Database

06 Workorder

06 JobType

07 Units

07 Lease

07 Resident

08 Occupants

08 Lease_Payment

09 PaymentCategory

09 PaymentType

09 Supplier_Order

09 Supplier

10 Part

10 WorkOrder_Part

10 Emplolyee_WorkOrder

11 Employee

12 Entity Relationship Diagram

13 Relational Database Schema

15 Main Menu and Data Input Screen Forms

38 Contributions Page


3

PROBLEM DESCRIPTION

Problem Statement

Since 2008, there has been substantial growth in residential apartment and

communal living properties, like dormitories, senior living centers, extended-stay

residences, and others management properties. One of the largest challenges in

maintaining operating as a landlord or property manager is balancing the various

dynamics that occur daily regarding new residents, requests for repairs, and

balancing payments and invoices. A professional system that integrates the

important information like lease obligations, resident details, work requests,

payments from tenants and to suppliers is a requirement in order to maintain the

property, operate efficiently, and ensure resident’s satisfaction. Our company,

Pro-Manage Consulting, Inc. has designed a system that can help a property

manager maintain their community in a centralized system.

Organizational Description

Company Overview

Pro-Manage Consulting, Inc. is a software development company that designs and

implements management systems for single and multi-unit residential property

management companies and was founded by four students at the University of

Texas at Dallas.

Client Overview

In this example, the client, University Village Apartments, located on the campus

of the University of Texas at Dallas has installed the Pro-Manage Apartment

Management System. With this system, the property management team will be

able to insert new resident information, create leases for apartments, accept

payments for rent and track payments to suppliers.


4

Employees

Although in a real-world application, all employees would need to be documented

into the Pro-Manage system, in this example, we have used 4 employees as

maintenance workers who help repair issues submitted on a customer’s

workorder.

Units

In this example, University Village has 25 units, ranging in size square footage size,

from 650 sqft. to 1090 sqft. and number of bedrooms and bathrooms, with

between 1 and 2 bedrooms, and 1 or 2 bathrooms, depending on the unit size.

Residents

Although most apartment complexes would prefer to have a very high occupancy

rate, due to operating without a comprehensive management system, University

Village has suffered a significant move-out rate, resulting in only 20 residents

currently holding leases within the complex.

Workorders

One of the advantages to tenants in an apartment is that they can call the

apartment’s management office and place workorder requests with the staff of

the apartment complex to have repairs made. One of the most important

functions that this system performs is to allow the complex to track the status,

estimated times to complete and estimated and actual costs related the

requested task.

Suppliers

In order to resolve the workorders that might be placed with the apartment staff,

the complex must have specific suppliers in order to provide the needed

replacement items that meet their needs, either in quality, style, or cost, such as

light bulbs or patches of carpet.


5

Leases

The backbone of every residential community is effective management of leases,

from keeping records on current contracts to knowing when new units might

become available. The lease outlines the expectations of both the resident and

the management company, including the agreed amount of rent due each month

and security deposits paid. Effective reporting on the lease element of the

apartment’s operations can spell the difference between successful management

and a failing community.


6

SCOPE OF DATABASE

WorkOrder

This project began as a focus on how to manage workorder requests from tenants

in a managed property, however as we continued to develop this application, we

found that there were many more items that were critical to the operations of a

property management service, and expanded our scope to include these items.

However, WorkOrder was the foundation around which this project was

developed. This table tracks each work order request through a WorkOrderID,

which is the primary key. The UnitNo is a foreign key from the Units table, as

each workorder must have a Unit number attached to it. Next the WOType is

based on the JobType coming from the JobType table. WODate accepts a date

that the work order was created, so that a starting point can be determined when

the issue was reported. Priority is an descriptor ranging from “Low, Medium,

High, Urgent”. ProblemDescription is a field that permits a note that provides

more specific details about the problem. CompletionDate identifies the date that

the workorder was completed. StartDate is the date that the actual work started

on the issue, different from the WODate as there may be a delay between when

the workorder was submitted and the activity actually began. Finally,

PermissionToEnter is an attribute that identifies whether the apartment’s

employees may enter the premise to complete the workorder without the

presence of the tenant. If a tenant does not give permission, appointment details

are noted in the ProblemDescription field so that the task may be completed in a

timely manner to the tenant’s satisfaction.

Job Type

This table contains a two attributes, JobType.as the primary key, and Estimated

Hours as an attribute. The JobType is an item like “Change Light bulb” and has an

expected amount of time that would be required to complete the associated task,

such as “5 minutes.” This permits the property manager to know how much time

each workorder might take.


7

Units

The Units table is built around UnitNo as the primary key, as each apartment

complex may only have a single location labeled as “Unit #A1” for example. In

this table, attributes like Area_SqFt, Bedroom, Bathroom, and Garage indicate the

unit size (in square footage), number of bedroom, number of bathrooms, and

presence of an attached garage, respectively. Also, a Notes field is present to

allow any special notes about the specific unit to be documented, such as a

sunroom or patio.

Lease

As this project has developed, the Lease table has become critical to the overall

success of this project. This table uses a unique “LeaseID” as the primary key to

track each individual lease maintained within the community. The ResidentID and

UnitNo are foreign keys from the Resident and Unit tables respectively, outlining

who is associated with the lease and which unit it is applicable to. Other details,

such as LeaseDate, LeaseStartDate, and LeaseEndDate may be documented to

show when the lease was drafted and the effective start and end dates. The

LeaseTerm attribute provides the expected duration of the lease and is present

because some leases may need to be terminated early due to unforeseen

circumstances between either the tenant or property. MonthlyRent,

SecurityDeposit, and PetDeposit are all attributes that are available to indicate

what the agreed monthly rent will be, as well as the presence of any deposits,

either for security towards potential damages, or for pets, and the expected costs

associated with turning over a unit to prepare for new tenants.

Resident

As foreign key to the Lease table, the ResidentID is the primary key of the

Resident table. This item identifies each resident that is listed on the lease.

However this is slightly different from an occupant. The Resident is the primary

individual on the lease, with others listed in a subordinate position to the

resident. This table provides information captured from the Occupants table

about the Resident, including the name through the ResidentFirstName and

ResidentLastName fields, contact information through the ResidentEmailAddress,


8

ResidentMobileNumber and ResidentHomeNumber. The Attachment field on the

Resident table permits the presence of a photograph, scanned image of a state-

issued ID, or other image to be included in the resident’s record. Finally a Notes

field is provided so that any additional details maybe documented about the

specific resident and their group.

Occupants

The Occupants table uses a primary key developed from both a unique ResID and

a unique MemberNo. The ResID, which provides the primary key for the Resident

table, is used to identify a group of residents that might be within a unit. The

MemberNo is used to identify the individual occupants that might be residing

within a residence. Only basic name information is needed, captured through the

OccupantFirstName and OccupantLastName fields. This table is used to capture

information about all persons residing within the community, including those that

might not be signors of the lease, such as a minor child, or that might be in a

subordinate position on the lease, such as a spouse or roommate. Each group of

residents will have a unique ResID, such as 005, and then a MemberID based on

their position on the lease, with the primary Resident having the “01” identifier,

and others having a subsequent number based on their position, such as “02”,

“03”, “04”, and so on.

Lease_Payment

In order for a managed property to remain financially viable, it must track every

dollar that is owed to it through it’s lease agreements. The Lease_Payment table

tracks each payment made with a unique PaymentID, which serves as the primary

key for this table. Each payment made will be attributed to a specific LeaseID

from the Lease table, and is used to match the payment to the appropriate payee

and lease. Other details, including payment type and payment category are

foreign keys, and used to correctly match each payment to the charge needing

remuneration. Other fields included are PaymentDate, PaymentAmount,

ReferenceNo, and PaymentDueDate provide additional details that are captured

referencing the Payment Date, amount paid, transaction reference number (such

as through a credit card transaction), and due date for payment respectively.


9

PaymentCategory

This table outlines different types of payments to be made, such as “Rent”,

“Utilities”, or “Fees”, such as for a late rental payment or as a processing fee for

running background applications on new residents. The PaymentCatID is the

primary key and is used to identify a specific category of payment to be made.

The PaymentCategory is a textual description s that identifies the payment

category with more details than just a identifying number.

PaymentType

This table uses a PaymentTypeID as the primary key to differentiate between

different payment types, which are defined in a text format through the

PaymentType field. This can include types of payment like cash, check, Visa,

MasterCard, or others.

Supplier_Order

The Supplier_Order table is used to track order requests to suppliers for various

parts , or other consumables. Using a primary key of OrderID to track each order

through a unique and ascending order number, this table also tracks the part

numbers ordered, using PartNo as a foreign key from the Part table and a

SupplierNo, which is used to identify approved suppliers, the list of which is

contained on the Supplier table. Other details of this item include a payment

type, gleaned from the aforementioned PaymentType table, and transaction date

and amount, documented in the TransactionDate and TransactionAmount fields

correspondingly.

Supplier

The primary key of the Supplier table is the SupplierNo field, which identifies each

approved supplier through a unique number. Additional information is captured

about each supplier, including the name of the supplier, their address, including

street, city, state, and zip code information, and their contact phone number.

This information is contained in the SupplierName, SupplierStreet, SupplierCity,

SupplierState, SupplierZip, and SupplierPhoneNumber fields individually.


10

Part

In order to keep track of what specific parts are used throughout the property,

the Part table allows the management company to maintain an ongoing inventory

and ensure that they order the correct replacement items, such as the correct

style and color of carpet for replacements, or the correct type of light bulb for

specialty fixtures throughout the complex. Using a unique part number to

identify each specific part, other details are also captured such as the part name

(held in the PartName field), the description of the part (PartDescription), the Unit

Price for the part (UnitPrice) and quantity available in inventory

(QuantityAvailable). If the quantity of a part is less than that which is required, a

Supplier Order can be placed with the specific supplier to reorder more units of a

specific item.

WorkOrder_Part

Coming back to the work order management function of this application, the

WorkOrder_Part table is designed to allow the management company to track

required amount of parts needed on a specific workorder. Using PartNo from the

Part table and WorkOrderID from the WorkOrder table as primary and foreign

keys, this table aids in ensuring that the required parts are accounted for prior to

starting on a workorder, with the hopes of avoiding delays in resolving the

workorder due to needing to order additional parts after the work has begun.

Employee_WorkOrder

The workorder submitted by tenants must be completed by apartment property

employees. In order to track employees and the jobs that they have worked, the

Employee_WorkOrder table is needed to identify the employee that worked on a

project, the specific project that they worked on, and other pertinent details, such

as the actual hours worked on a task, the status of the workorder, the completion

date of the item, as well as resident feedback about the task and an overall rating

between “1” to “5” with a score of “5” being very good. This table uses the

EmployeeID from the Employee table and the WorkOrderID from the WorkOrder

table as primary keys to track the details of each completed work request.


11

Employee

The final table that we created for this project at this time is the Employee table

to identify the numerous employees that work for the property. Each employee

is provided an Employee ID which serves as the primary key of this table in the

EmployeeID field. Other details are documented about the employee as well,

including their job title (EmpJobTitle), their name (EmpFirstName and

EmpLastName), their home address (EmpStreet, EmpCity, EmpState,

EmpZipCode), and contact information (EmpPhoneNumber).


12

ENTITY RELATIONSHIP DIAGRAM


13

RELATIONAL DATABASE SCHEMA

Unit (UnitNo, Area_Sqft, Bedroom, Garage, Notes, Photographs)

Resident (Res_ID, ResFirstName, ResLastName, ResEmailAddress,

ResHomePhone, ResMobilePhone, Attachment, Notes)

Resident.ResFirstName NOT NULL

Resident.ResLastName NOT NULL

Occupant (Res_ID, Member_No, Occupant_FirstName, Occupant_LastName)

Occupant.Res_ID references Resident.Res_ID

Lease (Lease_ID, Res_ID, UnitNo, LeaseDate, LeaseStartDate, LeaseEndDate,

LeaseTerm, MonthlyRent, SecurityDeposit, PetDeposit)

Lease.Res_ID references Resident.Res_ID

Lease.UnitNo references Unit.UnitNo

Lease.UnitNo NOT NULL

Lease.Res_ID NOT NULL

PaymentType (PaymentType_ID, PaymentType)

PaymentType.PaymentType NOT NULL

PaymentCategory (PaymentCatID, PaymentCategory)

PaymentCategory.PaymentCategory NOT NULL

LeasePayment (LeasePaymentID, LeaseID, PaymentType, PaymentCategory,

PaymentDate, PaymentDueDate, PaymentAmount, ReferenceNo)

LeasePayment.LeaseID references Lease.LeaseID

LeasePayment.PaymentType references PaymentType.PaymentType_ID

LeasePayment.PaymentCategory references PaymentCategory.PaymentCatID

LeasePayment.LeaseID NOT NULL


14

JobType (JobType, EstimatedHours)

JobType.EstimatedHours NOT NULL

WorkOrder (WorkOrderID, UnitNo, WOType, WODate, Priority,

ProblemDescription, CompletionDate, StartDate, PermissionToEnter)

WorkOrder.UnitNo references Unit.UnitNo

WorkOrder.WOType references JobType.JobType

WorkOrder.UnitNo NOT NULL

Employee (Employee_ID, EmpJobTitle, EmpFirstName, EmpLastName, EmpStreet,

EmpCity, EmpState, EmpZipCode, EmpPhoneNumber)

Employee.EmpFirstName NOT NULL

Employee.EmpLastName NOT NULL

Employee_WorkOrder (EmployeeID, WorkOrderID, Actual Hours, Status,

CompletionDate, ResidentFeedback, Rating)

Employee_WorkOrder.EmployeeID references Employee.Employee_ID

Employee_WorkOrder.WorkOrderID references WorkOrder.WorkOrderID

Part (PartNo, PartName, PartDescription, UnitPrice, QuantityAvailable)

WorkOrder_Part (PartNo, WorkOrderID, Quantity)

Supplier (SupplierNo, SupplierName, SupplierStreet, SupplierCity, SupplierState,

SupplierZip, SupplierPhoneNumber)

Supplier_Order (OrderID, PartNo, SupplierNo, PaymentTypeID, TransactionDate,

TransactionAmount)

Supplier_Order.PartNo references Part.PartNo

Supplier_Order.SupplierNo references Supplier.SupplierNo

Supplier_OrderPaymentTypeID references PaymentType.PaymentTypeID

Supplier_Order.PartNo NOT NULL

Supplier_Order.SupplierNo NOT NULL


15

MAIN MENU AND DATA INPUT SCREEN FORMS

Main Menu

The main menu allows navigation to the Lease, Units, Suppliers, Residents,

Employees, and Work Orders and to the Reports menu.

Description of Buttons

Units Button Navigate to Units Resident Details button Navigate to Resident Details Reports button Navigate to Reports Menu Lease Details button Navigate to Lease Details Suppliers button Navigate to Supplier Details Employees button Navigate to Employee Details WorkOrders button Navigate to WorkOrders


16

Lease Details – from Main Menu

This form gives details of all the leases and the associated Payment History

related to particular lease


Units Button Navigate to Units Resident button Navigate to Resident Details New Lease button Make a New Lease Record Close button Exit


17

Lease Details>>New Lease:

By clicking on the New Lease button, the Property Management Team can add

new leases. Navigation to the Unit or Resident forms is possible through the

buttons at the top.


18

Supplier>>from Main Menu:

This form provides information of individual suppliers and the parts associated to

them. The Payment Transactions related to each Supplier can also be viewed

here. We can also navigate to the Supplier List and Orders through buttons at the

top.


Add New Supplier Button To Add new supplier data to DB Supplier List button View complete list of Suppliers Order Order New Parts Close button Exit


19

Add New Supplier

Supplier List


20

Submit new order

By clicking on the Order button in the Supplier form, the Property Management

Team can view all the Order placed to the individual Suppliers.


21

Employee – from Main menu

This form provides the information of individual Employee and the Work Orders

associated with them.


Create Wororders Button To Create new Workorder WorkOrders button View complete list Workorders by an

employee Close button Exit


22

Employee Work Order

This form provides you the Employee specific Work Order information.


23

Units >> from Main Menu –

This form will give the detailed information of all the units along with the details

of the current residents.


Vacant Units List of vacant Units

Expiring Leases List of Expiring Leases


24

Vacant Units

List of Vacant Units

Expiring Leases

List of leases about to expire in next 75 days.


25

Resident Details >> from main menu

This form provides detailed information of the residents of University Village

Apartments. Both current and past residents can be viewed in the resident details

form.


Add New Resident Button To add new customer Lease Details button Navigate to lease details Close button Exit


26

Add new resident

This form allows the Property Management Team to add new residents by clicking

on the ’Add New Resident’ button in the Resident Details page.


27

Work order – from main menu

This form provides detailed information of all the work orders.


Create New WorkOrder Button To create new Workorder Employees button To Employee Details


28

Create new work order

By clicking on the ‘Create New WorkOrder’ button, we can create new work

orders.


29

Reports>>From Main Menu

List of various generated reports facilitates easy navigation to required report

The description of various reports is in table below and Screenshots Follow

Report Description Expiring Leases Report A report of all leases about to expire in next 75

days Employee Feedback Report Aggregated report of all employee feedbacks and

rating Security Deposit Refund Letter A report needed to refund security deposit of a

customer leaving apartment Payments by Lease Report Earnings from each lease (Total payments

received) Supplier Transaction Report Transactions in $ with each supplier by parts

WorkOrders by Year Report Maintenance requests raised during a year

Suppliers History $ Amount transactions with supplier over a selected period

Resident Contact Book A handy list of all resident contacts (Directory)


30

Expiring Leases Report

A report of all leases about to expire in next 75 days


31

Employee Feedback by workorder Report:

Aggregated report of all employee feedbacks and rating


32

Security Deposit Refund Letter

A report needed to refund security deposit of a customer leaving apartment


33

Payments by Lease Report


34

Supplier Transaction Report

Transactions in $ with each supplier by parts


35


36

WorkOrders by Year Report

Maintenance requests rose during a year


37

Suppliers History

$ Amount transactions with supplier over a selected period


38

Resident Contact Book

A handy directory of all customer contacts

CONTRIBUTION PAGE


39

Kyra Detwiler

Collected screenshots of menu, input and form screens, and reports, and

provided descriptions of each.

Contributed to idea, provided feedback and collaborated on outline of

ERD and database.

Pragati Bora

Designed database in Access, created forms, reports, and menu screens.

Collaborated on outline of ERD and report.

Priya Narayanan

Designed ERD and relational model schema.

Contributed to idea and collaborated on outline of database, ERD, and

report.

Peter Bellino

Wrote problem description, company outline, database scope, and

compiled report.

Contributed to idea and collaborated on outline of database and ERD.

Property management system database

Education

Transcript of Property management system database