Shop for multiple clients

[RFH Reseller: petemasson]

I've got a client who needs a shop set up for their clients. The trouble is that each client has different items available to them, and each client has different scales of pricing for a single or bulk items. Each client mustn't be able to see another client's items available. Effectively, I guess it's like a seperate shop for each client?

I can think of many different ways of doing this, but I wondered if anyone has any experience of doing similar, or just had some good ideas?

Cheers,

Pete

[Tanzy]

Don't know if this well do you, but I believe that DNN 4.8 ships with a shopping module. Don't know if it is any goo mind you. However, you can have multiple portals within DNN.

Other than that idea I'm afraid that I can't suggest anything.

[RFH Reseller: askjim]

We have built a platform at work where each shop is a seperate installation. We used to use a platform where each shop was part of one installation.

Im slightly divided on the best approach. If there is one installation it can be quicker to patch but patching all installations in one go could be a disaster. The other useful bit is that you could add functionality to allow data to propogate between shops or share data easier.

From a customer prospective seperate installation sounds better from a data perspective.

[RFH Reseller: SKILLIT]

I've got a client who needs a shop set up for their clients. The trouble is that each client has different items available to them, and each client has different scales of pricing for a single or bulk items. Each client mustn't be able to see another client's items available. Effectively, I guess it's like a seperate shop for each client?

I would start by finding out out how the items available to a client and their price are determined - to see if there is any logic behind it at all.
Are the products part of a group of products?
Is the customer classified in any way?
Are the scales part of a standard set?
How many scales can a customer have, do these vary by product?
etc.

I would anticipate at least some aspect is common.

David.

[RFH Reseller: petemasson]

Thanks for the comments so far...

I think the biggest issue with this is that the prices are all very bespoke (negotiated on a per client basis apparently), as are the items available to each client (as many items are branded specifically for that client). Which is why, at the moment, I'm thinking of going down the multiple shop route. I've checked, and CubeCart can be used unlimited times on one domain. The template system is good too, so it shouldn't be too difficult to brand each shop per client, and amend the templates site-wide should the need arise in future.

Cheers,

Pete

[RFH Reseller: nick]

http://www.magentocommerce.com/ may be an option for you, though I've never tested it fully on redfox. It has been written to allow deep customisation, like this, to be done cleanly,meaning you hopefully wouldn't break upgrades etc..

I've had a fair bit of experience making CubeCart do things it wasn't designed to, and it always involves a horrible amount of hacking and ugly patches, and then an ongoing nightmare every-time revisions come out.

Magento is still in beta, which may put you off, but from what I can tell it looks stable enough…

[RFH Reseller: Sol]

I'd actually think that to display the products and pricing would be quite easy since you could take almost any database shopping cart system and modify it to link products and price to a user / client table.

The hard part is modifying the admin end so that someone can assign products to a user / client and set the per user pricing. I say hard, but that is more from a layout / workflow point of view since the DB work is relatively simple.

Of course, if the products have attributes and prices vary by those then you can run into a very complex scenario, definately one to avoid if possible. To be honest I haven't seen anything that will handle per client pricing on products that vary by attribute (heck, I haven't seen a good clothing stock control system in that it allows tracking by style, colour and size).

[RFH Reseller: askjim]

You should see the platform we have built at work. Our system works by defining price lists. One price list is defined as default and each client uses the default price list or less they are assigned a different one. A price list describes the price of every individual SKU and provides quantity based pricing. A price list can be derrived from another price list if you want a crude conversion rate mechanism. Prices can either be specified inc or ex of TAX. This combined with awesome discounts functionality means we can handle any stupid pricing mechanism a customer has, and where we can not handle with price lists we extend our system via an api. We have recently added a female high street fashion retailer which can handle various sizes / colours and it would be possible for each combo to have different prices although it would be unfair to the customer to make a small pair of jeans cheaper than a larger pair.

Of course, if the products have attributes and prices vary by those then you can run into a very complex scenario, definately one to avoid if possible. To be honest I haven't seen anything that will handle per client pricing on products that vary by attribute (heck, I haven't seen a good clothing stock control system in that it allows tracking by style, colour and size).

[cjs]

What you're after is effectively a "multi-tennant" application. One codebase, multiple clients?

Examples: any 37signals product, myspace, google apps etc.

There will be nothing off the shelf to do that!

I've developed a custom e-commerce system and financial data aggregator around the principles but there are many problems to solve!

Google is your friend - microsoft have written some good white papers on it!