Multi vendor implementation ideas

[boboci9]

Hi Aaron,

According to our last conversation I came up with several options on how to implement the multi-vendor implementation and I thought I will ask your opinion on the matter. In our case the user will be able to buy products from different shops in the same order. For this we will need to extend the orders schema because we will need different shipping options (each vendor can set different shipping options for their product).

Same user can be a customer of different shops but it will result in different customers (I attached the userId parameter to the Customers collection to establish this connection)
At checkout -> If there is no customer with this user and Shop1 create new customer otherwise use existing (same for Shop 2).

Regarding the shipping I think the best solution for vendor specific shipping would be to add the shipping in the items, but this would conflict the reaction core schema?

Do you have any suggestions on which direction should I take in so that my schema will not conflict with the reaction core enhancements?
Thanks

[aaronjudd]

To elaborate on what I was thinking in #236

#Multi Vendor

REACTION ADMIN grants a USER ROLE with JOIN and MEMBER roles.

If USER has the JOIN role

 - JOIN gives permission to add "MEMBER" to their role (manual on some confirmation)
 - `MEMBERS` can create a shop while at the top level `SHOP`
 - `MEMBERS` become `ADMIN` of created `SHOP`.
 -  REACTION `ADMIN` has `SUPERVISOR` role for all child shops (need to define more on this role)

The MEMBER role provides them a configurable set of ROLES (set by the REACTION admin).

ROLES and Publications completely control access options, such options are:

Can vendor

• create products
• process orders
• fulfill orders
• publish products

Views

SHOPS can be filtered by DOMAINS
SHOPS could be allow/deny by a USER ROLE
Use ROLES to determine product visibility on any SHOP

Shipping, Payments, Checkout

Can checkout contain multiple shop items in checkout?

Shipment is consolidated into shipmentQuotes, but shipmentRates is stored with order. Store shop(vendor/user) specific rates there, for tracking, use those rates for each shops order review/instruction.

ShopId is stored on all products, so we can break out each shops carts totals filtering the orders.items by shopId.

Fallback to top shop with any missing components.

Customers
Guest checkout or account from current shop/

#Multi-Tenant

Host multiple separate shops, use DDP to login and share methods between shops.
This requires building a lightweight control panel / management tool (aka reactioncommerce site).

[boboci9]

Hi Aaron,
Thank you for your detailed response, but I think I am still missing an important point.
How can I handle different shipping options in the same order since for now the shipmentRates is one object per order but if I have in the same order products from two different shops and there are different shipping methods selected for the shops the suborders will have to have different shipmen rates.
Maybe if the shipmentMethod would be an array containing the shopId, or what else would you suggest?

Thank you!

[aaronjudd]

From gitter chat -> but in short the payment object should have quotes, rates, and selected method. where rates would be for every shopId, every product. where shipmentQuotes are the filtered values the user sees, and selected being the method. The opportunity here is to consolidate rates by "group" so that the user just selects a shipmentQuote that is a cumulative shipping method (and price) per order. You could potentially split it out in the view (per shop) as well by using the shipmentRates... and you'll always know what each vendor/rates were by that data.