1Purpose #
- Connects the two sides of payroll: the Pay Template master defines WHAT a salary structure pays; this screen defines WHO is paid by it and FROM WHEN.
- Allocations are dated, so a raise or a re-grade is recorded as a NEW allocation with a new effective date — the old row stays and keeps history intact for past pay periods.
- The legacy desktop form (Employee Paytemplate Allocation) edited one allocation at a time; this page shows a whole template's allocations as one editable grid.
2Your first allocation, step by step #
Suppose the template Workers should pay three employees from the 1st of the month.
- Pick Workers in Pay Template — or press Find Template (F2) to browse. (No templates yet? Use the Create new pay template button in the pick-list's footer.)
- The grid loads the template's existing allocations — empty the first time.
- Press Add Row (F3) and pick the first employee; the effective date defaults to today — change it to the 1st.
- Repeat for the other employees. Enter moves across the cells; off the last cell it appends the next row.
- Press Save (F5) and confirm. All rows commit together in one transaction — if any row is wrong, nothing is half-saved.
- Later, when a worker moves to the Staff template: open Staff and add a row for the worker with the move date. The old Workers row stays — it is history.
3How to use it #
- Find Template (F2) lists every pay template; picking one loads its allocations (the combo at the top does the same).
- Add Row (F3) appends an allocation row; Remove marks a saved row for deletion on the next save.
- Save (F5) commits the whole grid — inserts, updates and deletes — in one transaction.
- Cancel (Esc) discards unsaved changes and reloads the template's saved rows.
- Switching templates with unsaved changes asks first — the grid holds one template's rows at a time.
4Field details #
- Pay Template — from the Pay Template master. Required before the grid opens; the footer of the pick-list can create one inline.
- Employee (per row) — a ledger account flagged as an employee. Required; part of the row's key.
- Effective Date (per row) — the date the template takes effect. Required; an employee can hold only ONE allocation per date, across all templates.
- Calculate Extra Remuneration ? — appears only when the preference Allow Employee Extra Remuneration is ON; marks the employee for the extra-remuneration computation.
- TDS Amount — a company-specific column (legacy shows it only for companies named like GK…GROUP…); the monthly TDS deduction.
- Work Site is not on this page — the legacy field appears only under a preference and its master is not ported; stored values are preserved untouched.
5Shortcut keys #
- F2 Find template · F3 Add row · F5 Save · Esc Cancel.
- Enter moves to the next cell; off the last grid cell it appends a new row.
- Keys belong to the focused copy of the page; a dialog's own keys win while it is open.
6Why is a pick-list empty? #
- The grid itself shows nothing until a template is picked — it holds one template's allocations at a time.
7Rules and integrity #
- One allocation per employee per date — across ALL templates. A unique database index on (employee, effective date) enforces it; the page checks the grid before saving and the server re-checks the whole table with the same message (naming the clashing template).
- Every row names its employee and date. Both are parts of the row's key; a row missing either can not be saved.
- Rows save row by row. Editing the grid does not delete and re-insert everything; each row inserts, updates or deletes by its own identity, all in one transaction .
- Deletes are clean. Nothing references an allocation row, so removing one has no side effects — but remember past pay periods were computed from it.
- Template and employee must exist. The server verifies both and refuses with a friendly message instead of a database error.
- Off-form columns are preserved. Work site and the batch flag (stamped by legacy tools) survive an edit here untouched.
8If something does not work #
"Every allocation row must name an employee." / "An allocation row names an employee account that no longer exists. Reload the page and try again."
- Why
- An allocation is one employee's; the row is blank, or points at somebody deleted.
- What to do
- Fill or remove the row; press F5 to refresh the list.
"Every allocation row needs an effective date." / "Every row needs an effective date."
- Why
- The date decides from when the template applies, so a bill can tell which one was in force.
- What to do
- Give the date - usually the start of the payroll period.
"Pay template '...' does not exist any more - reload and pick again."
- Why
- The template was deleted while the page had it.
- What to do
- Press F5 and pick again.
A pay bill uses an older template
- Why
- The bill uses whichever allocation was effective on its own dates.
- What to do
- Check the effective dates; a new allocation does not reach back over bills already made.
This is the help InvoiceNET® ERP shows beside the Pay Template Allocation screen. Whether you have the screen depends on the modules of your licence and the rights your administrator has given you.
See this screen for yourself
The demo is the real product, with a company of your own.