Troubleshooting & FAQ
The connection test is designed so the step that fails tells you where the problem is. Start there.
The connection test failed
Checks run in order and stop at the first failure, so the failing step narrows the cause considerably.
| Fails at | What it means | What to do |
|---|---|---|
| Input & URL shape | The address is not a plain server address. | Enter scheme and host only — https://server.example.com. No path, no query, no username embedded in the URL. Put the username in its own field. |
| Host policy & DNS pin | The name did not resolve, or resolved somewhere ERPat is not allowed to reach. | Check the spelling and that ERPat's server can resolve it. For an on-premises BioTime on your LAN, an administrator must set the profile to on-premises and enable Allow private / internal hosts. Loopback and cloud-metadata addresses are refused whatever you do. |
| TLS handshake | The encrypted connection failed — usually a certificate that does not match the name you typed, or has expired. | Use the hostname the certificate is actually issued for. There is deliberately no option to ignore certificate errors. |
| Sign in | The server rejected the username or password. | Re-check both. Note that repeated failures will temporarily lock the connection. |
| Identity & company | Sign-in worked but the session could not read its own account. | Usually a permissions problem on the BioTime account. Ask for an account with normal read access. |
| Employees / Devices | That part of the API is unreachable or restricted for this account. | Confirm the BioTime account may read personnel and device data. |
| Transactions & punch-time filter | Punches could not be read, or the server ignored the date filter. | This one matters: incremental sync depends on that filter. If it fails, raise it with your BioTime provider — a server that ignores date filtering cannot be synced incrementally. |
| Organization | None of departments, positions, areas or locations could be read. | A partial result here is fine and passes — Locations exists only on cloud servers. A total failure points at account permissions. |
Common questions
“The connection says Locked.”
Several sign-in attempts were rejected in a row, so the connection paused itself rather than continuing to hammer your BioTime account — which many servers would respond to by locking the account itself. Wait a few minutes and retry with the correct password.
Network problems and server errors deliberately do not count toward this. Only genuine credential rejections do.
“Why does an employee show Conflict?”
Two or more ERPat employees have the same ID number, and that number is what the BioTime record points at. There is no safe automatic answer, so nothing was bound. Open the row, pick the right person, and save — or fix the duplicate ID number in your employee records, which resolves it permanently.
“A punch shows the wrong day.”
Almost always the connection's timezone. That setting is what tells the BioTime server which zone to render times in; if it is wrong, every timestamp is offset.
If the times look right but the date surprises you, note that the day a punch belongs to follows local time deliberately. For a UTC+8 organization a 01:00 punch belongs to that morning — even though the same instant is still the previous day in UTC. This is intentional: “which day did this person work” is a local question.
“No ERPat attendance record appeared.”
Work down this list — the Imported column on Attendance Transactions tells you which step you are stuck on.
- Is the import switched on? Settings → Attendance Import. It is off by default.
- Is the Human Resource module enabled? Without it there is no Attendance screen for the records to appear in, so the import stays inactive.
- Do you have the permission? "Import punches into ERPat attendance" is separate from "Run a sync".
- Is the employee bound? An unbound punch shows a dash — nothing can import it until it belongs to somebody.
- Is the shift still open? A shift is imported only after the gap (6 hours by default) has passed since its last punch, so today's clock-out normally appears that evening. The column shows Awaiting.
- Was it skipped? The column names the reason — a locked date, an overlapping record, a lone punch, an inactive employee, a shift over 24 hours, or a future timestamp. Fix the cause, then use Retry skipped punches.
“A punch arrived late. Why wasn’t the record updated?”
Biotime corrects a record in place only while it is still open for editing. The Imported column says which condition stopped it:
- Record already decided — it is approved, rejected, or was auto-closed by ERPat. Mark it Pending again if it genuinely needs changing, then retry.
- Record edited by hand — somebody changed its times, and a manual correction always wins. Review the punch yourself.
- Arrived after import — the shift spans two records, or belongs to a different employee after a re-binding, or the record holds punches outside this shift. The sync console says which.
- Awaiting — the shift is not closed yet; a correction waits for the gap to pass, exactly as a new record does.
“Will an import overwrite a note I wrote on a record?”
No. If you rewrite the note — or just add a sentence to the end of the one Biotime wrote — the times may still be corrected, but the note is left exactly as you left it. Where the record came from is recorded in its history instead.
“Where can I see that a record came from BioTime?”
Open it in Attendance → Log Details. The history table shows “Attendance added from BioTime”, plus an entry for each later correction with the values before and after. The record's Remarks also carry the run, the connection and the time the sync ran.
If everything above is clear, check the Sync Center console: the import writes a line per batch saying how many records it created and how many shifts it skipped.
“Two records appeared for one day.”
The person's punches had a gap longer than the shift gap in the middle — a split shift, for instance a morning session and an evening one. Raise New shift after a gap of in Settings if those should count as one shift.
“An imported record has the wrong break times.”
Breaks come from the punches between the first and last of the shift, paired in order. A missed tap shifts the pairing, and the record is flagged accordingly. Edit it in the Attendance screen before approving — that is exactly what Pending status is for.
“I deleted an imported record and it did not come back.”
Deliberate. Its punches are released and marked Attendance deleted, but nothing silently recreates a record a person just removed. Tick Retry skipped punches in the Sync Center if you do want it back.
“The sync says partial.”
It stopped early but kept its place. The commonest cause is the BioTime server rate-limiting us, especially during a large backfill; the next run continues rather than restarting. Check API Logs for the reason. Repeated partials with the same error are worth investigating.
“Nothing has synced for hours.”
Check, in order: the module is still enabled; Run the sync automatically is on; the connection status is Active rather than Error or Locked; and ERPat's cron is running at all (if no scheduled job anywhere is firing, that is an ERPat-wide issue, not a Biotime one).
“Can I see the BioTime password?”
No. It is encrypted at rest and is never displayed again, by design. If it is lost, enter the new one and re-run the connection test.
“We rotated the BioTime password.”
Open Settings → Connection Test, enter the new password and run the test. The new credential is stored only once a real sign-in succeeds.
“Are fingerprints or face data copied into ERPat?”
No. Biometric templates are never mirrored. Only the count of enrollments per device is copied, so you can see that a terminal has enrollments without ERPat holding any biometric data at all.
“Someone left. Why are they still listed?”
Deliberately. A leaver keeps their row under Employees & Bindings and keeps their binding, so every punch they ever made stays attributable to a real person. If the record were removed, all of their historical attendance would render as an unknown employee.
When they disappear from the BioTime server's personnel list, the next full sync marks the mirrored row missing rather than deleting it — that badge is how you tell "no longer on the BioTime server" apart from "never synced".
“Can I undo an automatic match?”
Yes — that is why automatic matches are marked as unconfirmed rather than presented as settled. Open the row and change or clear the binding. Once you set one by hand it becomes authoritative and no later automatic pass will overwrite it.
“The export only has some of the rows.”
The export runs on the server against your current filter, not against the page on screen, and is capped for safety. If you need a very large range, export it in smaller date windows.
Glossary
| Term | Meaning |
|---|---|
| Binding | The link between a BioTime employee and an ERPat employee record. |
| Employee code | The identifier BioTime knows a person by. Biotime matches it against the ERPat ID number. |
| Cursor | How far a sync got for one kind of data, so the next run resumes instead of restarting. |
| Overlap window | The short period each sync re-reads before its last known punch, so a late upload is never missed. |
| Full backfill | A deliberate, long run that reaches back through the server's whole history. |
| Punch state | What kind of tap it was — check in, check out, break, overtime. |
| Verification method | How the person identified themselves — fingerprint, face, card, palm, password. |
| Profile | Which generation of BioTime server this connection talks to: cloud, or on-premises 9.5. |
| Mirror | ERPat's local read-only copy. Changing it never changes your BioTime server. |
Escalating
Before raising an issue, collect: the failing check or the sync run's error code, the time it happened, and the relevant rows from API Logs (which are already redacted — they contain no credentials). Those three usually identify the cause immediately.
Contact the ERPat Team for module problems. For anything the API Logs show as a refusal or an error from the BioTime server itself, your BioTime provider is the right first call.