Craft Commerce: Bakery site with multiple bakeries (How to handle product types and variants)

Question

Alright, so I am trying to persuade a client to switch to Craft Commerce for their bakery shop.

Thing is, their current setup is kinda messy, and I just cant figure out how to convert it properly to Craft.

Case: They have Cakes, Cakes comes in a multitude of sizes, with a lot of choices. Different types of cakes have different choices (Fill, jelly, nuts, colors, figures etc.)

All possible combinations of the choices results in a unique ID (EAN) for that cake, that the bakery can use in their system for production.

Thats ok, we can have product types and variants for all these. But here is the hard part: each bakery have their own set of choices, some bakeries dont have the same type of jelly, or the same colors for the toppings.

Each bakery choose what cakes they want to sell, and what kind of configurations they have.

When on their front page, you type inn your ZIP code and we use that to determine the closest bakery, based on that, we show that bakery's cakes, with their configurations.

Since there are about 10 bakeries, having a chocolate cake with custom variants per bakery will get really messy really fast, given how many cakes each bakery has. So I am trying to figure out how to separate each bakery and its product in the CP.

I toyed with the idea of creating one product type per bakery, and just having a generic "cake" model that can be built up however they like, but this seems very hard for both us and the client, they having to create the same options over and over, and us having to "magically" get all kinds of configurations from some kind of matrix field, creating choices based on this in the frontend, and sending those choices by mail when the order is complete.

Is there some kind of "hack" where I can have a separate product (database) tables per user group, or something like that? If bakery X logs on the CP, we show products from this table, if bakery Y, we show products form another table.

The rest of the site is going to be joint, about us, contact, articles etc are all the same across bakeries. So I would like to avoid having 10 licenses, 10 databases and 10 installs to cope with this.

Any other ideas are greatly appreciated, maybe I am looking at this the wrong way, but having 300 cakes, with 18 variants each is going to make it impossible for a specific bakery to maintain their cakes.

Mathias

Answer 1

The way I see it, you have 2 very similar but different problems:

1. How does each bakery log in and maintain their own inventory?
2. How does each cake get built up in the admin?

You can pull off the separation of locations by using different permissions. Each Bakery would have their own user login (Store #1, Store #2, etc.) By setting the appropriate permissions, when Bakery #1 logs in, they won't see any other entries/products other than their own. To filter this on the front end, you just ask Craft to filter by the appropriate author. So in other words, Author = Bakery location.

We built a site where we had different, individual teachers logging into the same Craft install. Every teacher could post their own class schedule. We also didn't want them to view or edit each other's classes (but everyone on the front end could see and filter them for example). In your case, it would basically work the same way.

The second problem is much more complex. I don't think you're that far off from creating a single "cake" product or different cake products (depending on what you're selling), for example, and then creating different options (variants) around those basic types. How you build up those products really depends on how you manage inventory, SKUs, variants, prices, etc. If some of those options don't have prices (eg butter creme frosting doesn't cost more than vanilla), it's just an additional option, that gets to be a bit easier in terms of options. You can just pull those options off with Craft fields.

Another way to pull it off on the admin side would be if the bakeries know how to upload an Excel/CSV file to the site, they could update their availability from that. It would be up to the you, the developer, to figure out what data is available and some sort of function to make it work. That's a pretty common use case for, say, a manufacturer with thousands of SKUs. To change pricing one-by-one in the Craft admin would take hours. But a CSV lets you bump all the prices up or down with just a couple Excel macros, which you can then export out.

FWIW, these are both non-trivial problems to solve. There's probably other ways to do so but Craft gives you some tools to help pull this off.