Most businesses that outgrow a single shopfront do it by accident. A supplier relationship turns into a brand store. A product line gets its own domain because it sells to a different sort of customer. Within a year there are two or three storefronts, all drawing on the same ERPNext catalogue, and none of them wanting the whole of it.
The naive answer is to maintain a separate product list per shop, which puts you back where you started. The better answer is to let the catalogue stay whole and decide, per shop, which part of it is relevant.
That decision is what routing rules are. A rule looks at a field on the item and says whether this shop should receive it. An item arrives, every shop attached to that ERP is asked, and the ones that match get the update.
Routing by item group
Item groups are the usual basis, because most catalogues are already organised that way and the grouping already means something to the business.
One of our customers runs a lighting store that only wants lighting. The rule is a single line:
where data.item_groups contains Lighting, allow it through. Everything else in that ERP, and
there is a lot of it, never reaches the shop. They have a dozen similar rules sitting beside it,
one each for Smart Switch, Smart Dimmer, Smart Bulbs, Smart Sockets, Smart Magnetic Tracks and the rest, which together describe exactly the range that storefront sells.
Writing it as a dozen narrow rules rather than one broad one is deliberate on their part. When a new category appears in the ERP it does not quietly turn up on the shop, because nothing yet says it should. Adding a line is a decision somebody makes, which is the point.
Routing by anything else on the item
Item groups are the common case rather than the only one. Another customer sends a single brand to
its own domain: where data.brand equals Edifier, allow it to the Edifier store. The brand field
was already on the item for ordinary ERP reasons, so the shop costs them nothing to maintain.
Any field on the event can be matched, with equality or a contains test, and a rule can be an allow or a deny. Deny rules are evaluated alongside the allows and are the cleaner way to carve out an exception, such as a category that belongs on the shop with the exception of one discontinued line.
It works in both directions
The arrangement that surprises people is more than one ERP feeding one shop. We have a storefront in production that receives products from two separate ERPNext instances, each with its own rules, because the business runs two companies and sells from both through one website. The shop does not know or care, and each ERP keeps its own books.
The reverse is the more common shape: one ERP, several shops, each rule set describing a different slice. Both work because the routing decision belongs to the pair rather than to either side.
What happens when nothing matches
A site with no rules at all receives everything from its ERP. That is the right default for the first shop somebody connects, because the alternative is a connected store that stays empty until you work out why.
Once you add a rule, that site receives what the rules allow. So the sequence most people follow is to connect the shop, watch a few products arrive, and then narrow it down to the range that belongs there.
You can see which rules matched for any item in the activity log, which matters on the day a product does not appear where somebody expected it. The answer is usually that it belongs to a group nobody has added a rule for yet, and the log says so rather than leaving you to guess.
See pricing or talk to us about how your catalogue is organised.
