XML Shopping cart, front & back ends

> You agree to develop a shopping cart (front and back ends) which interfaces with the Propay XML system to process credit cards and customers orders. It's imperative that you read the propay xml page so you know what has to be done. (ref: <[login to view URL])> You will have to work with us to get the testing done as well. (see 3.0 in the reference doc). We cannot move forward until you read the document and understand it. Please confirm this when you have done so. > > You will create a professional looking invoice for the customer to print out as their receipt, which will be a pull ticket for our employees. Customers will have the option of creating an account or checking out w/o creating an account. > Create a database which will be populated by uploading vendor spreadsheets and/or using manual input. To create a system where we can manually add products and categories. You will use Python, Perl or maybe Ruby? for the language and the database is up to you. No flash, no java. Keep it simple, but functional and appealing. Please see below for a complete description of the job. Thank you ## Deliverables Here is the complete description to the best of our ability to describe it: You agree to develop a shopping cart (front and back ends) which interfaces with the Propay XML system to process credit cards and customers orders. It's imperative that you read the propay xml page so you know what has to be done. (ref: <[login to view URL]>) You will have to work with us to get the testing done as well. (see 3.0 in the reference doc). We cannot move forward until you read the document and understand it. Please confirm this when you have done so. Prefered languages are python, perl or ruby. You will create a professional looking invoice for the customer to print out as their receipt, which will be a pull ticket for our employees. Customers will have the option of creating an account or checking out w/o creating an account. To allow us to enter 1 to 5 tracking numbers so the customer can log into their account to view the progress of their order. Also, next to the tracking boxes, we should have options like: (check box) Order accepted (The system will show this box as checked on all orders unless there is a malfunction with the cart. Ie, empty cart or cart with some unknown part number, negative amount, etc) (check box) Credit card processed (Show ProPay Result Code: (with an explanation so they know what the codes mean) Depending on Result Code, display additional information and instructions to the customer. (check box) Order pulled, packaged and ready for pickup. (If employee added tracking no. information, it should be displayed here. Also employ may enter notes here like "shipping from multiple locations" or "shipping from state" "see email from shipper for tracking no." The admin will setup some of these with check boxes so it's easier for the employ to select one, or more, or type in their own msg. (check box) Order back ordered (partial/full). Once an order has been accessed by an employee, it will not be shown to other employees to avoid duplicate orders. Once an order has been filled, the employee will mark the status and has the option to enter tracking number(s). If the customer logs in, they will see theirs credit card has been charged and the status of the order. If a customer logs in and sees their order has not been charged they can add to their order. But once an order has had a successful payment via the ProPay system, it's locked for further changes. Just a note to them that they can add to their order by placing a new order. Customer can log into their account (if created) to see the status of their order. There should be options for the customer to "accept partial back order, ie, ship what you have now, and ship the rest when it comes in. (May incurr additional shipping charges)" or "hold order till full." It would be great if the system could send the customer an email with an update if the employee marks an order as "back ordered" with instructions to them to tell us what they want us to do. There will be at least 3 different account levals to the system: Admin, employee, customer. Admin has full access. Employee has access to orders so that they can pull them and updates status. Every order has to be tracked by which employee pulled the order. Employees can only access tickets they pulled. Admin of course can access all. Customers can only access their orders of course. It would be nice to have a system that calculates how long it took from the time the employee pulled the order from the queue to the time they marked it ready for pickup or backordered. Admin is the only one that can change prices, upload new spreadsheets, add product, etc. I think this is pretty standard procedure. Admin can put certain orders "on hold" so that employees do not see them. Customer would see "on hold" for status with instructions on how to proceed.. It's VERY important that the customer of the option of just adding to cart and check out, fast like the existing cart is, or the customer can create their account, upload their info and check out easier because their info is held. It should be at the end of the process. Ie, any customer can immediately add things they see to their cart. When the click on checkout, they are given the option to log into an existing account, create an account or "quick checkout with no account required." (And then we'll notate the benefits to creating an account.) This will be one of the advantages of a customer creating an account. w/o creating an account they will not be able to log in to see the status of their order. Of course we will be able to see it. But they will have to go off their email notification and the notification of the shipper. If they create an account they will have access to their orders status, shipping details, etc. In all cases the customer will get an email copy of their order. The admin will also get an email on every order, which will show at least the amount, customer name, ProPay result code and shipping method selected. (We might want additional info in that notification email, but for now that'll do it.) We also need to be able to show returns. Ie, after the order has been shipped, at some later time, if the customer returns something, we need to be able to go in and change the invoice to reflect the return, which will show credit, minus restocking charges (and maybe reshipping charges.), etc. These updated figures have to be used when running the reports of course. Create a database which will be populated by uploading vendor spreadsheets and/or using manual input. To create a system where we can manually add products and categories. The way I see this is the admin would log in and create categories. Then under each category the admin can create additional subcategories and then subcats under them. When a spreadsheet is uploaded, it'll give us the ability to specify which category it's to go to. There is the possibility that a spreadsheet will have many categories in a single spreadsheet. So what I propose is when the admin creates the category or subcat, the admin is given the option to specify a category number(s), which will match the prefix of the part number in the spreadsheet being uploaded. Hopefully there will be minimal duplicatation in this number, but it's possible so it should be checked. To develop shipping logic based on item shipping category. Probably 10 categories with each a base amount and a cost ($) per pound (#) amount. That we can easily update both the base amount and the $/# amount. That final shipping cost will be the sum of the base amounts plus the sum of the $/# amounts. Initially the system can calculate the weight of each item from the spreadsheet. HOWEVER the spreadsheets sometimes have missing information. So in cases where the weight is zero or missing, something needs to be done so that we know and can manually enter the info. When a spreadsheet is uploaded, it should ask what will be the default shipping category. We can then go in and manually change them as needed. When an item is added to the database manually it'll ask for this information. To have a system for expedited shipping. (next day am, next day PM, 2nd day, etc). At this point, I think the only option is to give the customer the option. Do you want "ground" (the default), 2nd Day, Next Day AM, Next Day PM, Sat Delivery. I will have to write a paragraph of information on this to display to the customer. We will have the cart run the order with the ground shipping calculated and then I'll manually run the extra charges for shipping. That's the only way to do it. But on any order that has one of the non-ground options checked, the admin needs to get an email with that information. To develop pricing schedule system for each manuf. based on quantity ordered, ie, individual parts, price by the bag, price by the box, by the 6box price, and by the pallet for each category of part. In the spreadsheets it shows "list" and then we apply multipliers for "individual" "by the bag" "by the box" "by the 6 box" and "by the 20 box ie, pallet" prices. So each of those quantities will have a multiplier attached to it. For items uploaded via spreadsheet, this is good. For items entered manually, (not of the same manuf.) then they will have their own price schedule. (this is not too bad as those items only have "individual" and "by the 100" and "by the 500" prices. They will all have a list price, and then say 3 different multipliers. When these are shown, they will also have to show the quantity for each level. (ie, 100, or 500, and these quantity leveles need to be setable by admin and change is possible.) To display products based on categories. Some products will belong to more than one category. Categories will contain parts from different manuf. To allow us to "create category" and then create sub categories off main and other subcategories. These subcats could be ... 10 deep. As I said, some of these cats will have a number associated with them. However, on other manuf., items there is no easy to follow convention with their part numbers. We'll be manually uploading them so we'll just have to speicfy the category at that time. Each product can be ordered off the subcat listing, (a little add to cart button next to the listing with quantity box) or the page for the product. EVERY product has to end up at it's own page with a friendly and unique url for each item or cat or subcat. We have to be able to cut and past a url to send to customers via email to the part they need. Also search engines need to be able to index the entire product line, both cats and subcats and individual items. URLs must be search engine friendly. To develop a coupon system for discounts to preferred customers. Another function this cart system needs to do is be able to send a url via email to a customer that has a cart ID in it so that the cart will show for the customer. What happens is the customer can't sometimes find all the parts we have. So an employee will create the order. We then need to be able to send a URL to the customer via email so they can goto the site, see the cart, inspect the items in the cart, edit cart if need be, and then if all is good, they can enter their credit card and shipping info (or log into their account) and complete the transaction. IOW, that order will go from being an "unassigned cart," to one belonging to the customer. To at least provide a list of customer emails and customers addresses. (ie, part of the reports function) Speaking of reports, we at a minimum, we need a sales tax report (thus of course we need to be able to enter the taxing state or states and their rates). Please let me know if you are unfamiliar with this aspect. A sales tax report is very important. Should show total sales and total sales subject to tax and total before tax and total tax collected, based on any period entered. We also need a report showing total items sold by any period. Thus if I want to know what we sold in jan 01, 08 to march 10, 08 it'll show a total by part num, quantity, etc. Also we'll need total sales reports. which would of course show all sales and reflect any returns. Also we need to be able to pull up any invoice or customer and view their history. Search by customer name, address, zip, invoice no, etc. Also be able to generate a report of all customer that bought part number xxx-yyy. This is standard proceedure for backends here, so if you are unfamiliar, please ask questions now. There also needs to be pricing adjustment functions. At a min. there should be: Increase/Decrease all products base price by x%. Increase/Decrease all products in category XXX base price by x% Also have to be able to change the mutilpiers on the different quantity prices and of course the shipping schedules. (both the base rate and the $/# rate.) From time to time, we may also need to update the prices based on the price shown in a new excel spreadsheet from our vendor. This is about once a year, perhaps less. But we can't overwrite our description or other changes from this updated spreadsheet, only update the list price. Also, we need to get working in this project very soon. Time is going by too quick. We are trying VERY hard to have this written in Python or Perl and staying away from php. So if you are willing and able to do this in Python or Perl, please send a msg to us stating this. We will put all those bids with Python or Perl at the top of the list. We will only go with php if we can't find a python/perl person to do the project. * * *This broadcast message was sent to all bidders on Thursday Feb 7, 2008 6:58:00 PM: Hello, We would like to add a few things: If you are proposing to do this job in php, we will require a warranty on bug fixes and patches for your code to address any problems found with php in the future. We really prefer a non php solution to this problem. When you post your bid or comment, please let us know your plan achieve our goal. So far only one bidder has done this. While we have posted this project on many other websites, we only recently found rentacoder.com. After looking at all the other sites, I can say with 90% certainty, this is the site we will use to complete this project and future projects. Additional information: We would like (and in fact, need) to utilize the full space available. We still see many sites using only 60% of the width of the browser. Yes, I realize this is a bit challenging, but our site needs to use the max. amount of browser space available. Think more along the lines of an online order form, and not so much as a corporate vacation website. We need to have print (font size) that is not too small. Too many websites are too hard to read. Our clientele is a bit older than 20something and font size is important. We need to know your warranty period and policy for updates/security fixes. We would not even consider using PHP without a written policy on patches, updates, fixes, etc. for at least 3 years. We very much prefer a "simple" site. We do not like to use the fancy graphics, animation, flash and scripting so many people seem to favor. Every page needs to have a url that is friendly to SE and can easily be emailed to anyone w/o losing the page/data. Search results should also be consistent. ie, the url should contain the search terms so that anyone can email the results page to another person and get the same results. Some of our customers are reluctant to give out credit card info over the internet. So what we allow them to do is create their order, and then call or fax us their CC info. We need to be able to accomodate these customers. We also have customers that pay by check/money order. We need to be able for them to create their order, print out the order and then mail their payment. So now, please update your bid or put in your bids. :) * * *This broadcast message was sent to all bidders on Friday Feb 8, 2008 6:26:10 AM: Almost forgot! One other very important thing. We must be able to export a full database file (containing all items in the database) for uploading to the [login to view URL] site. (aka googles marketplace.) Currently when we do that it takes a lot time formatting it to work. All this could easily be done from your end with an "export to froogle" file option for the admin. If you are unfamiliar with Froogle, it's pretty straightforward. Just see [login to view URL] for more info. Also, we would very much like to pick someone by Feb 15th to start work. If we don't find someone by then, that we feel can do this job professionally and on time and on budget, we might extend a little longer. But not more than Feb 28. The goal is to pick someone by Feb 15th, give about 2 months to get it done and then be 100% fully tested and working by May 1. (The beginning of our busy season.) Waiting till feb 28 will be cutting it very close. :) Thank you! * * *This broadcast message was sent to all bidders on Monday Feb 11, 2008 8:03:32 AM: We have also been reading up on the Ruby programming language and would consider it as well. The main thing is the quality of the programmer to write clearly written code that can easily be followed and updated. We believe a good coder can write in perl, python or ruby and achieve this.