Shift Assignment

1Purpose #

• Connects an employee to a shift defined in the Shift master, effective from a date. The shift carries the working-hours pattern and its attendance-type rules; this screen only says WHO works it and FROM WHEN.
• Attendance processing resolves the employee's shift for a day from this history: the row whose effective date is the latest one on or before that day.
• The legacy desktop form (Employee Shift Assignment) edited one row at a time; this page shows one employee's whole history as an editable grid.
• The same rows are also editable per employee from the Employee master's Shifts action — both screens edit the same table with the same rules.

2Your first assignment, step by step #

Suppose a new employee joins the General shift on the 1st.

1. Pick the employee in Employee — or press Unassigned (F4) to list the employees who have no shift yet and pick from there.
2. The grid loads their shift history — empty for a new employee.
3. Press Add Row (F3) ; the effective date defaults to today — change it to the joining date — and pick General in the Shift cell. (No shifts yet? Use the Create new shift button in the pick-list's footer.)
4. Press Save (F5) and confirm. All rows commit together in one transaction.
5. Months later the employee moves to Night from the 15th: open the same employee, add a NEW row — Night , effective the 15th — and save. The General row stays; attendance before the 15th still resolves to it.

3How to use it #

1. Find (F2) lists every assignment row in the company, newest first (the legacy Find); picking one loads that employee's history.
2. Unassigned (F4) lists employees with no shift assignment at all (the legacy F11 list; F11 itself toggles the browser's full screen) — picking one starts their history.
3. Add Row (F3) appends a history row; Remove marks a saved row for deletion on the next save.
4. Save (F5) commits the whole grid — inserts, updates and deletes — in one transaction.
5. Cancel (Esc) discards unsaved changes and reloads the employee's saved rows.
6. Switching employees with unsaved changes asks first — the grid holds one employee's rows at a time.

4Field details #

• Employee — a ledger account flagged as an employee. Required before the grid opens. The row stores the account's NAME (the table was not re-keyed), so a rename in the Ledger master flows through automatically.
• Effective Date (per row) — the date the shift takes effect. Required; part of the row's key.
• Shift (per row) — from the Shift master, active shifts only. Required; part of the row's key. The pick-list's footer can create a shift inline. A NEW row pre-selects the shift named by the payroll Default shift for new assignments setting when one is set (and still active) — a pre-filled row saves like any picked row, so remove or change it if the default is not wanted; a blank setting keeps new rows empty.
• Description (per row) — an optional note (up to 255 characters), e.g. why the shift changed.
• A row with no shift picked is simply skipped by the save — it is treated as an unfinished line, not an error.

5Shortcut keys #

• F2 Find assignment · F3 Add row · F4 Unassigned employees · 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? #

• Shift comes from the Shift master, table EmpShiftInfo , and shows ACTIVE shifts only — a shift marked inactive disappears from the pick-list but stays on saved rows. If the list is empty, define shifts in the Shift master, or straight from this pick-list's footer button.
• The grid itself shows nothing until an employee is picked — it holds one employee's history at a time.

7Rules and integrity #

• One shift once per date. The table's key is (employee, effective date, shift) — the same shift can not appear twice for one employee and date. The page checks the grid before saving and the server repeats the check with the same message. Two DIFFERENT shifts on the same date are allowed, exactly as in the legacy form.
• Every saved row names its shift and date. Both are parts of the key; a row with no shift is skipped, a row with no date is refused.
• Rows save row by row. Each row inserts, updates or deletes by its own SEQ identity, all in one transaction — the grid is never mass-deleted and re-inserted.
• The employee must be an employee account. The server verifies the picked account is flagged as an employee and refuses otherwise.
• A referenced shift can not be deleted. The database refuses (NO ACTION); mark it inactive in the Shift master instead.
• Inactive shifts can not be assigned. The pick-list already hides them, and while the payroll Block assigning inactive shifts setting is on the server also refuses a row naming one — so a shift retired between page load and save (or a bypassed pick-list) can not slip through. Rows saved BEFORE a shift was retired stay as history.
• Audit columns fill themselves. TranTime, UserName and WorkstationID come from database defaults on insert — no screen writes them.
• This page and the Employee master's Shifts dialog are the same data. Whichever is more convenient — one employee in depth here, or while editing the employee's record there.

8If something does not work #