| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 1882 |
| Technical Name |
eh_hr_attendance_migrate |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 1882 |
| Technical Name |
eh_hr_attendance_migrate |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Attendance Migration
A one time switching tool for customers leaving an incumbent biometric or punch clock attendance system. Two CSV importers, configurable mapping, dry run before commit, per row error log. Vendor neutral by deliberate design.
Day in the life
Export. Map. Dry run. Commit. Three months of history live in Odoo by smoko.
The implementer exports two CSVs from the previous T&A system: an employees file with names, emails, default analytic, and PINs; an attendance history file with checks in and out plus optional analytic. They open the employee importer wizard, attach the file, set the encoding and delimiter to match, choose match by email, tick dry run. The result log shows 312 would be matched, 4 created, 1 row skipped because the email is missing. They fix the source CSV, untick dry run, run again. Same for attendance history. By 11am the new database knows who is who and what they did last quarter.
Overview
What this module does, in one read.
eh_hr_attendance_migrate ships two transient wizards: an employee master importer and an attendance history importer.
Both run against a CSV of any shape the operator names, against any encoding and delimiter combination. Both support dry run mode that returns a per row preview with no database write. Both return a result log on commit, listing imported, updated, and skipped row counts plus per row error messages. No live connector to the previous system; no per vendor adapter. The previous system is leaving the picture, the file is the contract.
Capabilities
Six things this module gives you, with no padding.
Employee master importer
Matches existing hr.employee rows by name or by work email; creates rows that do not yet exist; sets default analytic, default kiosk site, optional kiosk PIN where the source CSV provides them. The match strategy is selectable on the wizard.
Attendance history importer
Matches employees by name or email; creates hr.attendance rows with check in and check out timestamps. Optional analytic, project, and task per row when the jobcost module is installed.
Dry run mode
Both wizards support dry run, returning a per row preview of what would be created, updated, or skipped. Nothing is written to the database. Untick to commit; the result log distinguishes DRY RUN from COMMITTED.
Per row result log
Every run, dry or live, returns a Text result with imported, updated, and skipped counts and a per row error message for anything that did not land. Fix the source CSV, re run, repeat.
Configurable encoding and delimiter
The wizard lets the operator pick UTF-8 or other common encodings and choose the delimiter. CSVs from any incumbent system that exports tabular data can be processed without a pre conversion step.
Honest about what is not migrated
Face templates from the previous vendor are cryptographically meaningless to face-api.js; re enrolment is required. Consent must be granted at the new system after the employee has read the new privacy notice; we never import "claimed prior consent". This is by design, not by oversight.
Frequently asked questions
Honest answers to the questions a buyer asks.
Can I migrate face templates from the previous vendor?
No. Different recognition models produce incompatible embeddings. A template from the previous vendor is cryptographically meaningless to face-api.js. Re enrolment of every face is required at cutover. Plan a window for it during the switch.
Is there a live API connector?
No. This is a one time switching tool, not a connector. The previous system is leaving the picture. CSV is the contract; the operator runs the export from the previous system, the importer reads the file.
Why not import "claimed prior consent" rows?
Privacy by design. Consent must be granted at the new system after the employee has read the new privacy notice. Importing a tickbox from the previous system bypasses that and creates a defensibility gap. Re consent at cutover.
What if the source CSV has unusual encoding?
The wizard lets the operator pick the encoding. Match the export's encoding (UTF-8, CP1252, and similar common encodings are supported). If the encoding is not in the dropdown, convert the file once via iconv or similar before import.
What if a row fails?
The result log lists the failing row and the reason. Other rows continue, not held back by one bad line. Fix the source CSV, re run, the importer is idempotent on already created rows.
Please log in to comment on this module