Last time we talked about currencies. Now it's time for arguably one of the biggest new concepts in Commerce 2.x: stores.

Stores represent billing locations, and were made to cover these two primary use cases:

1. One business with multiple billing locations

   The same product catalog is used for all stores. Customers always belong to a single store, usually based on their billing address.

   Example: Commerce Guys has a French office and a US office. These offices are separate legal entities. People who purchase Platform.sh are billed from one of the offices based on their location. EU customers are assigned to the French office, North American customers to the US store.

2. The "Etsy" marketplace model

   Sellers can open accounts on the site, create and sell their own products.

   The product catalog is store specific. The site lists multiple stores, each with their own products. Products are grouped into carts/orders per store.

Implementation

Stores are content entities. They contain the following information:

• Email (used on order confirmation mails)
• Address (shown on invoices)
• Supported billing countries (restricts the country list shown on checkout)
• Tax settings

Knowing the store address is a big help when resolving tax types. E.g, if the customer is German, and the system knows that the store is located in France, it can select the French VAT by default.

Stores can have multiple types, and are fieldable. Does your store exist in the analog world and needs to show the opening hours on the site? No problem, just add a new field.

Products can belong to one or multiple stores. An order always belongs to a single store. Carts are still orders, but there can now be multiple active carts, one for each order type and store. If a customer adds products from two stores to his cart, they will get two carts, two checkouts. This is the same UX as implemented on Etsy. Other Commerce entities will also be store aware. For example, it will be possible to limit a discount to one or multiple stores.

To improve the UX of store selection, we've created a special form element (and matching field widget) called entity_select. If the element is required and there's only one available entity, it outputs a hidden field. This means that people that use Commerce with only 1 store won't ever see the store selector. For up to 7 available entities (configurable) a set of checkboxes/radio buttons is shown, and for more than that, an autocomplete field is shown instead.

Getting started

So, how do you start selling with Commerce 2.x? The flow is:

1. Import a currency.
2. Create a store.
3. Create products.
4. Find customers!

To make steps #1 and #2 quicker (and less clicky) we provide our first of many Drupal Console commands:

It asks for the store name, email, and country. It then finds the default currency for that country, and offers a chance to confirm or override it. Finally, it imports the currency and creates the store.

Conclusion

It's much easier to design Commerce for multiple stores but allow people to use it with only one, than to do it the other way around. The Etsy use case still won't be complete without a contrib module, but Commerce itself is now doing the heavy lifting, thanks to the store entity and multiple carts. And of course, for those sites that only bill from one location, the UX remains unchanged from Commerce 1.x.