Add a second legal entity to a live installation
"We have registered a second company for the new plant in Faisalabad. Its people will be on its own payroll and its own books. Switch it on."
What is really being asked
He is asking for a second legal entity, and he assumes everything will be copied. It will not. Some of PeopleNest is one list for the whole installation and is already there the moment the entity exists. The rest is held per entity and is empty on the new one until somebody builds it.
Getting this wrong in either direction is expensive. Build a shared screen twice and you have two codes meaning one thing for the rest of the installation's life. Forget a per-entity screen and a payroll run comes up with nobody on it.
So the real outcome is a short list, and the discipline to work through it.
What you need in place first
- Legal Entity - the new entity itself, with its own name, currency and address.
- The existing entity's setup, as the thing you copy the shape of. Open it alongside.
- Agreement from the client on the one question that decides half of this: do the two companies share a working week and a holiday list, or not? The Calendar is shared, so if they do not, the new entity needs its own calendars.
What is already there, and what is empty
Shared across the whole installation. Do not build these again.
Calendar, Time Template, Public Holiday, Wage Type with its Wage Type Group and Wage Type Category, Pay Scale, Pay Area, Payroll Group, Pay Rate, Payroll Cycle and its Payroll Period, Payroll Tax Group and Payroll Tax Slab, Position, Position Grade, Position Category, Department, Business Unit, Business Area, Employee Type, Attendance Policy, Exemption Type, Roaster, Evaluation Template and Evaluation Increment Matrix.
The new entity can use every one of these on the day it is created.
Held per entity. Empty on the new one.
Leave Type and Leave Group, Shift Pattern and Shift Roster, Employee Policy Profile, Salary Structure, Contribution Scheme, Overtime Policy Setup and Over Time Category, Loan Type, Gratuity Policy, Evaluation Cycle, Evaluation Metric, Performance Target Entity, and every employee record on Employee Basic Information.
Build each of these on the new entity, in the order the order of setup gives. Use the same codes as the first entity where the client wants the same meaning, so that reports read the same across both.
Build the per-entity list in this order, because each one needs the one before it: Leave Type, Leave Group, Shift Pattern, Employee Policy Profile, Salary Structure, Contribution Scheme, then the people.
Load the people. Employee Basic Information for each man, then Employee Organization Assignment to put him on a position, a policy profile and a salary structure in the new entity.
Prove the configuration with a dry run before anybody is paid. See the first payroll run at a new client. The new entity is a new client for this purpose, even though the installation is old.
The Calendar is shared, and that is the trap
The Calendar is one list for the whole installation. It carries the working week, the daily working times, the attendance allowance rule and the sandwich-absent rule, and none of it is held per entity.
That cuts two ways.
- You do not build the factory and office calendars again. The new entity attaches its policy profiles to the calendars that already exist.
- A change to a calendar changes it for every entity at once. Raise the attendance allowance from 3,000 to 3,500 because the new plant asked for it, and the old company's five hundred men get the rise too, in the same period, with nobody told.
So when the new entity wants a different rule, create a new calendar, do not edit the old one. Name it so nobody is in any doubt: FSD-FACTORY rather than FACTORY-2.
Public Holiday is shared the same way. A holiday declared for Punjab lands on both companies. If the two entities are in different provinces with different holidays, you need to say so to the client now, because the holiday list cannot be split by entity.
Where two clients differ
| Two plants of one business | Two genuinely separate companies | |
|---|---|---|
| Calendar | Share the existing ones | New calendars, new names, same screen |
| Leave Type codes | Same codes, rebuilt per entity | Whatever each company's policy says |
| Salary Structure | Mirror the first entity | Built fresh |
| Payroll Cycle | Shared, so the same periods | Shared, so the same periods even if they did not want that |
| Wage Type | Shared, add to the one list | Shared, so prefix the new ones |
| Who runs payroll | One HR team, switching entity | Two teams, each on their own entity |
Note the row that surprises people: the pay periods are shared. Two companies that close their month on different dates need two payroll cycles on the one shared list, not one cycle each in their own entity.
How you prove it worked
- Switch to the new entity and open Employee Policy Profile. It must list the profiles you built and nothing from the other entity.
- Open Wage Type in the new entity. It must list every wage type the old entity had, without you having created any. If it is empty, you are not where you think you are.
- Open Shift Roster for a week in the new entity. Every man must have a shift. An empty roster means the policy profile or the shift pattern is missing, not the roster.
- Run Payroll unposted for the new entity's first period. Check the headcount on it against the number of employees you loaded. Those two numbers must match before you look at any money.
- Run the old entity's payroll unposted for the same period and compare its total against last period. It must not have moved. If it has, you edited something shared.
What will go wrong
- A calendar is edited instead of added, and the other entity's allowance or working week changes silently in the same period. Nothing warns you. Always add.
- The wage types are created again with new codes because somebody did not realise they were already there. Now the installation has two codes for basic salary and every cross-entity report has to be explained.
- Payroll runs with nobody on it. The people exist but have no organization assignment in the new entity, or no salary structure, so the run pulls nothing. Check the assignment before you blame the run.
- The new entity's first payroll is posted on the same day it is built. Do the unposted dry run. An installation that is already live has a client who will compare the two companies' totals, and he will do it the same afternoon.