One building with a press, a store and a shop counter

Your one building has a press, a store room and a counter where people walk in and buy things. The software asks you to set it up as three locations, and then to transfer stock from one to another before you can sell it. You are moving goods around on paper that have not moved an inch.

The first customer we built for was exactly that. The second had a production unit twenty minutes outside town and two shops. The third had a store that supplied both. If the software gives every location a single type, the first customer cannot be described at all.

What was actually going on

With a type on each location you have two bad choices. Create three records for one building, and stock sitting on one shelf lives in three places and has to be transferred to be sold. Or invent a fourth type called “mixed” and special-case it everywhere it appears.

So a site in our system has no type. It has a list of what it can do: produce, hold stock, and take till sales. One building holds all three. The production unit holds one. The shops hold two. Nothing is duplicated and nothing is special-cased.

A type forces you to list the combinations in advance. Three abilities make seven useful combinations, and nobody lists seven. You list the three you have seen and add a fourth when a customer complains, until the list holds values that are really combinations wearing a type’s name. A list of abilities says the true thing instead: here is what is physically there, which is what the business tells you when it describes a place.

Each screen then states what it needs. Production needs a site that can produce. Till sales need a site that can take till sales. Stock listings need a site that holds stock.

We also found a fault in the rule that enforces this. The check takes a list of abilities and passes when the site has any of them. A screen that needs both till and stock would therefore accept a site with only one. Nobody chose that. It is what you write when every screen names a single ability, because with one the words “any” and “all” mean the same. I read it the wrong way round at first, assuming a screen naming two required both, and only saw the difference when I followed a request that should have been refused.

What we changed

Sites in the product carry a list of abilities rather than a type, which is why one building can hold a press, a store room and a retail counter over a single pool of stock.

For the check we set the rule that it must say in its name whether it needs any or all. Two plainly named checks cannot be misread; one check with a silent choice is a fault waiting for its second user. This write-up does not record the date that change shipped.

What it did not fix

Abilities describe what a site can do, not what a person may do there. Those are different questions, and mixing them is how a fact about the building ends up in the permission layer, where a permission shortcut can switch it off. The ability test belongs in the checks on the action itself.

And a list of abilities does not say where stock sits inside a site. One building with all three holds one pool of stock. That is right for a small operation and wrong the day somebody wants shop-floor stock counted apart from back-store stock. That is a bin or sub-location model, a different feature, and the abilities list will not help when you need it.

The pattern, for anyone choosing stock software

Model a place by what it can do, not by what it is. A type is a compression of abilities, and it loses the most exactly where your sites differ.

The test takes a minute. Describe your three most awkward sites out loud. If any description needs the word “and”, software built on location types is going to cost you a rework, or a lot of pointless transfers.

Where this ends up

The same thinking runs through Sazinga Factory, where one building can make goods, hold them and sell them over one pool of stock, with no paper transfers between rooms.