Every Company in One Database

A group of companies usually ends up with a group of systems. One database per company, one login per database, and a consolidated view that exists only in a spreadsheet somebody rebuilds every month.

Nama ERP is a multi-company ERP in the sense that matters: the company is a field on the record, not a separate installation. Every entity in the group lives in one database, and a consolidated figure is a filter rather than a collection exercise.

Five dimensions, on almost every record

Nama answers “which part of the business does this record belong to?” with five dimensions — legal entity, sector, branch, department and analysis set — and almost every record in the system carries all five. They do three jobs at once:

• Security. A dimension can participate in record-level accessibility, so a user restricted to one branch sees only that branch’s records. Turn that off for a dimension and it stays descriptive and reportable, without being a wall.
• Reporting. They are how figures group, at every level from one department to the whole group.
• Account structure. Many charts of accounts encode dimensions straight into the code — 1010-05-03-11 reading as account 1010, sector 05, branch 03, analysis set 11 — and the system can read a code back into its dimensions.

Legal entity is the one that cannot be switched off; it is the company. The other four can be turned off entirely if your business does not use them, and their fields then disappear from every screen, which removes a column of noise from data entry across the whole system.

Shared where you want it, separate where you don’t

A record saved with no legal entity is public. One setting decides whether public records are visible from inside every legal entity — which is what you want for a common item catalogue that all the companies buy and sell from, while their transactions stay strictly their own.

The same logic runs down to details that usually get forgotten in a group. A customer’s credit limit can be set per company or per branch rather than once globally. Outgoing email accounts carry the five dimension columns too, so each company in the group sends from its own address.

Consistency the system enforces

The risk in a shared database is a document that quietly contradicts itself — a line filed to one branch under a header filed to another. Nama checks that as the document is saved, and you choose how loudly it complains: refuse the save, allow it with a warning, or say nothing. Leaving it at refuse is the safe setting, because an inconsistent dimension corrupts every report that groups by it, silently and for years.

Where a document must legitimately point at another branch’s record, the check can be relaxed on that single reference field rather than turned off everywhere.

Moving value between companies

When money moves inside the group, the Inter Company Transfer document records both sides in one step: a journal entry in the first company and its counterpart in the second, so the inter-company current accounts stay matched without anybody entering the same transfer twice. Fixed assets move the same way — transfer a machine to the sister company and two entries appear, one in each, linked by an intermediary account, with the receiving company taking the asset at its book value.

That is the test of a multi-company system. Not whether it can hold several companies, but whether a transaction between two of them is one document or two arguments.