Setup Considerations: attendance devices

What this achieves

Attendance terminals send punches to Humavera directly, so a day’s attendance is built from what people actually did rather than from what they remembered. Planning the rollout before you register the first device saves reconfiguring terminals that are already on a wall.

Decision 1: which punch sources you are actually using

A punch can reach Humavera from more than one place, and a device is only one of them. Decide which sources you want before buying hardware.

Option	Description
A biometric device	A terminal on site sends punches as people use it. Suits sites where people arrive at a fixed point.
Self-service check in and out	People record their own attendance. Suits office and remote work.
A correction request	Somebody asks for a day to be fixed after the fact. This exists regardless of the other sources.

Devices and self-service are not exclusive. A warehouse at HC Corp UK Ltd can use a terminal at the gate while the London office uses self-service, because attendance is reconciled the same way whatever produced the punch.

Decision 2: what the device records about people

This is the decision with consequences beyond the product. A terminal that identifies people by a fingerprint or a face is collecting biometric data about your employees, and what you collect is a configuration choice you are making as their employer.

That choice carries data-protection obligations — what you may collect, what you must tell people, how long you keep it, and what lawful basis you rely on. Humavera does not decide any of that for you, and this documentation is not legal advice. Take the question to whoever advises you on data protection before the first terminal goes live, not after.

A terminal identifying people by a PIN or a card rather than by a biometric is a materially different proposition. If the identification method is negotiable, decide it deliberately.

Decision 3: protocol, and getting the serial right

Each device is registered against a protocol, and the picker names which terminal families each one covers. Match it to the hardware you actually have.

The serial number matters more than it looks. It is how the terminal identifies itself to Humavera, it must be entered exactly as printed on the device, and it cannot be changed after registration because the punches already received are tied to it. Getting it wrong means removing the device and registering it again.

Example: read the serial off the unit itself rather than off the box or the purchase order. A transposed character produces a device that registers cleanly and never delivers a punch.

Decision 4: the timezone limitation

Each device records a timezone, and that field is held for reference. Punch times are currently read as UTC.

The practical instruction follows from that: set your terminals to UTC. A device left on local time produces punches offset by however far its clock sits from UTC, and the offset is silent — the punches arrive, they look plausible, and every one of them is wrong by the same amount.

Example: a terminal at the London site left on British Summer Time records an eight o’clock arrival as nine. Nothing warns you, and the error only surfaces when somebody queries their hours.

Decide this before installation. Changing the clock on a wall-mounted terminal across several sites is a visit to each one.

Decision 5: how tightly to lock each device down

Three controls are set per device, and each one narrows what will be accepted.

Option	Description
Require the ingest token	The device must present a token issued when you registered it. The token is displayed once and cannot be shown again.
Require an API key	The device must present a key as well.
Allowed source IPs	A list of addresses punches will be accepted from. Left empty, punches are accepted from any source address.

These decide whether something other than your terminal can send punches that Humavera will treat as real attendance. A device with no token and no address restriction accepts whatever reaches it.

Decide the level with whoever runs your network, and decide it before registering, because the token is issued at registration and shown only at that moment. Losing it means removing the device and registering it anew.

Decision 6: who holds the PIN list

A terminal identifies each person by a number held on the device, and Humavera shows which of those numbers belongs to which employee. Punches arriving under a number it does not recognise are kept and listed as unrecognised rather than discarded.

Creating those associations is not done from the device screens today. Plan for that: agree who maintains the numbering, keep the list of who holds which number outside the product, and treat a growing queue of unrecognised punches as the signal that somebody has been issued a number nobody recorded.

Example: a new starter at the Manchester site is enrolled on the terminal and given a number. Their punches arrive and sit as unrecognised until the association exists, so the day is not lost — but nobody is credited with it either.

What is expensive to change later

Decision	Cost of changing later
The serial entered at registration	High. It cannot be edited. Remove the device and register it again.
Device clocks set to local time	High. Every terminal needs visiting, and the punches already collected carry the offset.
The identification method a terminal uses	High. It is a hardware and a data-protection decision at once.
The ingest token, once lost	Medium. Remove the device and register it anew to be issued another.
Allowed source addresses	Low. Edit them on the device record.
Location label and name	Low. They are labels for the people reading the list.

What happens next

Register each device, hand its setup details to whoever configures the terminal, and watch the device record for its first punch. Punches feed the same attendance days that self-service check-in produces, so they are reviewed, corrected, and approved through the screens your team already uses.