Voting starts in March for the Drupal Association Board election.
While a common use case for Commerce may be a single store representing a single seller, many use cases involve "marketplace" functionality in which there are multiple sources of products and/or multiple recipients of financial transactions.
It may not be necessary for Commerce core to support such marketplace functionality, but at the least it would be valuable to identify and document/fix:
- Existing or planned Commerce extensions focused on marketplace usage.
- Site recipes or models that can be used to implement marketplace functionality.
- Changes to Commerce core that may be required to facilitate marketplace functionality.
A BOF session took place at Drupalcon London, with results summarized in #98.
A number of options have been identified for providing marketplace functionality, including:
- Provide a "store" entity type, allowing multiple stores, each with its associated products.
- A store is an organic group, with products associated via an OG field, see #55
- A store is a user profile type implemented via Profile2, see #72
Relevant sites and case studies:
Relevant Commerce plugins that may cover part of the overall need or serve as instructive models:
- https://github.com/amitaibu/commerce-paypal-chained, see #189.
- Commerce payout, http://drupal.org/sandbox/ASupinski/1342892, see #155.
- Commerce offer, http://drupal.org/sandbox/bojanz/1123256, see #98.
Work already completed in Commerce to facilitate marketplace functionality:
- A sandbox has been created at http://drupal.org/sandbox/damz/1232160 for marketplace development. It is currently unused.
- The Inline Entity Form (formerly known as the Commerce inline product form) has been written and is now in a usable state. It is a requirement for marketplaces because it solves the product display -> product separation problem for merchants, allowing them to manage everything through the node add / edit screen. You can help it by testing and providing bugfixes.
Work to be done by the community
Plan outlined in #239:
- Create a commerce_marketplace module.
- An entity that represents the store. That can either be the user, a store entity clicked together through the ECK module, or a store entity provided by a module (a commerce_store module, for example).
- Entityreference. Then a bunch of entityreference fields that point to the "store" entity (or user). One on products, one on product displays, one on orders.
- Form alters that hide the entityreference fields on product displays and products (or just use a "hidden" widget) and fill it in with the known value (you always know which store the user has. If not, give him a dropdown...).
- A custom submit handler for the add to cart form (replacing the existing submit handler) that adds a product to an appropriate order (since there's an order per store for each customer), and if the order doesn't exist yet, creates it and sets the value of the entityreference field.
- Custom view for cart/ that shows all active carts to a customer.
- Custom views filtered by the entityreference field that show the merchant the products and orders for his store.
- Solve the Payment problem by adding support for three-way transactions to the commerce payment modules of gateways that support that.
Original report by jucallme
Commerce assumption's is that there is one store on the site. However when we deal with marketplace (i.e. any user can buy for any other user) that assumption is not correct.
My suggestion is to add a "store" entity that will be referenced from the product. So for example:
1) T-shirt will reference the site's own store entity, that uses USD
2) Jeans will reference a user's store entity, that uses paypal API credentials different from the website.
This might add complexity for adding to cart, as product will need to belong to the same store -- but I want to get this idea out there.