PomsApp – A SaaS Web Application for Purchase Order Management – Draft 1 Rev 2

About two months ago, I decided to build a web application. I looked at the various offerings that were available and decided that the Web Application I would write would help manage Purchase Orders. I now have the first draft, which is just high level requirements for the system. Only the functionality of the app is covered – not the meta structure supporting it like the billing, infrastructure, support etc.

When I wrote the first draft a couple of months ago, the system was more complex. Even then I had not finished it. For example it had the concept of multiple approvers, roles for CEO or CFO etc. In this one – Revision 2, I am posting an updated design that I rewrote this week. In this version the functionality is much simpler. I have removed all extraneous roles, I even reduced the possible statuses removing “partially approved” and even “Closed”. I was inspired to do this after reading the book “Getting Real” by the authors of 37signals.com.

Without further ado, here is rev 2 of the first draft.

Introducing PomsApp:

PomsApp is Purchase Order Management System used by small businesses and startups. It lets you manage the PO from the initial stage of Requisition to the final stage of Payment.

Importance of a PO and where PomsApp helps:

A purchase order can help your business operate more effectively.  The purchase order specifies the exact stock required, the quantity and a number of other important details about your order. By stipulating the details of your order you can eliminate any possible mix-ups, and delays in receiving your order. Given the importance of the PO to your business, it is imperative that you manage the PO as efficiently and accurately as possible. This is where PomsApp helps you.

Highlights:

1. In terms of users, PomsApp allows you to define roles, responsibilities, authorities.
2. You can compare Quotes from multiple vendors and select one to proceed with. It allows you to attach these Quotes (PDFs or JPEGs) to the requisition.
3. It generates the PO as a PDF and emails it for you (sending you a copy).
4. After the ordered item is received and accepted, it allows you to follow up with the payment before you close the PO.
5. All web pages are always served with SSL. So you can be assured that your credentials and data are secure.

Roles:

1. SA – System Administrator – sets up the system and configures it.
2. Requestor – person who ultimately needs the item. This can be any employee in the company.
3. Approver – this can be any employee designated with that role by the SA.

The same person can assume multiple roles (for example in a one person company) if the roles were set up that way.

Initial Setup by System Administrator:

1. Define Company Name
2. Define Sites and Addresses (like HQ, Data Center, Colo Facility, Denver Office, etc). SA can always add more sites and remove sites as needed

Setup Options Available to SA:

1. Add, Edit, and Remove a site (A site is an office location of this company that creates the PO. This is useful as a delivery location)
2. Add/Edit/Remove Vendors (only SA can remove vendor)
3. Add, Edit, and Delete employees of this company

a.  Edit includes: Disable login, Designate as Approver

Actions Available to Requestor:

1. Create new Request
2. Add notes to the Request (like justification) – at any state even “Rejected” and “Paid”
3. Modify Request – only before approval (things like quantity, item name, etc)
4. Create or Edit Vendor (company)
5. Add/Edit/Remove Vendor Contact
6. Associate potential candidate vendors with a Request
7. Request Quotes from Vendor Contacts
8. Attach received Quotes to a Request
9. Select “winner” Vendor to fulfill this Request
10. Save draft Request
11. Delete draft Request
12. Ask for “approval” of the Request from “Approver” – this generates a notification to the approver. This also assigns the Request to the Approver.
13. “Promote” Approved Request to a “PO” – status now becomes “Ordered”. This sends and email to the vendor with a PO in PDF form as attachment.
14. Change PO status to “Received”
15. Change PO status to “Paid”
16. Cancel a PO that was issued

Actions Available to Approver

1. Approve request – status now becomes “Approved”
2. Reject request – status now becomes “Rejected”
3. Change “winner” Vendor – with justification
4. “Promote” Approved Request to a “PO” – status now becomes “Ordered”
5. Add notes to PO
6. Assign unapproved request back to the requestor (or any other employee) by adding notes – this generates a notification to the assignee (use case is when approver is asking for additional justification)

Features and abilities:

1. Everybody always has to be logged in to do anything useful.
2. Requestor has a need for an item
   1. Requestor clicks on “New Request”
   2. Required fields are “Item”, “Quantity”, “Unit of measurement”. Item is a multiline field.
   3. A Request allows multiple items. At the end of each item, the buttons say “Save Purchase Request”, “Save Purchase Request and Add Another Item”. There will be two links that say “Discard this Item and Save Request”, “Discard Purchase Request”
   4. As a general rule, when discarding there will be no prompt saying “Are you sure?” Instead on the following screen/page there will be a prominent link that says “Purchase Request Discarded. Undo”. If the Requestor wants to ‘Undo’, then they can just click on that link and everything comes back as if nothing happened, and they are be able to continue.
3. Requestor wants to provide justification for a new purchase request
   1. This is just part of ‘New Request’. Empty value is OK.
   2. This justification is for internal use only and does not show up in the purchase order.
4. Requestor wants to provide additional justification for an existing purchase request
   1. Requestor will be able to update the justification (by adding additional justification) at any time. Existing committed justification values cannot be edited. If they have made a mistake, they can just add more justification and point out the error. This is to ensure an audit trail.
5. Requestor wants to modify an existing request
   1. Requestor browses a list of existing open requests and selects from there. Requests that have become “Approved” or “Rejected” cannot be modified (except to add notes).
6. Once a Request is **promoted** to become a PO, it remains a PO and cannot be modified, except to cancel it. The number remains the same. So if the request ID was X123, the PO number is X123.
7. Requestor wants to add a new vendor
   1. Requestor clicks on ‘Add a new vendor’. As the new vendor is added, ‘type-ahead’ will suggest existing vendors based on exact spelling as well as approximate spelling. If an existing vendor is then selected from the list, a new vendor is not added to the system, but the existing one will be used.
8. Requestor wants to add a new Vendor Contact
   1. Requestor selects a vendor from the vendor list, and then adds a new contact. Fields are First Name, Last Name, Email, Cell Phone Number, Work Phone Number, Fax Number, Notes
   2. There will be two buttons – “Save Contact”, “Save Contact and Add Another”. There will be a link called “Cancel and return to Vendor List”
9. Requestor wants to request Quotes from candidate vendors
   1. At any time, requestor should be able to select potential vendors from a list of vendors in the system.
   2. Requestor should be able to send an email to vendor(s) from the system by clicking on a button asking for Quotes. The body of the email will contain some text that the user can enter, plus the list of items requested.
10. Requestor wants to attach Quotes to the request
    1. When the requestor receives a Quote from a vendor, he should be able to upload the Quote file/PDF as an attachment to the request, along with a comment.
11. Requestor should be able to choose a “winner” vendor from the potential candidates after reviewing the Quotes.
    1. A justification comment should be filled in when choosing the winner.
12. Requestor should be able to “promote” a Request to a PO. The status will become “Ordered”. Approver should also be able to do this. Only a Request that is already in “Approved” state can be promoted to a PO (“Ordered”)
    1. When the request is promoted to a PO, a confirmation page will display saying “Vendor XYZ has been chosen to fulfill the Purchase Request. They will be notified immediately and a Purchase Order will be sent by email to.” Two buttons called “Create Purchase Order” and “Cancel” will be shown and the expected action will happen when they are clicked.
13. When Approver does not approve a request, or even after it has been approved, the approver must have the option to reject a request.
    1. When the requestor is logged in, he should have an option to see all his open requests. Open requests include approved requests.
    2. Approved requests can be promoted to Purchase Order, or can be Rejected.
    3. Open requests can also be Rejected
14. Statuses are
    1. Open – a new request is created and not yet rejected and not yet approved.
    2. Approved – the approver has approved the request
    3. Rejected
    4. Ordered
    5. Received
    6. Paid
    7. There will be no Closed or completed. Paid and Rejected are final states.

State transitions:

Legend: Old State -> Action -> New State

1. “Nothing” -> New Request -> Open
2. Open -> Reject -> Rejected
3. Open -> Approve -> Approved
4. Approved -> Promote -> Ordered
5. Ordered -> Goods Received -> Received
6. Received -> Log Payment -> Paid

Both Rejected and Paid are end states from which no transition can happen. ‘Add notes’ can happen at any state and is the default action at any state.

Class definitions:

For all humans

• First Name
• Last Name
• Email (double up as user name)
• Phone number
• Roles – multiple selection possible

Roles:

1. Role Name

Settings:

No Settings!