[imac]

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.

Dear mitbar,

We do not have a fixed deadline yet, I suppose it will be ready in summer/autumn 2011. Now we realy need your ideas and suggestions on how it all should work.

Did you get the main idea in the opening post of this topic? Can you answer this question please: "Do you find it correct that there will be a joint base of customer accounts for all storefronts?"

[imac]

As I can see, you are more intrested in "Implementation A".

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.

At the moment, we do not plan the ability to share products among different stores. This will be implemented in futher releases. But you will be able to clone products in the first Multi-Store.

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?

All stores will be physically located at one place, but it will be possible to use a different domain name for each storefront. Also, these stores will have one back-end. They cannot be located on different machines. All stores will use the same database.

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.

We plan to gather and show statistics separately for each store.

[Struck]

Hello Imac,

Do you find it correct that there will be a joint base of customer accounts for all storefronts?

I think it is very important that customers should be able to login to all stores using their same account details, so Yes.

[CartBooster]

Hi,

From my clients point of view this is what we'd like
-------
1) Main master CS-CART store on
(www.onedomain.com)
-------
2) CS-CART duplicate store (Option to have several of these)
(www.anotherdomain.co.uk)

- Select products / categories to be active from the main store for this store.
- The option to select a different currency for this store.
- Option to select individual skin / block layout options
- All customers / orders written to the main master data base system
- All inventory is take from the one master database
------
3) All branding for each store (website / email / invoices) must be separate to each other.
------
We'd basically have our store selling in foreign currency on a foreign domain, but taking the inventory from our main store, and with shipments from our main store.

This would also the option to niche certain products and categories via premium domains, and would be great for targeting SEO

Stephen

[Triplets]

At the moment, we do not plan the ability to share products among different stores. This will be implemented in futher releases. But you will be able to clone products in the first Multi-Store.

I do not understand the purpose of multi-store without the ability to have a common product database. I have clients that have 5 web sites all selling the same products (just laid out differently for different search engine keywords). If you cannot maintain a common product catalog, the multi-store is worthless. Let's get it done correct the first time. I am willing to wait.

[tbirnseth]

Imac,

First off, I'm not criticizing, I'm trying to help get you started in the right direction versus investing a lot of time and then not meeting the real need.

It sounds as if you are taking the approach that all the databases and stores are on one server. This won't work in the real world. Remember that the customers of this functionality are generally going to be your larger cs-cart customers. Hence they will probably host each domain on a separate server for performance and availability reasons.

If you're going to architect a solution, you should start from a "system independent" standpoint. That's why I suggested you implement an API so that the various stores can communicate with each other as well as having a "master source" where an API can be used to update the various stores. Just my two cents.

[JesseLeeStringer]

Imac,

First off, I'm not criticizing, I'm trying to help get you started in the right direction versus investing a lot of time and then not meeting the real need.

It sounds as if you are taking the approach that all the databases and stores are on one server. This won't work in the real world. Remember that the customers of this functionality are generally going to be your larger cs-cart customers. Hence they will probably host each domain on a separate server for performance and availability reasons.

If you're going to architect a solution, you should start from a "system independent" standpoint. That's why I suggested you implement an API so that the various stores can communicate with each other as well as having a "master source" where an API can be used to update the various stores. Just my two cents.

I am one of the 'larger ones'

[dustundag]

I think the main trick of the virtual server options required for the web server is the following . (This is almost not possible for Panels like Parallels® Plesk. But very easy for panels like virtualmin!)

Home Page A (all goods)
Document Root: "/home/allstore.com/public_html/cs-cart"
server name: allstore.com
Ip Address:xx.xx.xx

Home Page B (bstore goods)
Document Root: "/home/allstore.com/public_html/cs-cart"
server name: bstore.com
Ip Address:xx.xx.x1

Home Page C (cstore goods)
Document Root: "/home/allstore.com/public_html/cs-cart"
server name: cstore.com
Ip Address:xx.xx.x2

mysql on the same or on a seperate server, but single and shared

Each seperate domains should have seperate ip's if the goods are
similiar to avoid google issues
----------------------------------------------------------------------------

As I can see, you are more intrested in "Implementation A".


All stores will be physically located at one place, but it will be possible to use a different domain name for each storefront. Also, these stores will have one back-end. They cannot be located on different machines. All stores will use the same database.



We plan to gather and show statistics separately for each store.

As I can see, you are more intrested in "Implementation A".


All stores will be physically located at one place, but it will be possible to use a different domain name for each storefront. Also, these stores will have one back-end. They cannot be located on different machines. All stores will use the same database.

.

[imac]

Hello Imac,
I think it is very important that customers should be able to login to all stores using their same account details, so Yes.

Well, in this case, how should be handled the following situation?

A customer, who went shopping in your store A a few days before, comes to your store B and tries to sign up. And he certainly receives an error saying that his email is already registered in the database and offering him to sign in.

Such situation is likely to confuse the customer because it is his first time visiting this particular store, and he can hardly expect to be registered there. That is the possible problem.

[imac]

[quote name='djstevie84']Hi,

From my clients point of view this is what we'd like
-------
1) Main master CS-CART store on
(www.onedomain.com)
-------
2) CS-CART duplicate store (Option to have several of these)
(www.anotherdomain.co.uk)

- Select products / categories to be active from the main store for this store.
- The option to select a different currency for this store.
- Option to select individual skin / block layout options
- All customers / orders written to the main master data base system
- All inventory is take from the one master database
------
3) All branding for each store (website / email / invoices) must be separate to each other.
------
We'd basically have our store selling in foreign currency on a foreign domain, but taking the inventory from our main store, and with shipments from our main store.

This would also the option to niche certain products and categories via premium domains, and would be great for targeting SEO

Stephen[/QUOTE]
Ok, it's "Implementation A".
Actually, we plan all stores to be equal, without a master store. You'll be able to configure each store separately, but there will be an ability to set default settings for all store from one place.

[qoute]Select products / categories to be active from the main store for this store.[/quote]
Each store will have own categories and products.

[quote]The option to select a different currency for this store.[/quote]
Confirmed.

[quote]Option to select individual skin / block layout options[/quote]
Confirmed.

[quote]All customers / orders written to the main master data base system[/quote]
Yes, please comment on my post http://forum.cs-cart...35&postcount=29

[quote]All inventory is take from the one master database[/quote]

Ok, as I can see, many of you want to have common inventory for all products. i.e. products from different stores will have the same inventory. We'll take it into account.

[imac]

I do not understand the purpose of multi-store without the ability to have a common product database. I have clients that have 5 web sites all selling the same products (just laid out differently for different search engine keywords). If you cannot maintain a common product catalog, the multi-store is worthless. Let's get it done correct the first time. I am willing to wait.

There will be a common database. This is not being discussed here.

The issue is that we plan to track inventory separately for each store, i.e. each store will virtually have an independent inventory. This issues is still under discussion.

From our point of view, the main problem with having a common inventory is that it in not absolutely clear which product properties shoul vary from store to store and which should be the same. For example, it seems that product options should all be the same as they affect the inventory, but you won't be able to change option modifiers (price) then.

Any ideas?

[tbirnseth]

From our point of view, the main problem with having a common inventory is that it in not absolutely clear which product properties shoul vary from store to store and which should be the same. For example, it seems that product options should all be the same as they affect the inventory, but you won't be able to change option modifiers (price) then.
Any ideas?

What I do (and you may consider also) is a master inventory. Various fields in the inventory can be adjusted by an intermediate data set that applies add/modify capabilities for each field based on the store it is destined for. Hence you could have product a with options x, y and z for store 1 and options x and y only for store 2. For store 3, product a would not be part of its catalog. Additionally, product a could be in different categories on the different stores.

When store 1 sells 2 of product a, the master inventory is notified and when it is changed, it triggers and update of the available stock to all stores that are configured to use that product.

A customer, who went shopping in your store A a few days before, comes to your store B and tries to sign up. And he certainly receives an error saying that his email is already registered in the database and offering him to sign in.
Such situation is likely to confuse the customer because it is his first time visiting this particular store, and he can hardly expect to be registered there. That is the possible problem.

Solve it with a change of the notification. First, this assumes you are using email addresses for login and that you've restricted each user table to have email addresses be unique. So change the notification to something like:
The email address foo@example.com is registered in our sister store, would you like to login using that address?

The goal is single sign-in across linked stores. I don't really think anyone would be surprised if they entered their email/password into a sign-in box and it was accepted. Youl can easily check if they are already registered if they try to register, again notifying them that the email address is already registered in a sister store.

[mitbar]

Imac,

First off, I'm not criticizing, I'm trying to help get you started in the right direction versus investing a lot of time and then not meeting the real need.

It sounds as if you are taking the approach that all the databases and stores are on one server. This won't work in the real world. Remember that the customers of this functionality are generally going to be your larger cs-cart customers. Hence they will probably host each domain on a separate server for performance and availability reasons.

If you're going to architect a solution, you should start from a "system independent" standpoint. That's why I suggested you implement an API so that the various stores can communicate with each other as well as having a "master source" where an API can be used to update the various stores. Just my two cents.

Part of this is inaccurate, we have a dedicated server just for all our stores that have huge databases. Having the option to have all our items (over 1100 of them) in one backend and control multiple front ends would make our life much easier. We host all our stuff on one server but it is a large server .

[mitbar]

Well, in this case, how should be handled the following situation?

A customer, who went shopping in your store A a few days before, comes to your store B and tries to sign up. And he certainly receives an error saying that his email is already registered in the database and offering him to sign in.

Such situation is likely to confuse the customer because it is his first time visiting this particular store, and he can hardly expect to be registered there. That is the possible problem.

i would like them to have to sign up for each store, thus giving the illusion that the stores are not owned by the same person and are seperate.

[mitbar]

There will be a common database. This is not being discussed here.

The issue is that we plan to track inventory separately for each store, i.e. each store will virtually have an independent inventory. This issues is still under discussion.

From our point of view, the main problem with having a common inventory is that it in not absolutely clear which product properties shoul vary from store to store and which should be the same. For example, it seems that product options should all be the same as they affect the inventory, but you won't be able to change option modifiers (price) then.

Any ideas?

For my stores the products would be identical so that works for me. However is it possible to tell the backend which store we would like said item to show up in?

[imac]

For my stores the products would be identical so that works for me. However is it possible to tell the backend which store we would like said item to show up in?

Sure, you'll be able to specify in which stores the product should appear.

[JesseLeeStringer]

Hi Ilya,

Having considered your proposals, I would like to provide what "I" need.

A single administration area to control all products, categories, shipping methods, taxes, users.

Multiple domains/storefronts in order to accept payments. Checkouts will all be identical to settings provided in the backend. Promotions will be able to be developed per domain.

Having reviewed your proposition for multiple backends per domain, I can see the need for this, however where possible it would be easier for employees to place orders from a single administrative backend. Otherwise I presume they will need to have 5 website backends opened at all time in order to process an order.

An excellent example for our business is a large increase in manufacturered items which we can sell wholesale, this deserves it's own website however it doubles our overhead for labour having to recreate storewide specials, contact forms etc.

It would be much easier to see a 'contact form' with 'enable for DomainA' 'enable for DomainB' as opposed to creating the form multiple times.

Let me know your thoughts

J.

[gasngrills]

i would like them to have to sign up for each store, thus giving the illusion that the stores are not owned by the same person and are seperate.

I agree, why confuse the customer. If a customer had bad experience with store A and visits store B and finds out it is owned by the same company he/she would leave without buying .

Imac,

Would we be able to use same payment method for each store with different credentials , for example if I have two merchant accounts with authorize.net for two different stores with different products that have also different deposit bank accounts, are we able to set 2 instances of this payment method for each store?

[nathand]

i would like them to have to sign up for each store, thus giving the illusion that the stores are not owned by the same person and are seperate.

I agree..


I want my customers thinking they are shopping the competition when infact they are still on one of my sites..

After all, Im my best competition

[imac]

I agree, why confuse the customer. If a customer had bad experience with store A and visits store B and finds out it is owned by the same company he/she would leave without buying .

Imac,

Would we be able to use same payment method for each store with different credentials , for example if I have two merchant accounts with authorize.net for two different stores with different products that have also different deposit bank accounts, are we able to set 2 instances of this payment method for each store?

Yes, you will be able to set different payments, shippings for each store.