Lesson 5 — Reseed, permissions, and why your manual edit will not survive
The last lesson is about who is in charge of the mapping, and the answer is not the person editing it.
The rule, in the guide's own terms. You can change a mapping by hand, and the seed will put it back the next time it runs. If a change should be permanent, it belongs in the module, not in the database. That is not a restriction dressed up as a principle — it is the only way a mapping can be reproduced on a second database, on a fresh company, or after a restore, and configuration that cannot be reproduced is configuration you will lose.
When the seed runs. Its install hook seeds every UAE company that already exists when the module installs. It cannot reach a company that did not exist when it ran, which is the whole reason the reseed button exists. And it only seeds companies whose country is the United Arab Emirates — so if nothing was seeded at all, the country is the first field to check, not the mapping list.
The click path for a company created later. Three steps, in this order, and the order is the part people get wrong.
- Set the company's country to the United Arab Emirates and make sure it has a chart of accounts.
- Make that company the active company. The reseed acts on the active company only.
- Go to Payroll → Configuration → Settings → UAE Payroll Accounts and press Reseed UAE payroll accounts.
It is safe to run repeatedly. The reseed re-runs the whole resolution for the active company: existing accounts are matched rather than duplicated, and a mapping that has drifted is corrected rather than added to. There is no state to clean up first and no window in which the company is half-mapped.
Who is allowed to do what. No new groups are created. The split is between reading the mappings and changing them.
| Action | What it needs |
|---|---|
| Reviewing the mappings | The Payroll role |
| Changing a mapping | Accounting → Manager |
| Pressing Reseed UAE payroll accounts | Accounting → Manager |
And the check is repeated on the server. Hiding a button restricts the button and nothing else, so the manager requirement is re-checked server-side and a direct RPC call cannot bypass the button's own restriction. That is worth knowing for two reasons: an integration running as a payroll user will be refused rather than quietly succeeding, and a permissions review can be answered honestly rather than with a screenshot of a hidden menu.
The worked example is the one that bites. You add a second UAE company mid-year — a new branch entity, say — and payroll for it starts posting on the first company's accounts. Nothing is broken and nothing needs repairing in code: the install hook ran before that company existed, so it was never seeded, and the mapping it is using is not its own. Set its country, activate it, press Reseed, then open the mapping list grouped by company and confirm the new company now has its own rows.
The failure mode, and the habit that prevents it. Both of this lesson's failure modes are the same mistake seen from different sides — a company the seed never reached. Nothing seeded means the country was not the United Arab Emirates when the hook ran. A second company posting on the first one's accounts means Reseed was never run with that company active. So make the reseed part of your new-company checklist, immediately after the chart of accounts, and check the mapping list grouped by company before the first payslip run rather than after it.