Biometric Attendance Push Bridge for Odoo

Name: Biometric Attendance Push Bridge for Odoo
Brand: ECOSIRE
SKU: zkteco-push-sdk-api

Recursos Principais

Dedicated push-listener HTTP controller (auth='none', CSRF-exempt route) that accepts device handshake, options exchange, and attendance-log POSTs

biometric.device model tracking serial number, location, per-device timezone, firmware, and a live last-seen heartbeat with a state selection

biometric.punch staging model that stores every raw event with @api.depends resolution to hr.employee via a device-user-ID mapping table

Configurable punch-pairing engine that builds hr.attendance check-in/check-out records (first-in/last-out or strict alternation per shift)

Idempotent writes keyed on device serial + user + timestamp so a re-sent buffer after a network outage never double-counts a shift

Quarantine lane for unmatched, unknown-user, or duplicate punches so bad data never silently corrupts the timesheet

ir.model.access.csv plus record rules scoping devices and punches per company for correct multi-company isolation

ir.cron heartbeat monitor that flags any terminal that stops pushing within a configurable interval

Backend list/form/kanban views (XML for 17.0/18.0, OWL-compatible for 19.0) to register devices and audit the raw punch log

QWeb daily attendance-exception report listing missing check-outs, orphan punches, and out-of-window events

Per-device timezone normalization so punches land at the correct UTC instant regardless of terminal clock settings

Automated action / server action hooks to trigger notifications or downstream syncs when exceptions are detected

Full XML-RPC/JSON-RPC exposure of devices, punches, and resolved attendance for payroll or middleware integration

Optional employee auto-provisioning from pushed user records, mapping device enrollment IDs to hr.employee on first sight

Feito sob encomenda, pronto para você

Sem configuração por conta própria — um app funcional criado, instalado e com suporte da ECOSIRE.

Você faz o pedido

Comece com um preço único de desenvolvimento. Definimos o escopo com você no início.

Nós criamos e instalamos

A ECOSIRE cria, configura e instala no seu Odoo.

No ar + suporte

Você entra no ar em cerca de 2–4 semanas, com um período de suporte pós-lançamento.

Sobre este Produto

Most teams that adopt biometric fingerprint or face terminals for time tracking hit the same wall: the devices happily record punches, but getting that data into Odoo is a manual export-import chore. Odoo's native hr_attendance module is built around kiosk check-in/out and manual entry — it has no listener for the "push" protocol that low-cost biometric terminals use to POST punch events to a server over HTTP. Without a bridge, someone downloads logs to a spreadsheet nightly, reconciles employee IDs by hand, and payroll inherits every typo. That is exactly where Odoo runs out of road: it can store attendance, but it cannot ingest a device push stream on its own.

We build a dedicated HTTP endpoint inside Odoo that speaks the terminal's push dialect. The controller (a subclass of http.Controller with an auth='none', CSRF-exempt route) accepts the device handshake, options exchange, and attendance-log POSTs, parses the raw punch records, and writes them through the ORM. A new biometric.device model (models.Model with fields for serial number, location, timezone, last-seen heartbeat, and a state selection) represents each registered terminal, and a biometric.punch staging model captures every raw event before it is resolved to an hr.employee through a device-user-ID map. Matched punches are paired into hr.attendance check-in/check-out records using configurable pairing logic (first-in/last-out per day, or strict alternation), while unmatched or duplicate events are quarantined for review instead of silently corrupting the timesheet.

Because this is a real module and not a script, it ships with the full Odoo surface: ir.model.access.csv plus record rules so HR sees only their company's devices, backend list/form/kanban views (XML for 17/18, OWL-compatible for 19) to register terminals and browse the raw punch log, a QWeb report for a daily attendance-exception sheet, and an ir.cron heartbeat monitor that flags any device that stops pushing. Everything the endpoint receives is also reachable over Odoo's own XML-RPC/JSON-RPC API, so downstream payroll or middleware can read the same records. We handle multi-company scoping, timezone normalization per device, and idempotent writes so a device that re-sends its buffer after a network outage never double-counts a shift.

Delivery is build-to-order. After a short scoping call we confirm your device push protocol variant, Odoo edition (Community or Enterprise) and version (17.0/18.0/19.0), employee-mapping rules, and multi-company layout, then build against a staging copy of your database, run UAT with your real terminals, and cut over with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); additional device protocol variants, multi-company/multi-timezone rollouts, payroll-system integration, and historical punch-data migration increase the quoted scope.

O que você ganha

Installable Odoo module source code targeting your confirmed edition and version (17.0/18.0/19.0), with a clean __manifest__.py and declared dependencies

Installation and configuration on your staging environment, including device-endpoint wiring and employee-mapping setup

Technical documentation: models, controller routes, security rules, and the push-protocol handling notes

User guide plus a live training session for HR/admin staff on registering devices and resolving attendance exceptions

UAT on a staging copy of your database with your real terminals, plus a documented rollback plan for cutover

Post-go-live support window for defect fixes and configuration adjustments

Git repository handover with full commit history and tagged release

Data-migration pass for historical punch records where in scope

Para quem é isso

HR / Payroll Manager

Runs monthly payroll off attendance data and is tired of reconciling device exports by hand. Needs punches to flow into hr.attendance automatically, with a clear exception report for missing check-outs before payroll close.

Odoo System Administrator

Owns the Odoo instance and its uptime. Needs a maintainable module with proper security rules, a device heartbeat monitor, and idempotent writes — not a fragile cron that scrapes a spreadsheet every night.

Operations Manager (multi-site)

Oversees several branches each with its own terminal and timezone. Needs per-device registration, multi-company scoping, and one consolidated view of who clocked in where, without manual per-site imports.

IT Integrator / Implementation Partner

Delivering an Odoo rollout for a client and needs the biometric layer handled by specialists. Wants clean source, XML-RPC/JSON-RPC access to the records, and a documented handover to fold into the wider project.

Como Biometric Attendance Push Bridge for Odoo se compara

Critério	ECOSIRE	Construção personalizada	Concorrente
Device push ingestion	Purpose-built HTTP listener for your terminals' push protocol	You design and debug the protocol handling from zero	Fixed protocol support; may not match your device model
Employee mapping	Device-user-ID map resolving to hr.employee, with quarantine for unknowns	Build your own mapping and error handling	Basic mapping; exception handling varies
Duplicate / re-send safety	Idempotent writes keyed on serial+user+timestamp	Depends entirely on your implementation	Often not guaranteed
Multi-company & timezone	Record-rule scoping plus per-device timezone normalization	You implement scoping and TZ logic yourself	Frequently single-company / single-TZ assumptions
Version & edition fit	Built and tested for your exact 17/18/19, Community or Enterprise	Your responsibility to target and test	Prebuilt for specific versions; upgrades lag
Exception reporting	QWeb daily exception sheet plus device heartbeat cron	Build reports and monitoring separately	Limited or absent
Support & handover	Training, post-go-live support window, full git repo handover	In-house knowledge only	Vendor support ticket queue
Total cost profile	Fixed quote from an indicative $249 base after scoping	Open-ended developer time and maintenance	Low list price but integration and fit costs hidden

Perguntas frequentes sobre Biometric Attendance Push Bridge for Odoo

How long does delivery take?

This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope. The exact timeline depends on how many device protocol variants, companies, and timezones are in play, plus whether historical data migration is included. We agree the timeline in writing before work starts.

Does this work with my specific biometric terminals?

It targets terminals that use an HTTP push protocol to POST punch events to a server. During the scoping call we confirm the exact protocol variant your devices speak and build the listener to match. If you run mixed models, each additional protocol variant is factored into the quote.

Which Odoo versions and editions are supported?

We build for Odoo 17.0, 18.0, or 19.0, on Community or Enterprise. We confirm your exact version and edition at scoping and build against a matching staging copy, since view syntax (OWL in 19.0) and some HR behaviors differ between releases.

How does pricing and scoping work?

Pricing starts from $249 as an indicative figure for a single-company base scope. It is not a fixed price. After a short scoping call we assess your devices, edition/version, mapping rules, and multi-company needs, then send a fixed written quote for the agreed scope before any work begins.

What about support and updates after go-live?

Every build includes a post-go-live support window for defect fixes and configuration adjustments. Because you receive the full source and git repository, you can also maintain it in-house. We offer ongoing support and version-upgrade work (for example moving from 17.0 to 19.0) as a separate arrangement.

Will re-sent data create duplicate attendance records?

No. Writes are idempotent, keyed on device serial, user, and timestamp, so a terminal that re-sends its buffer after a network outage will not double-count a shift. Unmatched or duplicate events are quarantined for review rather than silently written.

Can we read the attendance data from other systems?

Yes. Devices, raw punches, and resolved hr.attendance records are all standard Odoo models, so they are fully available over Odoo's XML-RPC/JSON-RPC API for payroll systems, BI tools, or custom middleware.