Batch Assignment

1Purpose #

• Doing the same assignment employee by employee is slow — a new leave policy for a whole department, a night shift for a site, an annual increment for everyone. This screen does it in one run.
• Each assignment type writes the SAME table the corresponding one-employee screen writes: Shift Assignment writes the shift history, Leave Policy Assignment the policy assignments, Payhead Assignment the employee's pay scheme, Pay Template Assignment the template allocations.
• Pay Template Duplication & Assignment is the increment tool: it clones each employee's LATEST pay template under a generated name (employee code + timestamp, description BATCH ), adds the value change to the salary-bearing lines (base types Attendance and BasicSalary — other lines copy unchanged), and allocates the clone from the effective date with the IsBatch flag set.
• Villa/Apartment Assignment records staff accommodation; the villa list comes from the legacy villa master (no web page for it yet).
• Existing rows are never overwritten — every type inserts only where nothing exists yet. The one exception is Payhead Assignment , which UPDATES the rate/amount/contribution when the employee already has that pay head on that date (exactly the legacy behaviour).

2Your first batch run, step by step #

Suppose the whole Packing department moves to the Night shift from the 1st.

1. Press Load Employees (F2) — the list fetches once; the filters then work instantly, without touching the server.
2. The employee grid is a full grid: click a column header to sort , use its filter icon to filter on any column, and drag a header into the bar above it to group (by Department, say, then tick a whole group at once). The header checkbox selects everything the grid is currently showing, so filtering first and ticking the header is the quickest way to pick a set. Ticks survive sorting, filtering and grouping.
3. Set the Department filter to Packing . The other filters (designation, group, status, gender, marital status) narrow further; [ALL] means no filter.
4. Tick the header checkbox to select every filtered employee — or tick them one by one.
5. Pick Assignment Type = Shift Assignment and Night as the shift.
6. Set the Effective Date to the 1st — or tick use hire date to give each employee their own joining date instead (useful when seeding assignments for new joiners; a blank hire date falls back to today).
7. Press Start (F5) and confirm. The whole batch commits in ONE transaction; the result banner reports how many rows were applied and how many were skipped (already assigned), with the skips listed under the grid.

3Field details #

• Assignment Type — one of the six batch operations. Changing it swaps the value list and shows the fields that type needs.
• Value — WHAT is assigned: the pay head, template, policy, shift or house. For Pay Template Duplication it is replaced by the Value change — the amount added to each cloned template's salary lines (use a minus to reduce; 0 clones unchanged).
• Rate % / Amount / Employer Contribution Rate % (Payhead Assignment only) — the pay scheme figures written for every ticked employee. Blank counts as 0.
• Effective Date — the date every written row takes effect; disabled while use hire date is ticked, which uses each employee's own DOJ instead (blank DOJ falls back to today).
• Filters — narrow the employee list; they combine (AND) and never change what is already ticked outside the current view.
• The checkbox column — who gets the assignment. The header checkbox (de)selects every FILTERED employee; ticks on employees hidden by the current filters are kept.

4Shortcut keys #

• F2 Load/refresh the employee list · F5 Start the run · Esc Reset the selection and parameters.
• Enter moves to the next field.
• Keys belong to the focused copy of the page; a dialog's own keys win while it is open.

5Why is a pick-list empty? #

• The employee grid lists employees who have a LEDGER ACCOUNT linked — every batch write keys on it. An employee without one (incomplete record) does not appear; fix the record in the Employee master first. The grid stays empty until Load Employees (F2) is pressed.
• Pay template lists the Pay Template master; Leave policy the Leave Policy master.
• Shift lists ACTIVE shifts only — an inactive shift disappears from the list but stays on saved rows.
• Villa/Apartment lists the villa master ( hrVillaInfo ) — maintained in the legacy desktop application for now; the web has no villa master page yet.
• Department / Designation / Group filters list their masters; Status offers Active/Inactive.

6Rules and integrity #

• One transaction. The whole run commits or rolls back together — a failure half-way leaves nothing behind.
• Insert-if-missing. An employee who already has that shift/policy/villa/template on that effective date is SKIPPED and listed, never overwritten. Payhead Assignment alone updates the existing row's figures (legacy behaviour).
• One template allocation per employee per date. Enforced by a unique index across ALL templates — the run guards on it instead of crashing.
• Duplication needs a starting point. An employee with no template allocation yet is skipped — allocate a template first (Pay Template Allocation screen).
• Honest counts. The result reports what was actually written; the legacy counted every ticked employee even when its guard skipped the row.
• Same rules as the single screens. A row written here is indistinguishable from one written on the Shift Assignment, Pay Template Allocation or Employee master screens — those screens edit it afterwards as their own.
• Restructured storage. Since the employee-family cutover the writes go to the int-keyed base tables (the legacy name-keyed views stay for the desktop app); the shift table alone was never restructured and stays name-keyed.

7If something does not work #