Biotime Overview Public

Biotime

What the ERPat Biotime module does: mirrors a ZKTeco BioTime or ZKBio TimeCloud attendance server into ERPat, matches every BioTime employee code to a real employee record, and turns the punches into ERPat attendance records for HR to approve.

Guide version: r2 Module version: 1.4.0 Updated: 2026-09-02 Estimated time: 4 min 7 views 0% helpful

Biotime

See your ZKTeco BioTime attendance server inside ERPat — every employee, punch and device, matched to the right person on your payroll, and turned into attendance records your HR team can review.

10 pages 13 mirror tables 9 binding states Attendance import

What this module does

Biotime connects ERPat to your existing ZKTeco BioTime / ZKBio TimeCloud attendance server and keeps a local copy of what it holds: personnel, attendance punches, biometric terminals, the organization tree, and people who have left.

The point of the copy is not storage — it is attribution. Biotime matches each BioTime employee code to an ERPat employee record, so a punch stops being “employee 10231 at Gate 1” and becomes a named person your HR team already knows.

From there it can take the last step: grouping each person’s day into a shift and writing it as an ERPat attendance record, ready for HR to review and approve. That part is switched off until an administrator turns it on.

ERPat never writes anything back to your BioTime server. Data flows one way. The only records Biotime creates are ERPat attendance records, and only once an administrator enables that — they arrive as Pending for a person to approve, never straight into payroll.

The problem it solves

Most organizations running biometric attendance end up with two disconnected systems: the device software knows who tapped and when, and the HR system knows who people actually are. Reconciling them is manual, error-prone, and usually happens once a payroll period under time pressure.

Biotime removes that gap. It pulls the attendance data in automatically, matches it to your employee records, and shows you exactly which people it could not match — and why — so the exceptions are a short reviewed list instead of a spreadsheet nobody trusts.

What it will not guess

ERPat does not enforce unique employee ID numbers, and duplicates genuinely exist in real data. Where two employees share the ID number a BioTime record points at, Biotime records a conflict and resolves nobody. Binding the wrong person’s attendance is worse than binding none — a conflict is a five-second decision for a human, while a silent mis-bind is invisible until payroll is wrong.

Who it is for

HR administrators

Confirm every biometric record belongs to a real, current employee.

Payroll officers

Get attendance data attributable to named people before a cutoff.

IT administrators

Own the BioTime server connection, its credentials and its sync schedule.

Operations managers

Check that terminals are online and actually reporting punches.

Biotime is a staff-side module. There is no employee self-service view in this version.

Where to go next

Getting started

Add a connection, pass the nine-step test, run a first sync, accept the safe matches.

Day-to-day operations

Reading the dashboard, running syncs, reviewing bindings, resolving conflicts.

Administration

Permissions, every setting and its default, scheduled jobs, retention, security.

Reference

Tables, binding states, punch codes, error codes, menu map and the API.

Research & evidence

What was tested against a live server, and what is documented but unverified.

Troubleshooting & FAQ

What each failed check means, and why a punch might show an unexpected day.

The ten screens

PageWhat it is for
DashboardCoverage, punch volume, binding health, device status and the last sync, at a glance.
Employees & BindingsMirrored BioTime personnel and which ERPat employee each maps to, with a per-row Remarks note for your own annotations.
Attendance TransactionsEvery mirrored punch, with local and UTC times, device, verification method, and whether it became an ERPat attendance record.
DevicesTerminals reporting to the server, their state and last activity, with a per-row Remarks note.
OrganizationMirrored departments, positions, areas and locations, each with a per-row Remarks note.
Sync CenterRun a sync, watch it live, and review previous runs.
AnalyticsPunch trends, busiest devices and per-state breakdowns.
API LogsEvery call ERPat made to your server, with HTTP and vendor codes.
SettingsConnections, the connection test, sync windows, binding rules, retention.
Was this guide helpful?

Report a content problem