Multi-Store

Dear friends,



The idea of a web store with multiple storefronts has been ranked first in the CS-Cart Idea Tracker for several months now (see one back-end, multiple Store-fronts).

Finally, we’re getting down to its implementation. At this stage, we need to summarize all your requirements and suggestions to prepare a detailed specification for the project.



[size=3]Definitions:[/size]

Root administrator means the store owner with full range of administrative privileges.

Storefront means a separate web store with a separate URL, which is managed by a store administrator or a vendor.

Company means the storefront owner who can be either the root administrator (or some other store staff with special privileges) or a product vendor.





[size=3]Implementations:[/size]

We reviewed your messages in CS-Cart Forums and CS-Cart Uservoice and invented two possible ways of implementing this concept:

[size=3][color=“darkblue”]Implementation A.[/color][/size] Multiple storefronts are managed by the store owner through a single back-end (see the attached image, only in black);



[size=3][color=“darkblue”]Implementation B.[/color][/size] Multiple storefronts are managed by multiple store vendors, each having a separate back-end to manage their product that appear on a separate storefront. At that, all storefronts and vendor back-ends utilize the common database (see the attached image, both in black and blue).



[color=“darkgreen”]Note[/color]: In fact, the second option would be an extended implementation of the first one. And most likely these two implementations will be released as two different editions in future.



However, we will discuss both branches in this forum thread because their functionality would be very much alike.





[size=3]Key features:[/size]

[b]- All storefronts will share a joint base of customer accounts. Customers will be able to log in to different storefronts once they’ve registered in at least one storefront, and in a situation when a registered customer will try to sign up for an account in a different storefront, he will get a notification that such account already exists and he needs to sign in.

  • Each storefront will use independent checkout procedures. We do not plan to offer a joint checkout for multiple storefronts.
  • Each storefront will have an independent set of tools and options to control its look-n-feel.
  • Each storefront will be able to utilize storefront-specific shipping methods (created and configured by the company managing the storefront) as well as common shipping methods (created anf configured by the root administrator).
  • Taxes, languages and currencies will be managed by the store administrator and will be the same for all storefronts.[/b]





    [size=3]Functionality:[/size]

    Below I’ll describe how we’re going to restrain/grant access to different functionalities depending on a user’s role:



    [color=black]Black[/color] - objects can be managed only by the root administrator and are shared by all companies/storefronts.

    [color=green]Green[/color] - object can be managed both by the root administrator and individual companies. E.g., there can be storefront-specific shipping methods (managed by the company)as well as common shipping methods (managed by the root administrator) that can be utilized by all storefronts.

    [color=blue]Blue[/color] - object can be managed by individual companies and thus can vary from storefront to storefront.



    Catalog
  • [color=blue]Categories[/color]
  • [color=blue]Products[/color]
  • [color=blue]Product features[/color]
  • [color=blue]Product filters[/color]
  • [color=blue]Global options[/color]
  • [color=blue]Promotions[/color]



    Shipping/taxes
  • [color=black]Taxes[/color]
  • [color=black]States, Countries[/color] - Each company will be able to enable/disable these items, but not to add, remove or edit them.
  • [color=green]Shipping methods[/color]
  • [color=green]Locations[/color]



    Administration:
  • [color=black]Database[/color]
  • [color=black]Credit cards[/color]
  • [color=black]Titles[/color]
  • [color=black]Currencies[/color] - Each company will be able to enable/disable

    these items, but not to add, remove or edit them.
  • [color=black]Logs, Upgrade center[/color]
  • [color=black]Store access[/color]
  • [color=black]Addons[/color] - Companies will be able to manage some addon-specifc settings, but not to install or uninstall add-ons.
  • [color=green]Payment methods[/color]
  • [color=green]Import/Export[/color] - Each vendor will be able to import/export own products, orders and customer account.
  • [color=green]Statistics[/color]
  • [color=blue]Settings[/color] -Companies will manage all settings that affect the storefront look-n-feel: Appearance > Customer settings, Appearance > Products list layouts settings, General > Catalog, Thumbnails, etc.



    Design:
  • [color=blue]Logos[/color]
  • [color=blue]Blocks[/color]
  • [color=blue]Quick links, Top menu & Site map[/color]
  • [color=blue]template editor[/color]
  • [color=blue]Skin selector[/color]



    Content:
  • [color=black]Languages[/color]
  • [color=green]Language variables[/color] - Companies will be able to override the default language variables only for their storefront.
  • [color=blue]Pages, forms polls etc separate for each store.[/color]
  • [color=blue]Tags[/color]
  • [color=blue]Site news[/color]
  • [color=blue]Banners[/color]
  • [color=blue]Newsletters, Mailing lists, Subscribers[/color]





    In your replies, please specify which of the two implementations ([color=darkblue]A[/color] or [color=darkblue]B[/color]) you refer to and which would meet you business requirements best.





    You opinion is really important for us to decide upon our development strategy since many functionalities can be implemented in different ways and we’re looking for a solution that will suit most of you. To start with, please answer the following questions:
  • Does this general description complies with your understanding of how a multi-storefront web store should work?
  • Do you find it correct that there will be a joint base of customer accounts for all storefronts?



    We are eager to hear your comments and suggestions!

    implementations.png

[quote name=‘imac’]

Implementations:



Implementation A. Multiple storefronts are managed by the store owner through a single back-end (see the attached image, only in black);



Implementation B. Multiple storefronts are managed by multiple store vendors, each having a separate back-end to manage their product that appear on a separate storefront. At that, all storefronts and vendor back-ends utilize the common database (see the attached image, both in black and blue).

[/QUOTE]



it would be excellent if both options are made available as either of these could be more suitable to a company.

Yes, we plan to implement both of them.

But as was earlier mentioned, there might be two separate editions.

Hi Imac,



This is great.



Q. How do envisage an SSL Certificate to work? A separate IP would be required for each shop, and therefore a separate SSL? How does this tie in with one backend?



Most interesting. I’m certainly interested.



Cheers,

Greg

This is great! I think you are heading in the right direction. I see this being used by companies who a partner or another business entity that wants to sell some or all of your product under a different brand.



I can tell you that I will use this because I have two different companies that have some overlap. I have tried to manage two different instances of inventory and it is impossible.



This product will allow me to sell from two different websites, feature products differently on each site, yet keep my inventory managed.



I am looking forward to this very much and I would love to help beta test.



imac, in reviewing your message, I think you are heading in the right direction. Looks good so far.



Thanks again CS-Cart.



Adam

is there any plans for multiple site xml sitemap for google etc.

what is the expected google results with single

or multiple ip adresses for multi sites?

Thanks

[QUOTE]- Taxes, languages and currencies will be managed by the store administrator and will be the same for all storefronts.[/QUOTE]



I think that it will be better to have different configuration and options for each storefront. What about if someone wants to have low taxed for the “A” store and high tax for store “B”.



Also it will be best to do it like Magento. Having a global store and different store views. All the settings can be overwrite by each storefront. And the Administrator Switch between store configurations by a dropdown like the language feature works.

[quote name=‘ANDiTKO’]I think that it will be better to have different configuration and options for each storefront. What about if someone wants to have low taxed for the “A” store and high tax for store “B”.



Also it will be best to do it like Magento. Having a global store and different store views. All the settings can be overwrite by each storefront. And the Administrator Switch between store configurations by a dropdown like the language feature works.[/QUOTE]



As I understood you mean Implementation B

If you need some additional Tax, root administrator must add it. And company just enables it or not for the own products.

Main problem with ability for companies to add taxes could be incompatibility with shared products, i.e. if I want to display the same product at the different storefronts. But store A have Tax X, whereas store B does not have such tax. Thats the main reason.

I would strong suggest that you take this opportunity to separate back end business managemement from store management by creating a complely separate application. This new application should communicate with the storefront via a published API.



This will give you the greatest flexibility in meeting the needs of members who may want to utilize separate management practices for their store operations versus their business (like inventory).



In addition, a webservice needs to be defined that will keep inventory in sych between stores if that’s what’s desired.



If you try to shoe-horn this into the existing cart architecture you will create an unmaintainable beast.



You would end up with two products:

  1. a storefront
  2. a back-end management system that could “drive” the storefront(s) and centralize common business practices as they relate to storefronts.



    I’ve been integrated with cs-cart from a back-end order management system for over 2 years now. I can manage multiple store inventories (sharing where desired and not sharing where not) and basically do nightly catalog updates to all stores a customer is configured to use.



    I wouldn’t dream of trying to do this within the existing cart. The rules/methods for managing things are simply different between the front and back ends.



    Have fun.

Also, you cannot assume that all of the stores will be on the same system and have access to common databases… Hence the biggest need for a strong API.

Multi-Store should be simple. Stores sharing the same inventory and drop ship program in real time. That’s it. No more. Who could buy this Multi-Store? Distributors and manufacturers looking to boost new retailers.



The clone stores should not have option to delete products or add products. The only Options for the clon store should be manual filling categories-products and single price discount, due to market location.



The retailer buy a domain, and the distributor license their store to him. That’s it, no more.

Zeke… Please remember that the real goal should be less about setup and configuration and more about ongoing maintenance and variations among the “served stores”. Leave the store admin in the storefront (payments, shipping, etc.) and focus on distribution of catalogs (inventory, options, features, etc.) with the ability to have them global or specific to 1 or more stores.



Agree with colortone about keeping it simple. You’re trying to overcome a limitation, not invent something new.

There is trade-printer company in the USA, that offers a “Branded Website” program with a “hand-on” or “hand-off” settings.



in “Hand-off” the reseller register a domain and set the DNS to the trade-printer root server. Also selects a template, provide a logo header and pay an annual fee which includes the SSL certificate. All the prices, orders, taxes, payments and drop ship are done in the root server. At the end of the process the markup is sent to the reseller bank account.



In the “Hand-on” options, the reseller also summit the DNS, pay the fees, select a template and header. But is free to edit some prices and promotions.



In this case, Branded Websites do not require keeping an inventory on real time. The main purpose is sending printing orders from a pool of options.

[quote name=‘tbirnseth’]Zeke… Please remember that the real goal should be less about setup and configuration and more about ongoing maintenance and variations among the “served stores”. Leave the store admin in the storefront (payments, shipping, etc.) and focus on distribution of catalogs (inventory, options, features, etc.) with the ability to have them global or specific to 1 or more stores.



Agree with colortone about keeping it simple. You’re trying to overcome a limitation, not invent something new.[/QUOTE]



Dear tbirnseth,

We are open for the conversation please suggest your ideas.

[quote name=‘colortone’]Multi-Store should be simple. Stores sharing the same inventory and drop ship program in real time. That’s it. No more. Who could buy this Multi-Store? Distributors and manufacturers looking to boost new retailers.



The clone stores should not have option to delete products or add products. The only Options for the clon store should be manual filling categories-products and single price discount, due to market location.



The retailer buy a domain, and the distributor license their store to him. That’s it, no more.[/QUOTE]



Dear colortone, could you please explain what do you need cloned stores for.

One of the main ideas of the Multi-store is the ability to manage different stores from one place.

Zeke - Here’s what I do to manage multiple stores from my EZ Order Manager back-end.



I give customers the ability to manage a “catalog”. The catalog is driven from their inventory. They can have settings within the catalog to adjust pricing, change categories and set other inventory options on a store by store basis.



This is all ground up and put into a csv that is sent to each storefront via the standard import mechanism (but without user interaction).



There are problems you need to address before you do this, mostly releated to options and product features. Right now, you only have a Name atrtibute for an option. You really need a name and title. The title is what’s displayed (such as Color) and the name should be unique. Right now, the product import requires you to specify a DB key to update an option (but really it dupicates it if it’s not specified). Same goes for features. You need to either do a look up and see if the option/feature already exists for the product and update it or to insert it if it doesn’t.



So I would suggest you develop a programtic API for distributing products and product information. All the look and feel stuff can be done from the admin of the store. What’s really needed is the ability to do things like adjust prices for everyhing by 10% today and then change it back easily tomorrow.



So I think the primary request is to have a centralized inventory that can be used as a basis for multiple store-fronts. Each storefront should be able to be configured differently for different markets (eg. separate pricing, etc.).



That’s how I’d approach it. Start with the basics and then move into the details if needed. I would do this as a completely separate application that is geared toward inventory management. Of course, you can dive into order management too but I’d wait on that.

You can review EZ Order manager at http://www.ez-om.com if you like.

[quote name=‘tbirnseth’]Zeke - Here’s what I do to manage multiple stores from my EZ Order Manager back-end.



I give customers the ability to manage a “catalog”. The catalog is driven from their inventory. They can have settings within the catalog to adjust pricing, change categories and set other inventory options on a store by store basis.



This is all ground up and put into a csv that is sent to each storefront via the standard import mechanism (but without user interaction).



There are problems you need to address before you do this, mostly releated to options and product features. Right now, you only have a Name atrtibute for an option. You really need a name and title. The title is what’s displayed (such as Color) and the name should be unique. Right now, the product import requires you to specify a DB key to update an option (but really it dupicates it if it’s not specified). Same goes for features. You need to either do a look up and see if the option/feature already exists for the product and update it or to insert it if it doesn’t.



So I would suggest you develop a programtic API for distributing products and product information. All the look and feel stuff can be done from the admin of the store. What’s really needed is the ability to do things like adjust prices for everyhing by 10% today and then change it back easily tomorrow.



So I think the primary request is to have a centralized inventory that can be used as a basis for multiple store-fronts. Each storefront should be able to be configured differently for different markets (eg. separate pricing, etc.).



That’s how I’d approach it. Start with the basics and then move into the details if needed. I would do this as a completely separate application that is geared toward inventory management. Of course, you can dive into order management too but I’d wait on that.[/QUOTE]



Dear tbirnseth,



From my message you can see that my nickname is imac.



Actually, the functionality that you described refers to CS-Cart Professional (and sure, to both Multi-Vendor & Multi-Store). And here I want you to comment upon the features and functionalities of the future Multi-Store edition. How should it work that is the main question.

No, actually my comments apply to multi-company.



Tell me how your solution relates to having 3 stores (x.com, y.com, z.com). I want x/y to have the same catalog but differ in pricing. I want z to have a subset of the inventory in different categories and to have some products be the same price and others be different.



How do I manage this from one inventory source where x, y, and z may be on different machines and may NOT have direct access between databases?



I also want sales reports, statistics and other info for the individual sites as well as the ability to “roll up” information across them all.

how long until this multi store will be ready? I have two carts right now i would like to use this for and right now only magento does this so i really dont want to switch and all that jazz again.