ASP Classic Purchase Requisition System

This is a pretty simple system in comparison with other puchasing systems. We have an internal website setup on Windows 2003 with a SQL Express 2005 database setup to authenticate via windows integrated authentication. No design is needed. I will give you the header and footer include files that have all design elements. You will have a main content div within which you can work. No client side scripting, no AJAX, no third party plugins, no dlls, only straight ASP with VBScript and HTML. Please keep abstraction and modularity to reasonable limits. I don't like digging through 5 files to troubleshoot a simple database call. It is within this context that you must create this application. You can also assume a session variable set to the user's login name to verify identity. For instance: User Joe Smith goes to website - default page will authenticate and set session variable based on his Windows Username such as "jsmith". Each page should verify this session variable is set, and use this variable as the basis for identifying the user. Role based security will be used to identify who can access the purchasing area, admin area, and other roles as necessary. This will need to be part of this application. You will need to create a database driven application that will accept a purchase requisiton, route for approval, and "deliver" to the purchasing department all within this website. You will be required too create the database structure. It will need to be reviewed by me before work begins on the actual website. Home Page: Should show four sections: wating approval (this is reqs that need to be approved by this person) unsubmitted, in process, and completed requisitions. Should have nav links to these actions: create new, modify unsubmitted (also a link to this by clicking on list), modify in process (also a link to this by clicking on list) Create New Page: I will give you all the feilds need to be stored. I would like you to mimic the spreadsheet layout that is attached (within reason, doesn't have to be exact). All fields need to be sanitized for sql injection, but most do not need to be sanitized for content (only things like money feilds and such). Should have a drop down to select a supplier, or the ability to enter a new one. Every supplier must be created, then they can select it to create a requisition. Therefore there will need to be a supplier entry page. Each user's suppliers should be seperate (not a company wide pool, but that option in addition would be neat). Data will be inserted to db. Modify pages: Similar to New page, but for modifications. Also a cancel/delete option. Purchasing Area: If as user is identified as a member of the purchasing role, they can access this area. It should show all approved reqs, and what status they are in (submitted, in progress, purchased, delivered, back ordered, issue found). They should also have the ability to print a req in a format like the spreadsheet attached. They can also move each req to a different status, or kick back to the originator. Routing: Upon insertion of a requisition, the application needs to check if the submitter has a puchase authority higher than the amount of the requisition. This should be a table that lists the user and his authority. This should be modifyable in the admin section. If they do have the authority for that purchase amount, then send to the purchasing department/area. If they do not have authority for this purchase amount, route to thier supervisor for approval (I will give you a com object you can call to retrieve the supervisor). The supervisor must approve; if the supervisor does not have authority to for the purchase amount, route to his supervisor. And so on until finally some one can purchase that amount. This is certainly not a full description of everything needed. Please do not consider this a complete list of all features/pages needed. Some features/pages/programming not discussed may be an inherent part of an application like this, others may need to be added once we get into details of the system. This is expected to be part of your bid. There will be no additional charges for features inherent to a successful project. All clarification on features should be made before bidding.