The document outlines an electronic requisition system plan for purchasing office supplies. It includes an executive summary describing the key internal departments (purchasing, management, receiving, accounts payable) and external vendor involved. Diagrams are provided showing the data flow and logical structure of the system. Forms and reports that will be used are also described, such as a requisition order form, purchase order, and receipt. The goal is to streamline the approval and purchasing process electronically.

1. Electronic Requisition System
Plan
IS 320
Fall 2014
Group Four
Milosz Golik, Mack Foster, Jacek Dybowski, Lajos Farkas

2. Table of Contents
Executive Summary .......................................................................................1
Business Process Flow ...................................................................................2
Assumptions/Business Rules ........................................................................4
Data Flow Diagrams.......................................................................................5
Entity Relationship Diagram .......................................................................10
Data Dictionary.............................................................................................11
Forms.............................................................................................................14
Reports..........................................................................................................17
Glossary.........................................................................................................18
Appendix.......................................................................................................19

4. 1
Executive Summary
The Project we are presenting is meant to show the process of purchasing office supplies by
employees from the vendor’s catalog on the website. The whole process requires numerous
departments that are involved in creating the requisition system. There are several major
internal departments that are crucial for the whole process, Purchasing, Management,
Receiving, and Accounts Payable. There is also an external department. In this case it is the
vendor, our supplier.
The on-line catalog contains a list of office supplies that are provided by the vendor and the
employee can specify the product and quantity he/she wants to order.
Once the employee requests the order, the information is sent to the management in order to
be approved or disapproved. After the requisition is approved the Manager sends this
document to the Purchasing Department to place the actual order. Next in the process is our
Vendor, who sends the supplies to the Receiving. After the order is received by receiving our
internal process, the Invoice is sent by the Vendor to Accounts Payable. The final process is
delivering the product by Receiving to the employee who placed the initial order.
In order to avoid the errors and improve weaknesses we used commonly used in this industry
diagrams and tools.
The most important to understand diagramwe used is Data Flow Diagram that shows the
logical meaning of the whole process, how it operates, and how each process and entity is
connected to one another. We also have included Business Process Flow that shows the flow of
the process. Another very important diagram we used is Entity Relationship Diagramthat
illustrates the logical structure in a database.
Some other tools we included in our project are forms and reports that are used by the
employees while making the actual order requisition.

5. 2
Business Process Flow

6. 3

7. 4
Assumptions/Business Rules
To make the systemefficient certain rules and assumptions must be kept and enforced.
By deploying an Electronic Requisition system we can maintain tighter control over the entire
system from the requisition process all the way to payment process. Internal controls over
expenses, payables, suppliers and customers can be enhanced. The system will eliminate many
of the manual tasks generally associated with an electronic requisition system.
By using this system users have gained significant savings and efficiencies in processing
requisitions, approving of those requisitions and creating the PO order. From PO order to
invoicing every step is simplified. Upon approval, POs can be electronically invoiced from
suppliers directly for an efficient paperless process. Automated matching occurs between the
PO and the invoice when it arrives to validate price, quantity, line amount and items ordered.
All invoices matched will be tracked against the PO until the PO is closed to account for blanket
POs or partial payment against a PO. Matching rules can be configured for further control to
ensure that invoices are properly matched to POs based on your existing business rules.
Additionally, tolerances can be applied for the entire PO or down to the line item. Automated
matching occurs between the PO and the invoice when it arrives. All invoices will be tracked
against the PO in the case of a blanket PO or partial payment against a PO. Matching rules can
be used for further control to ensure that invoices are properly matched to POs. Users, groups,
and roles are maintained in one place as well as their respective routing hierarchies and
approval limits. Your purchase requisitions and Accounts Payable users are now communicating
in a single system, which provides for ease of routing for discrepancies if invoices do not match
to the purchase order.
The electronic Requisition system:
 Streamlines the approval process
 Increases control over expenses, payables and disbursements
 Rectifies discrepancies faster

8. 5
Data Flow Diagrams
Data Flow Diagram Context Level

9. 6
Data Flow Diagram Level 0

10. 7
Level 1 CreatingRequisition
Level 1 ApprovingRequisition

11. 8
Level 1 ConfirmingPurchase Order
Level 1 ReceivingPurchase Order

12. 9
Level 1 PayingInvoice

13. 10
Entity Relationship Diagram

14. 11
Data Dictionary
EMPLOYEE: REGULAR ENTITY
EmpID : [PK] ATTRIBUTE Type:VARCHARLength=15
EmpName : ATTRIBUTE Type:CHARLength=20
EmpAddress:ATTRIBUTE Type:VARCHARLength=25
SS# : ATTRIBUTE Type:INTEGERLength=9
Depart: ATTRIBUTE Type:VARCHARLength=15
Supervisor:ATTRIBUTE Type:VARCHARLength=20
AutorLevel :ATTRIBUTE Type:INTEGER
REQUISITION: REGULAR ENTITY
ReqID: [PK] ATTRIBUTE Type:VARCHARLength=20
PoID: ATTRIBUTE Type:VARCHARLength=15
FKey:PoIDref PURCHASE ORDER
PURCH ORDER: REGULAR ENTITY
PoID: [PK] ATTRIBUTE Type:VARCHARLength=15
ReqID: ATTRIBUTE Type:VARCHARLength=20
VenID: ATTRIBUTE Type:VARCHARLength=15
FKey:ReqIDref REQUISITION
FKey:VenIDref VENDOR

15. 12
REQ LINE ITEM: WEAKENTITY
ReqLine :[PK] ATTRIBUTE Type:VARCHARLength=15
ReqID: ATTRIBUTE Type:VARCHARLength=20
Quantity: ATTRIBUTE Type:INTEGER
Price : ATTRIBUTE Type:DECIMALLength=Width=
ReqDate : ATTRIBUTE Type:DATE
FKey:ReqIDref REQUISITION
PO LINE ITEM: WEAK ENTITY
PoLine :[PK] ATTRIBUTE Type:VARCHARLength=20
PoID: ATTRIBUTE Type:VARCHARLength=15
Date : ATTRIBUTE Type:DATE
Quantity: ATTRIBUTE Type:INTEGER
Price : ATTRIBUTE Type:DECIMALLength=Width=
RcvdQty: ATTRIBUTE Type:INTEGER
RcvdDate : ATTRIBUTE Type:DATE
FKey: PoIDref PURCH ORDER
VENDOR: REGULAR ENTITY
VenID: [PK] ATTRIBUTE Type:VARCHARLength=17
VenName :ATTRIBUTE Type:CHARLength=20
VenAddress:ATTRIBUTE Type:VARCHARLength=25

16. 13
INVOICE:REGULAR ENTITY
InvoiceID:[PK] ATTRIBUTE Type:VARCHARLength=15
PoID: ATTRIBUTE Type:VARCHARLength=15
VenID: ATTRIBUTE Type:VARCHARLength=17
FKey: PoIDref PURCH ORDER
FKey: VenIDref VENDOR
INVOLINE ITEM: WEAK ENTITY
InvoiceLine :[PK] ATTRIBUTEType:VARCHARLength=20
InvoiceID:ATTRIBUTE Type:VARCHARLength=15
Quantity : ATTRIBUTE Type:INTEGER
Price : ATTRIBUTE Type:DECIMALLength=Width=
FKey: InvoiceIDref INVOICE
CATALOG: REGULAR ENTITY
ItemID: [PK] ATTRIBUTE Type:VARCHARLength=20
Description:ATTRIBUTE Type:VARCHARLength=15
Price : ATTRIBUTE Type:DECIMALLength=Width=

17. 14
Forms
RequisitionOrder

18. 15
Purchase Order

19. 16
Physical Receipt

20. 17
Reports
Order Fulfillment Report
Invoice Exception Report

21. 18
Glossary
Data Flow Diagram (DFD A graphical representation ofthe "flow" of data through an information system,
modeling its process aspects.Can be logical or physical
Entity Any objector event aboutwhich someone chooses to collectdata is an entity
Process The activities that transform or change data in an information system.They can be
either manual or automated.Signified by a rounded rectangle in a DFD.
Context Level Data Flow
Diagram
The mostbasic data flow diagram ofan organization showing how processes
transform incoming data into outgoing information
Level 0 Data Flow
Diagram
The explosion (or decomposition) ofa context-level data flow diagram thatshows
from three to nine major processes,importantdata flows, and data stores of the
system under study.
Level 1 Data Flow
Diagram
A further explosion of a level 0 data flow diagram,showing a process in a more
detailed manner while illustrating the logic required to produce the output. Also called
“child diagrams”
Data dictionary A reference work of data about data (metadata) created by a systems analystbased
on data flow diagrams;collects and coordinates specific data terms,confirming what
each term means to differentpeople in the organization
Primary Key (PK) A key that uniquelyidentifies a record
Foreign Key (FKey) A field (or collection offields) in one table that uniquelyidentifies a row of another
table. In simpler words,the foreign key is defined in a second table,butit refers to
the primary key in the first table.
Attribute Some characteristic ofan entity. There can be many attributes for each entity.
Data type A classification identifying one of various types of data, such as real, integer or
Boolean,that determines the possible values for that type (i.e. “integer” for numerical
data)
Relationship An association between entities (sometimes referred to as data association);can
take the form one-to-one,one-to-many,many-to-one,or many-to-many.
Purchase Order A commercial documentand firstofficial offer issued bya buyer to a seller,indicating
types, quantities,and agreed prices for products or services
Invoice A commercial documentissued bya seller to a buyer, relating to a sale transaction
and indicating the products,quantities,and agreed prices for products or services the
seller had provided the buyer.

22. 19
Appendix
Thisis an example of aone-to-onerelationship.Inaone-to-one relationship,one entityis linkeddirectly
to anotherentity,onlythatentityandvice versa.The vertical baron the relationshiplineclose the entity
representsitsstatusasa single entity(the “one”).Usuallythisisseenasaprimarykeyin twodifferent
tables.
Thisis an example of amany-to-one orOne-to-manyrelationship.Inthese relationships,eachentitycan
be relatedtomultiple entities.Thisisrepresentedbyaprimarykeylinkedtomanytablesviaforeign
keys.The symbol nexttothe “CHILDREN” entityisdenotedas“crowsfeet.”Thissymbol representsthe
“many” portionof the one-to-manyormany-to-one relationship.

23. 20
Thisis an example of amany-to-manyrelationship.Many-to-manyrelationshipsconstitute multiple
entitieslinkedtomultipleotherentitiesacrossseveral tables.Many-to-manyrelationshipsare generally
advisedwhendesigningdatabase relationships.Instead,one mustfindawayto transforma many-to-
manyrelationshipintoone-to-manyormany-to-one relationships.
Images found at http://www.teach-ict.com/