Introduce "shops"

[alexsegura]

The problem

One of the main design problems we have, is that "B2B customers" (i.e, customers that don't have a customer-facing page) are represented as a Store entity, under the /api/stores endpoint.

The have a slightly different behaviour & features. For example, a Store may have a PricingRuleSet & a TimeSlot.

Actually, a Store & a Restaurant are pretty similar. They are both a LocalBusiness, and bike messenger companies deliver their products. The bike messenger company may deliver their products to customers, or businesses (or both).

The biggest difference is that a Store doesn't have customer-facing page.

No matter if this is a Store or a Restaurant, the main question is:

Do they sell goods online via our platform? Do they expose their catalog of products online publicly?

So it's more a matter of "enabling" online shopping for a Restaurant or a Store.

Introducing Shop concept

For a better separation of concerns, a customer-facing page should become a first-class citizen. A pretty simple way to do this is to extract all the logic into a Shop class. A Shop just exposes the catalog of a LocalBusiness online.

A LocalBusiness, no matter if it is a Store or a Restaurant, may have several Shop. This would easily fix the problem of franchises, where the same restaurant brand has several locations in the same city, with more or less the same catalog (currently, they are duplicated).

This would also allow to easily add online shopping later for a B2B customer. Since the beginning of the COVID-19 pandemic, we have seen lots of businesses switch from B2B to B2C.

Refactoring

The Restaurant & Store entities should be unified under a single local_business table in database, with inheritance mapping. All the entries in the store table need to be moved to the local_business table. We will lose the previous ids but YOLO.

A LocalBusiness may have one or many Shop

The catalog of products should be abstracted instead of being named a Menu. We can still expose a /api/restaurants/{id}/menu API operation but only for restaurants, for stores it should return a 404.

On the opposite, Restaurant should be closer to the way Store behaves, regarding deliveries for example. Currently, deliveries may be associated to a Store, but not directly to a Restaurant (the relationship is restaurant <-> order <-> delivery).

API endpoints (to be confirmed)

• /api/shops should slowly replace /api/restaurants
• /api/restaurants should be kept for backward compatibility
• /api/shops/{id}/deliveries should retrieve the collection of deliveries of a shop
• /api/local_businesses/{id}/shops should retrieve the collection of shops for a business

---

• https://schema.org/LocalBusiness
• https://schema.org/Restaurant
• https://schema.org/Store

[552020]

I'm not sure it was a good idea to have closed the issue #1518.

It could take probably months to complete this "refactoring": I don't think on the other hand that's is so hard to change only the denomination of the stores in clients on the interface: and this would solve some misunderstandings since "stores" wouldn't be used in two different meanings on the platform.

[552020]

In general it should be taken in considerations that the clients of the normal same-day-delivery business can be also "private persons" using the service regularly and paying on invoice. These clients are not necessarily always "shops" or "businesses".

[agichim]

I don't think it's worth opening a new issue.

I'm thinking maybe we can refactor the platform with this hierarchy:

Store

• e-commerce (currently restaurants)
• non e-commerce (maybe this should be named different, but not too technical; currently stores)

store is the general word used on the internet I think for online shops. a restaurant is not necessarily the only kind of store that can have an e-commerce presence.

e-commerce can be any kind of store. non e-commerce can also be any kind of store.

I'm commenting this as I'm thinking about the documentation. So in the docs we should have a guide for creating a e-commerce store or a non e-commerce store on the platform.

[agichim]

I'm unsure about my previous comment.

Mex, are you proposing to have 1 business account, either e-commerce or non-ecommerce? With a sort of toggle, when it's ON that business can be seen on the front-end for customers to purchase and if the toggle is OFF that shop disappears from the front-end?