I am CFO of a dropship company. We need a relational database created or adapted to our business model, which I will now explain briefly...
We sell inventory we have in stock through major online etailers, ebay, and we intend to have our own shopping cart someday.
We are constantly requesting manufacturers, but primarily wholesalers, to submit new product offerings (we call them sku's) for our consideration. We constantly get lists of product items that a company wants us to either buy, sell on consignment, or flip to an online seller for a slight mark-up.
Once we receive a product submissions, we have to shop the price. We have to see if it is really being offered low enough so we have a decent profit margin, etc. If it is a good price and is an item we want to carry, then we have to upload the product, with some of the fields of information, to our retail seller where it goes live for sale to the public.
We would like to streamline this process using a database. Here is what we envision:
A wholesaler or manufacturer logs into a database using their username and password. New wholesalers should be able to easily set up an account. Once logged in, they can upload the products. We will define the fields they need to fill in. They should have the ability to import their data at least as a CSV (comma separated value) file, and maybe our database could accept other forms. They should also be able to manually upload each offering, with out a bulk upload.
After we receive the uploads, we need to be able to review all of the inputs, sort it by date, or by any other field (sku, manufacturer, product model, name of manufacturer, name of wholesaler, etc.).
We then research the product to see if it is viable to sell. This usually includes copying and pasting the brand name and model number and searching the web for matches to see what street price is. We are open to new ideas as to how the database can streamline the current copy and paste method...
Once we have reviewed the project, we want to track if we accept or reject the offer. If we accept it, we then need to track the way in which the product is to be carried (bought and stored, dropshipped by manufacturer/wholesaler, consigned, etc.)
We then want to avoid having to manually input our selections into our retailer's databases. This means the database has to be able to export a CSV file for the fields we want it to export that match up for input into our retailer's software program.
The number of fields per item we would need to create would probably be well under 50.
Currently, our serve accepts MySQL databases, but we can migrate to another ISP if necessary.
Currently we are shipping out 100 orders a day. We expect that number to grow 10 times to 1,000 in the next year.
I know how to use Filemaker Pro, so I am familiar the what relational databases can and cannot do, and I can give clear explanations of what we want this database to do.
There are many off-the-self databases that will manage orders, inventory, labels and shipments. We are looking at [url removed, login to view] for this one. It would be nice if these databases could work together, but that is for another time! Right now we just need an easy way to manage product buys that, once accepted, we can turn around and submit to the Etailers.
We also want our suppliers to be able to go in and update the information submitted as they acquire more information.
16 freelancers are bidding on average $1113 for this job
Hi We are group of programmers from India willing to submit our proposal based on your requirements. We would also like to discuss few technical specifications based on specification set given in PM.