Integrating biometric attendance devices with Frappe HR

Auto Attendance is only as accurate as the shift assignment behind it. In Frappe HR, the Shift Type defines the start time, end time and the grace and tolerance settings that decide which punches count as on time, late or early. The Shift Assignment then ties that shift to an employee for a date range. Before you trust the output, confirm that every biometric user maps to an employee with a current, submitted Shift Assignment for each working day, and that the Shift Type's Determine Check-in and Check-out setting matches how your staff actually punch. Overnight and rotating patterns are where the window logic is most likely to misfire, so these need explicit test cases rather than a single sample day.

Auto Attendance groups the Employee Checkin records that fall inside each shift window and derives the attendance from the first IN and last OUT punch. Missing punches are the most common exception. If an employee has only an IN, or only an OUT, the record cannot produce a complete day, so decide in advance whether those days are left for manual review or marked from a fallback rule, and confirm how your version of Frappe HR handles a single punch. Multiple punches inside one shift are normal for breaks, and the calculation depends on which punches the shift treats as the boundary. Late corrections need a separate check: a manually added or edited Employee Checkin after the attendance run may not be picked up until the attendance is recalculated, so agree who approves corrections and when the calculation runs before payroll is locked.

Test with your own shift patterns before go-live, not with a generic demo. Build a short list of cases: a standard day shift, a night shift that crosses midnight, a rotating roster, an employee with two punches in one shift, a day with a forgotten punch, and a correction entered two days late. For each case, record the expected attendance status and hours, run Auto Attendance, and compare the result. Confirm these details with your Frappe HR version's documentation, since the exact handling of single punches and overnight windows has changed across releases. Keep the test results with your change records, because a payroll dispute usually starts with a disputed attendance day.

Before any work starts, the client supplies the inputs that decide whether punch logs can be matched to the right people. The most important is an inventory of every biometric or RFID device: vendor, model, firmware version, location, and whether it is cloud-managed or on the local network. Next comes the employee ID mapping, which lists each device user ID alongside the ERPNext Employee record it belongs to, so that the Attendance Device ID field on each Employee is filled from a list someone in HR has checked. Shift schedules should also be provided in writing, including rotations, night shifts that cross midnight and any grace periods, because Auto Attendance depends on them. Finally, the client names an HR data owner, an IT owner for device network access and a sign-off approver, and provides a test environment that is a copy of production or a separate Frappe HR site where test punches can be imported without touching live attendance.

DeployOpen delivers the work in a scope agreed in writing before it begins. In general terms, that means a documented mapping of device users to employees and a record of how unmatched IDs are handled, a tested import or API path that creates Employee Checkin records from the device source, and verification records showing sample punches, the resulting check-ins and the attendance rows they produce. The scope also states which device models and integration routes are covered. Where a device cannot export data in the format the chosen path needs, the scope says so and names the workaround or the device change the client must approve. Each deliverable is tied to a named acceptance check, such as a reconciliation of punch counts for a test period, so the client can judge completion without relying on the implementation team's word.

The handover includes a runbook that the HR and IT owners can use after go-live. It covers how new employees are added to the device and mapped in ERPNext, how a failed import or dropped API call is detected and retried, who reviews unmatched punches, and how device time zones and clock drift are checked. Pricing and duration follow from the written scope, so the client should ask for each device route, the number of devices and sites, and the test cycles to be itemized. Ongoing support for device firmware changes or new hardware is a separate decision, and it can be contracted as a retainer if the client wants DeployOpen to keep the integration working between releases.

The attendance feed needs a named owner after go-live, and that owner should be someone who will check it every working day. Once punches flow into Employee Checkin, the risk moves from installation to drift: imports fail quietly, devices get replaced, clocks wander and new hires appear without a device ID. Name one person in HR operations and one backup in IT. Give them a short written runbook that covers who fixes a failed import, who approves a device swap and who is told when an employee has no mapped Attendance Device ID. Confirm with your partner or Frappe HR documentation which import and sync logs the version you run exposes, so the owner knows where failures show up.

Reconcile Employee Checkin records against the device's own log on a fixed cadence, starting with a sample of several days after go-live and then a regular monthly check before payroll closes. Compare counts per employee and per device, and look for punches that are missing, duplicated or stamped on the wrong date. Time drift is the most common silent fault: a device clock that runs fast or slow shifts punches across shift boundaries, which then affects Auto Attendance. Check device clocks against a trusted time source at a set interval and record each correction. When a device is replaced, keep the old device's last punch timestamp, map the new device to the same location, and confirm that the Attendance Device IDs on employee records still match before the first punch arrives.

Treat the scheduler and background jobs as the first place to look when punches stop appearing, not as an area you can ignore until something breaks. Confirm that the scheduler is running on the site, that the jobs which process imports and attendance are queued and completing, and that failures alert the owner. Ask your partner which of these checks apply to your hosting model, because a Frappe Cloud site and a self-hosted bench expose them differently. Finally, build a joiner step into HR onboarding so every new employee receives an Attendance Device ID before their first shift, and add a leaver step that stops mapping them. Most missed punches in mature deployments trace back to a new hire who was never mapped.