Lesson 2 — How the seed finds an account before it creates one
The second idea is smaller than the first and saves more arguments: the module looks for an account four different ways, and creating one is the last of them.
Why this matters before you see a single screen. Your chart of accounts is the spine of everything you file. A module that creates a second Basic Salary account beside the one you already use has not added a feature — it has split your salary expense across two lines, and the split will be discovered by whoever is reconciling the year, months later. So the honest question to ask of any seeding tool is not what it creates. It is what it does when the account is already there.
The resolution order. The seed resolves each account in this order: by the UAE localisation's own identifier, then by code, then by English name, and only then does it create one. Accounts already in the UAE chart are reused. Read the order as three attempts to find, followed by one decision to create.
| Step | How the seed looks | What it catches |
|---|---|---|
| First | By the UAE localisation's own identifier | A chart installed from the UAE localisation, where the account carries the identifier the localisation gave it |
| Second | By code | A chart where the account exists under the expected code but not under the localisation's identifier |
| Third | By English name | An account carrying the expected English name under a code of your own choosing |
| Fourth | Create it | Nothing matched — the UAE chart genuinely has no account for this purpose |
Each mapping row tells you which step won. Every row records in its note how its account was found, so you can tell a reused localisation account from one this module created. That note is the first thing to read when a balance looks wrong, because it answers the question underneath most payroll ledger disputes: is this our account, or one the module made?
The click path. Open Payroll → Configuration → GL Account Mapping, and group the list by company. You get one row per salary rule per company, each with its account and its note. Nothing here is hidden in code — the whole result of the seed is visible on one list.
Run it twice and nothing happens. That is the property worth testing on your own database rather than taking on trust. Everything is matched before it is created, and a second run changes nothing. A mapping that has drifted is corrected rather than added to, so the list does not grow a duplicate row for the same rule.
The failure mode. If you do find two accounts that look like the same thing, the seed did not make them both. Open the mapping note and see which account the module is actually posting to, then deal with the other one as the chart-of-accounts question it is. The reverse case is more common and easier: nothing was seeded at all, which is a country problem rather than an account problem, and Lesson 5 fixes it.