Multi-store roadmap. Let's discuss (UPDATE: done)

hi , i read it before and i ask about multivendors , in nop 3.0 will not be multivendor support?
if each multivendor will add own products to our web site and they will manage own orders  how will be payment and management systems for order ? how multivendors will take payment ? from administrator or from customers ? if customer will have only 1 invoice end of the checkout and make payment online in 1 time ?

every multivendor will see own ordered products and they will see customer details , they will send to customer with cargo ? if customer buy 10 product from 10 different multivendor customer will receive 10 invoice ? or all multivendors will get payment from web site owner and send products to web site owner and owner will send to customer ?

CodeMaster wrote:
I think what you are talking about is a site like Ebay (without the auction features) which is very complex multi-cart solution. Ebay just gets seller an buyer together and they and the orders, payments, shippng, billings, etc. are processed directly between them. PayPal was created by a third party (and later purchased by Ebay) to support, with much success such payments.

If you want a multi-vendor and  uni-cart/payment store, the solution developed by Hezys is near what you want.

No you didnt understand me i just try to understand if nop 3.0 will have multistore and multivendor support how will be payment management and order management ?

i understand that only one owner will have seperate stores in 1 site and each store can have own multivendors to add products but if customer make order from different stores customer will have only one invoice end of the checkout and pay it to bank or any online payment system , customer will pay for 1 incoice number totaly sum.

but in the backoffice admin side how we will understand from which store which product ordered customer ? and if customer make payment online to store owner account , how we will see howmuch need to pay for which vendor products to vendors (product owner)
?

Please can you explain me , how multi store and multi vendor system will work in new nop 3.0 ? i still didnt understand how system will work in the new version with multistore and multivendor ?

  I ask about it because i already have another web site too developped under PHP+Mysql and i use it over 1 year and it is also multistore and multivendor , my suppliers use multivendor account to enter admin and they add new products,delete,edit,update stock and price and when customer make order and make payment , i see from the admin which product ordered from which supplier and they also get email automaticly what i need from them , i pay them money seperately to each supplier and they send me products and i send to my customer

nop 3.0 will not work like this ?

CodeMaster wrote:
It hasn't been defined yet.

I agree that we should capitalize from other carts experience which have been tested and improved over time. Besides Magento I find OpenCart (login credentials: demo, demo) also valuable because it seems to be simple and powerful, probably more alike of what Nop requires.

The Multi-store/vendor concept
Just for establishing a working framework here are some some kinds of multi-store/vendors which I had described in another post (and now with some more details):

Multi-vendor (drop-shipping): several vendors selling under one store (as this in Nop)which has only one common: domain, skin, product catalog, customer db, payment and shipping methods, reward points, discounts, etc. There are several administrations, one general which sees and controls everything and one for each vendor from which he updates his products and sees and controls the portion of the orders referring to his products. This is, in real life similar to some department stores which provide (or "rent") places to vendors to display their products but customer pay at store's checkout. The vendors do not have control over the customers base nor the discount. promotion and reward strategies, etc.  Amazon could be a case of multi-vendor.

Multi-Store: Several stores sharing one or several parts of the cart system. Here we can have different combinations and cases. Examples:
- Like a pizza (or groceries, supermarket, etc.) chain with a general catalog,  but not all product and prices are alike in all branches: One domain (each store might have its sub-domain); one skin; one central customer db; common payment and shipping methods, and discount and rewards settings; etc. Individual stores have their administration to check/control their orders and to select their products and pricing from general catalog. Ina a multi-national/regional case is common that products can from store to store different pricing and costing, taxing, currencies, stock/warehoses, etc.

- Like a mall: several stores under one roof. One general domain and other common infrastructure (i.e. delivery, credit card processing, rewards, etc). Each store has its domain (redirected to its sub-domain in the general domain) skin (sometimes from a set of templates provided by the mall), catalog, customers, discounts, individual payment and shipping methods.  The Mall might have a general catalog, encompassing all individual catalogs, for the purposes of aiding the customers to do searches and then refer them to the individual store. It may also provide customer service, call/chat center and a guaranties to customers. Ebay can be in a combination of this and previous case.

- Like a shopping district where all stores are independent (domain, skin, customers, catalog, payment/shipping, discounts/rewards, etc.) but they all share a common cart system (most db's are individualized), so that the hosting and any enhancements are shared by all stores.

- A multi-Vendor could be considered a particular case of a multi-store.

Summarizing a multi-store can go from some stores  selling some products from a  general catalog and sharing some common infrastructure to a single installation with different and independent stores.


My 2 cents
I find that Adndrei's initial proposal is an excellent start and here are some comments on what he and others have proposed:

1. Mapping. The  ACL type of mappings sounds good. Consider mapping product variants which can be used to differentiate pricing, currency, costs, taxing, warehouses, stock management, etc. Topics should be mapped  too. Store managers should have restricted access to the entities allowed to their stores.

2. Cart and order history sharing. I think at least for the first releases there should not be cart sharing. Each store should have its own cart and order history. For a multi-vendor (drop shipping, as the project developed by Hezyz, alike Amazon) there would be a single store where orders and catalog administration is split among all the vendors.

3. Settings. OpenCart Settings and other configurations under System have interesting ideas for Nop.

4. Plugins. Some plugins such as all related to discounts should be shared by all stores whereas there are some others (i.e. shipping and payment) which will require multiple installations.

8. Localized message templates and strings Maybe they can be handled as different versions of the same language. In that fashion each language (which will be a default) might have different "versions".

What about the payment and delivery system ? for example if multivendors are owner of product and if customer will have only 1 checkout payment end of the order , how to manage this delivery and payment to vendors (product owners)

CodeMaster wrote:
Follow the Amazon model: they charge the customer and pay vendors and the vendors deliver the products.

i understand it well from amazon ,

1) the problem is where product cargo post will go ? all vendors will send to mainly store owner and owner will send to customer ? or vendors  will send to customer directly ?if customer choice product from 10 different vendors 10 product , customer will have 10 post cargo ?

2) if all vendors will send to owner then need to have in admin area , big management about the vendors payments too and control all orders and cargo posts and all , big work for nop team , waiting new version with big patient .

Advice needed...

Good news. I've finished the most of the work for multi-store support. Mapping, host detection, etc. Almost everything is already done and works fine.

The only complex thing still not implemented is per-store settings. Currently we have ISettings interface and setting classes inherited from it (e.g. StoreInformationSettings). Developers who worked with nopCommerce before should know how it is implemented. These setting classes are injected into services (etc). Now some settings will be always global, some settings could be configured per store. But how should it be implemented now? I really cannot find a good approach for. I want to keep it simply (IoC/DI, etc). Maybe, extend ISetting interface with some extension methods such as GetForStore(x = x.PropertyName, int storeId) - implementation similar to GetLocalized extension method of ILocalizedEntity

Does anybody have any suggestion regarding the implementation of global and per-store settings without much core changes?