Day-to-day operations
Once a connection is verified, most days need no attention at all. This page covers the checks worth making and the two jobs that need a human.
The daily glance: Dashboard
The dashboard answers one question — is the mirror healthy? Four numbers carry most of it:
| Card | What to look for |
|---|---|
| Employees mirrored | Should track your BioTime headcount. A sudden drop means people vanished from the remote system. |
| Bound to ERPat | The percentage that matters. Anything left over is on the Needs review list. |
| Transactions mirrored | Grows steadily. A flat count between days means the sync is not running. |
| Devices online | An offline terminal is not sending punches — the sooner you know, the less data you lose. |
Below them, the last sync strip shows when the mirror last updated and how many new punches arrived, and binding health breaks the population down by state so you can see whether the leftovers are harmless or need work.
Running a sync
The scheduled job keeps things current on its own. You would run one by hand when you have just changed something on the BioTime side and do not want to wait, or when you are deliberately reaching further back in time.
-
Choose the scope
Tick only what you need. Pulling Organization and Employees is quick; Transactions is the one that takes time.
-
Set the window
For transactions, the date window decides how much is fetched. Leave it alone for a routine top-up — the sync already re-reads a short overlap so nothing is missed.
-
Press Run sync and watch
The console reports each resource and page as it goes, and the counters move in real time. You can leave the page — the run continues to be recorded — but the live console only exists while you are watching it.
Why there is an overlap window
A terminal can upload a punch minutes after it happened. If each sync started exactly where the last one stopped, those late arrivals would fall in the gap and be lost forever. So every run re-reads a short overlap — ten minutes by default — before the last punch it saw. Re-reading is free: a punch already mirrored is recognised and skipped.
Reviewing employee bindings
This is the one screen that genuinely needs a person. Open Employees & Bindings and work top-down through the states that are not yet settled.
| State | What it means | What to do |
|---|---|---|
| bound | Confirmed by a person. | Nothing. |
| auto_matched | A single, unambiguous match on ID number. Applied, but reversible and unconfirmed. | Use Accept safe matches to confirm in bulk. |
| suggested | A similar name was found, but nothing was applied. | Open the row and confirm or reject the suggestion. |
| conflict | Two or more ERPat employees share this ID number. | Pick the right person by hand — or fix the duplicate ID number in the employee records. |
| not_found | No ERPat employee carries this ID number. | Either the person is not in ERPat yet, or their ID number differs. Bind manually. |
| unbound | Not matched yet. | Re-run the matching pass, or bind by hand. |
| missing_remote | Present in an earlier sync, now gone from BioTime. | Usually nothing — the binding is kept so their old punches stay attributable. |
| ignored | Deliberately excluded (test cards, shared badges). | Nothing. |
| disabled | Disabled or attendance-off on the BioTime side. | Nothing in ERPat. |
Accepting the safe matches
Accept safe matches promotes automatic matches to confirmed bindings in bounded batches, with a live console naming each one as it goes. It only ever touches auto_matched rows — conflicts and unconfirmed suggestions are never included, because neither has a single answer a machine could pick.
Resolving a conflict
Open the row. You will see the candidates that share the ID number, each with their job title and department so you can tell them apart. Choose the right person and save.
A manual binding is authoritative — no later automatic pass will overwrite it. If the underlying problem is a duplicate ID number in your employee records, fixing that is the better remedy, and the next matching pass will then resolve it cleanly.
Reading Attendance Transactions
Each row is one raw punch, stored exactly as the server reported it. The listing opens with the ERPat identity of the person it belongs to; where those columns show a dash, the punch is not yet attributable to anyone — which is the same list the binding screen is asking you to work through.
Both local and UTC times are shown. The local time is the one your operators recognise; the UTC one is what every filter and calculation actually uses. The day a punch belongs to always follows local time, so an early-morning punch belongs to that morning.
Importing attendance
Once employees are bound, Biotime can turn their punches into ERPat attendance records. An administrator switches this on in Settings → Attendance Import; it is off until they do.
How a day becomes a record
Punches are grouped into shifts: consecutive punches within the configured gap (6 hours by default) belong to the same shift, and a longer gap starts a new one. Within a shift, the first punch is the time in, the last is the time out, and the ones between become break pairs.
Each closed shift becomes one attendance record in Pending status, which appears in ERPat's own Attendance screen alongside everything else awaiting approval. Approving it calculates its payroll totals in the usual way. Nothing is approved automatically — that step is what catches a terminal with a wrong clock before it reaches a payslip.
Why today's shift is not there yet
A shift is only imported once the gap has passed since its last punch. With the default 6 hours, somebody who clocked out at 17:00 gets their record that evening. That wait is deliberate: importing at lunchtime would use up the morning clock-in, and the evening clock-out would then have no shift left to join.
Running it
- On demand — Sync Center, tick Attendance import, start the sync. You need the "Import punches into ERPat attendance" permission for the option to be usable.
- Automatically — turn on "Import automatically after each sync" and the scheduled job does it every fifteen minutes.
Reading the Imported column
Attendance Transactions gains an Imported column and matching filter, so you can always see what happened to any punch.
| Shows | Means |
|---|---|
| Imported | It became part of an attendance record. Hover for the record number. |
| Awaiting | Bound and eligible, not yet processed — usually a shift that is still open. |
| Only one punch | The shift has no clock-out. Skipped unless the opt-in setting is on. |
| Date locked | That day is closed for attendance edits. |
| Overlaps an existing record | An attendance record already covers those hours. |
| Arrived after import | The shift reaches across two records, belongs to a different employee after a re-binding, or the record holds punches outside this shift. Merging or moving records is a manual decision — the sync console says which case it is. |
| Record already decided | The record is approved, rejected, or was auto-closed by ERPat. It is never rewritten. |
| Record edited by hand | Somebody changed the record's times. The correction stands; the punch is left for review. |
| Employee inactive | The bound ERPat employee is deleted or deactivated. |
| Shift over 24 hours | Almost always a wrong device clock or a missed clock-out. |
| Repeat tap | A duplicate of the tap beside it; folded into the same record. A reader firing twice within seconds. |
| Double tap | A repeat badge minutes later — on the clock in, a break, or the clock out. Folded into the same record by the double-tap auto-fix in Settings → Attendance Import. |
| Attendance deleted | Somebody deleted the record it belonged to. Not recreated unless you retry. |
| — | Not bound to an ERPat employee yet, so nothing can import it. |
When a punch arrives late
A terminal that was offline uploads its punches when it reconnects, so a punch can turn up after its shift has already become a record. Biotime corrects the record in place: the clock-out moves, a break appears, the note and the punch count are refreshed. Nothing new is created, so the day never ends up with two records.
It only does that while the record is still open for editing. A record is corrected when all of these hold:
- its status is still Pending or incomplete — an approved, rejected or auto-closed record is somebody's decision and is left exactly as it is;
- it still belongs to the same employee — a re-binding does not let one person's punches rewrite another's record;
- nobody has edited its times — if a person corrected the record, their correction is the truth and the punch is flagged instead;
- the day is not locked, and the new span does not collide with another record.
Corrections wait for the shift gap just as new records do, so a device uploading a whole day at once produces one correction rather than one per punch.
The record's own history
Open any imported record in Attendance → Log Details and its history table shows "Attendance added from BioTime", and "Attendance updated from BioTime" for each correction, with the values before and after. That is the same history HR-created records have, so an approver can see the provenance of a record without leaving the screen they approve it on.
Use Retry skipped punches in the Sync Center after fixing the cause — a date you have unlocked, or an overlapping record you have removed. Scheduled syncs never retry, so a punch the importer refused is not re-attempted every fifteen minutes.
When a sync goes wrong
| Run status | Meaning | Action |
|---|---|---|
| success | Completed everything in scope. | None. |
| partial | Stopped early. The cursor is preserved. | Check the error code; the next run continues rather than restarting. |
| failed | Could not proceed. | Check API Logs and the connection status. |
| cancelled | Stopped by an operator. | None. |
| running | In progress. | Wait. A run whose heartbeat stops is taken over automatically. |
A partial run is usually not a problem: the most common cause is the BioTime server rate-limiting us, and the next scheduled run simply picks up where this one stopped. Repeated partials with the same error are worth investigating — see Troubleshooting.
Checking devices
Devices lists every terminal with its state, its last activity and how many punches it has captured. A terminal that has not reported for longer than usual is worth raising with whoever maintains it — punches from an offline device are not being collected by anybody, and Biotime can only mirror what the server has. Use the row's Remarks note to record what you know about a terminal ("lobby unit, replacement ordered") — the note stays put through every sync.
Leaving remarks on a row
Every mirrored listing — Departments, Positions, Areas, Locations, Devices and Employees & Bindings — has a Remarks column: a free-form note your team leaves on a row to tag or explain it. The listing shows a short preview; hover it (or focus it with the keyboard) to read the whole note, or open the row's note button to read it in full.
Three things to know. First, remarks are yours, not BioTime's: they are stored in ERPat only, never sent to the server, and never changed by a sync — a note survives every mirror refresh and every re-binding. Second, editing a note does not move the row's "Last synced" time; that column still means what it says. Third, anyone who can see a page can read its remarks, but writing one needs the separate Add / edit remarks permission — without it the note button opens read-only. Basic formatting (bold, lists, links) is kept; images and tables are removed on save, and every change is recorded in the audit log.