VERY URGENT: Website and database with ISAPI and DELPHI

This is a project for which we had a service provider selected, but they didn't do anything and just let time pass. So now we are very in a hurry! READ THIS CAREFULLY: WE NEED THIS PROJECT TO BE COMPLETED 100% BY NO MORE THAN APRIL 23rd. THE TECHNICAL STRUCTURE OF THE DATABASE RELATED TO THE HTML HAS TO BE DONE BY THIS COMING SUNDAY APRIL 16th. Because of this urgency, we are provinding here with much info, so you can know and start thing ASAP: We need a website designed for a new project which will involve access for 1. Potential customers (public access), 2. Actual customers (limited access via password), 3. Potential distributors (public access), 4. Actual distributors (limited access), 5. Potential direct salespersons (public access), 6. Actual direct salespersons (limited access), and 7. Establishments wanting to register to get a card-reading machine (see below for an explanation of products). The products are two: 1. A SmartCard with a chip that has stored the information about the person necessary to print a receipt for every purchase made (in Mexico, the only way to have a deductible purchase for tax matters is if we have a physical printed receipt with all our fiscal info on it). 2. The SmartCard Reader (kind of the machine that swipes credit cards) that reads the cards and prints the fiscal receipt. The cards will be sold by direct salespersons in a two-tier sales system directly in the websitem thru their ID. The SmartCard readers will be sold by distributors, divided by regions. Mainly, we can design and develop the webpages and the graphical aspects of our site (the presentation page, sales page, contact page, registration, etc.), but we need help in developing the databases, the relations between the databases and the webpage, and the online, real time actualization of the site. The main database for the purchases (read directly from the swiping of SmartCards) is being developed by our Systems Administrator in Borland's Interbase, so the website will have to connect with it. The database you develope must be in DB ISAM, with non-persistent queries and no mosaic. You give us the source code NOT COMPILED (we'll compile it). We won't use Microsoft databases (no SQL, no MySQL, etc.). --->>> All design will have to be done using ISAPI, and, very important, NO SCRIPT LANGUAGES. So you can NOT use asp, PHP, etc. All of these will be exclusively for Mexico. So, we need the site to be IN SPANISH. We won't attend international clients, since our product is specifically and only developed for the fiscal laws in Mexico, applying only to Mexican citizens doing business in our country. Let me tell you about the different limited areas of the website (where you'll have to program the access and the databases): CUSTOMERS Customers can be 1. Individuals, 2. Businesses with one master customer and several customers in one location, or 3. Corporations with lots of customers in several locations (with one master customer in each location or branch). Only individuals and master customers can access the limited areas of the website. There, mainly they can access their history of purchases made (date, amount, tax, name and address of the establishment or store). For master customers, this will be done for all their company, for location, for city and for every individual customer. They can filter the purchases reports by establishment, date, city, customers, etc. ASSOCIATES (SALESPERSONS) In their exclusive access area, they can view their own sales, the sales of the salespersons in their organization (2-tier), if they already met the minimum quota for each month (20 individual sales), the comission already made, the contact data of their downline. So, in essence, is access to the database of sales and downline. CARDREADER DISTRIBUTORS The area is the same as the salespersons' but they won't have a downline organization. They can have access to their sales, clients data, commisions, etc. Now, for the INTERESTING PROGRAMMING: This is the most important part of this project: Once a customer (individual or master customer) clicks to register to buy their card(s), the system will have to do several things: On the customer's end: 1. To buy, they must enter the password of the salesperson who referred them to the site. Or, enter the corporate password. Then, show the registration page, for the person to input all his/her data. 2. Save their data and assign a personal key in case they need to close the page and return later (so, they won't have to reenter all their info). For an individual this is not too much of a problem, but it is if it's a master customer registering all their locations and customers. 3. Show a personalized quote for their purchase, showing amount per customer and per location, tax and shipping costs. 4. Ask if they want to use a credit card or a direct bank deposit for their purchase or if they want to pay later (especially in case of corporate customers). If it's a credit card, show the page with the credit card info necessary to authorize the card. 5. If it's direct bank deposit, show a printable pop-up with the actual deposit slip, with all theirs and the bank's data already there. Especially, it will have to connect with our bank system to generate what is called a "Reference Number" so the system can know when they deposit and can determine to whose purchase it corresponds. 6. If it's a master customer of a company with different locations, ask if they want their cards shipped to one location or to every location. 7. Show all the data entered to be reviewed and approved. The master customer can assign privileges for every customer (delete, edit, add info). On our end: 8. When the credit card is approved or the deposit is thru, then the system will instruct the printer (a machine, not a person) to print the card(s). They are personalized with a key number, their name and valid dates (like a credit card). 9. Print the shipping label(s) to ship the card(s) 10. Print the receipt with all the fiscal data (already stored). Send a confirmation email to the customer and send the physical receipt along the cards. 11. Actualize the customers database with a new customer or customers data; actualize the sales database with the sales data, so the salesperson and their upline can check their statistics on their webpage; actualize the comissions table with the sales data, to be paid to the salesperson and their upline. 12. Once per month, check who of all the salespersons complied with their requisite in order to earn comissions. Run the comissions program to determine the actual comissions. List all the people to be paid. Generate and print the checks to be paid. Actualize the accounting and fiscal systems. 13. Once per day or once per week (we haven't yet determined this period, but probably will be daily), connect to the main database to retrieve the movements of the day relating to the use of the cards and actualize the customer database, so they can log in and check all their movements. That's the flow of information and the desired outcomes. Probably we'll need some other along the development of the project, but having the databases in place, this will be only a matter of designing tables and formats. The timeframe for this project is VERY URGENT. This HAS to be developed maximum IN THE NEXT WEEK, with the database technical structure and relation to HTML done no longer than this coming sunday! We have the diagrams for the dataflow (see attached files) and an early predesign of the homepage, but need all the database structure ASAP! Please, POST A BID ONLY IF YOU TRULY CAN DO IT IN THIS TIMEFRAME!