Forum Moderators: buckworks
Web Site for Travelling widgets
You fill in all your customer demographics, name, address, email etc.
You can upload unlimited number photos of the widget
You select from 1 to 150 cities you would like your widget ad to appear in, with same or seperate contact info for each city.
You select different categories for your widget ad to appear in each city, ex. blue widgets, small widgets, square widgets etc.
You can select to upload a video of your widget.
You can select to pay for the widget ad monthly, quarterly, semiannually, or annually.
As you add more services, pictures, cities, categories the price is updated so the customer can see how much their widget ad is going to cost.
Is this something osCommerce is capable of or is their a better package for this type of setup? Any guidance is greatly appreciated.
...but it sounds like no matter what you do, it will be a custom solution. You are going to end up doing quite a bit of extra scripting to make it work.
You might also consider building a shopping cart from scratch and make it exactly the way you want it.
It's all possible. I would start by getting a really good plan describing exactly what you need. You might even layout some pages the way you want it to look. As a developer, it makes it so much easier when the plan is very clear from the start.
that you may want to demo, but I'm not certain if it will work in your situation. I've only used x-cart for basic processing with some basic custom programming.
If you're going to use an existing shopping cart setup I highly recommend that you keep the "customizations" as independent from the original shopping cart source code as possible. The reasoning is, when your shopping cart software undergoes upgrades and security fixes, you will probably be "locked" into the version that the custom job is based on. My shopping cart has been customized from its existing source code, which makes it very hard to upgrade to the next version.
If you're going to have a developer work with osCommerce try to make it modular. Better yet, why not have a developer code an independent "configurator" script that will "pass" the billing values to osCommerce. Similar to how you can sell a product through paypal by passing the product info through the hidden fields values. The truth is, osCommerce may only need to hold the pricing info. What configuration constitutes that price shouldn't really matter.
One of the other complicated aspects is the synchronization of user accounts. I had to have an independent affiliate script become synchronized with my shopping cart user base, but I did not want the affiliate script customized in any way. I wanted the freedom to upgrade it without breaking anything. What I had my developer do was execute the affiliate account creation script via CURL whenever a shopping cart account was created. Whenever a user updates his shopping cart profile (email, street address, phone #) it would locate the matching record in the affiliate database and overwrite the affiliate database record with the shopping cart record. This keeps both in sync, while forcing the user to update his shopping cart profile in order to update his affiliate profile. It's not the cleanest approach, but at least both can remain relatively independent.
I'd suggest this:
Install a clean osCommerce and study the database structure via phpMyAdmin. Look at what tables are populated and how they're populated. Add a customer and see what tables are updated (records inserted, removed). Add a product, and review the database changes. Purchase a product, and review the database changes.
Once you understand what actions osCommerce performs during these situations, it's possible your developer can write a custom script which will "insert" values into osCommerce's database, independent of osCommerce's interaction. Be very careful to take into account the "auto_increment" field of any database tables. I thought I once saw a "configurator" script on Hotscripts.com. I'm not sure if it was javascript based though.
When you're dealing with these type of "custom" package setups be sure you take into account how you're going to deal with customer upgrades/downgrades. Will you have to prorate upgrade charges, and refund/credit downgrade charges. You may want to have a setup where upgrades are possible, but downgrades are not allowed. Whatever you code, you should consider if it's necessary for you, the admin, to have the ability to selectively add/remove items/configurations on a per user account. Basically, will you be able to enter overriding values for individual users without the billing environment choking or worse, overwriting your custom values on it's next billing initiation. My current setup isn't as flexible; if I want to upgrade a customer's account I have to sign him up under an entirely different package.
The real complexity of my setup is that customer "packages" are activated/deactivated based on their billing status. For instance, if Charles purchases package 301 and his monthly billing charge is "declined" then his package is "deactivated." If his last successful billing date is 60 days or greater, a "sweeper" script executes which will delete his packages from the site (database, hard disk, portfolio files, etc).
Occasionally, a customer will log into his account to "update" his credit card data. Whenever the user updates his CC data (new #, or change of expiration date) his database billing record has a field called "new_cc" which will change from a value of N or null, to Y, which stands for Yes. There is an hourly script called "disabled-billing.cgi" which queries all billing records with a "new_cc" value of Y. It then attempts to charge any "disabled" packages that account is related to. Regardless of the success or failure of the charge, the "Y" value is immediately cleared. If it is successful, his "disabled" package will be automatically reactivated.
I know you didn't ask for this much info, but I think you may encounter such scenarios and it may be helpful to have some billing scenarios to compare and contrast against.
Good luck.
