Who can see whose money
When one operator runs several legal entities, a shared workspace becomes a channel between them unless somebody decides, field by field, what crosses.
A shared container with unfiltered contents is a leak with a good interface.
An operator with one legal entity has a simple question to answer about access: who works here. An operator with twelve has a second question underneath it, and it is the harder one: whose money is this, and who is allowed to see it.
#Two axes, not one
Most systems model a single boundary — the customer. Everything inside it is shared. That is correct for a part number: an engine type is the same engine type regardless of which of your companies bought it, and splitting the catalogue by company would give you twelve catalogues of the same parts.
It is wrong for an order. A purchase order belongs to a specific legal entity, because somebody will pay that invoice and it will appear in that entity's books. So the boundary runs differently for different things:
- Part master data, suppliers and customers — shared across the organisation
- Orders, agreements, invoices, stock movements — owned by one company
- Projects — visible to the organisation, but with contents filtered per viewer
That third line is the one that took the longest to get right, and it is the one where the two boundaries meet rather than sit beside each other.
#The container can be open. The contents cannot.
A project is deliberately visible to everyone in the organisation, because work crosses entities and people need to see what is running. Its ledger, though, belongs to one company.
That combination is a leak waiting to happen, and it was measured rather than assumed: a user with access to two companies could list a third company's agreement through the project, and the project's financial roll-up included money from a fourth company they had no access to at all. Nothing in the interface suggested anything was wrong. The totals simply included things the viewer was not entitled to see.
#A partial total that admits it is partial
The fix is not only to filter. A filtered total that looks complete is worse than the leak, because the leak is at least detectable. So a filtered list returns a count of what was withheld, and a filtered roll-up says how many records it could not include.
Showing an incomplete total as if it were complete is a lie the interface tells on your behalf.
The viewer sees the figure they are entitled to, and sees that it is not the whole figure. Those are two different facts and both of them matter — one for the decision, one for knowing whether to ask someone else.
#Why this is not a permissions setting
It would have been easier to make company access a checkbox inside the permissions matrix. It is deliberately not, and the reason is that a job title and a financial boundary are different things. A buyer is a buyer in every one of your companies; which companies' money that buyer can see is a separate decision about that person, and it belongs with the person rather than the title.
Keeping them separate costs an extra screen. Merging them costs the ability to answer the question this article is named after.