Understanding the Architecture

A physical event becomes a business record

Dari kejadian fisik menjadi catatan bisnis

Modern attendance systems are more than standalone devices used to record employee check-in and check-out times. A Dahua attendance terminal can become part of a larger business system where device events are collected, processed, validated, and eventually synchronized with Odoo.

Sistem kehadiran modern lebih dari perangkat mandiri untuk mencatat jam masuk dan keluar karyawan. Terminal Dahua dapat menjadi bagian dari sistem bisnis yang lebih luas: event dikumpulkan, diproses, divalidasi, lalu disinkronkan dengan Odoo.

In this series, we will build that integration one layer at a time. The objective is an integration that is understandable, maintainable, and designed for production operation.

Dalam seri ini, kita akan membangun integrasi selapis demi selapis. Tujuannya adalah integrasi yang mudah dipahami, mudah dirawat, dan dirancang untuk operasional produksi.

1. The Dahua attendance device

1. Perangkat kehadiran Dahua

The process begins with the physical terminal. Depending on its model and configuration, a device may identify employees using face recognition, fingerprints, RFID/access cards, a PIN or password, or a combination of methods.

Proses dimulai dari terminal fisik. Bergantung pada model dan konfigurasi, perangkat dapat mengenali karyawan melalui pengenalan wajah, sidik jari, kartu RFID/akses, PIN atau kata sandi, maupun kombinasi metode tersebut.

An attendance event may include a user ID, device ID, date, time, verification method, and event type. The example below is illustrative, not a vendor payload specification. A successful access event must still be interpreted under your attendance rules.

Event kehadiran dapat memuat ID pengguna, ID perangkat, tanggal, waktu, metode verifikasi, dan jenis event. Contoh berikut bersifat ilustratif, bukan spesifikasi payload vendor. Event akses yang berhasil tetap perlu ditafsirkan sesuai aturan kehadiran Anda.

User ID

10025

Date

2026-09-14

Time

07:52:31

Method

Face

Device

Main Entrance

At this stage, the information belongs to the device environment. Odoo does not yet know that the event exists.

Pada tahap ini, informasi berada di lingkungan perangkat. Odoo belum mengetahui keberadaan event tersebut.

2. Attendance logs

2. Log kehadiran

Devices generate events as employees use them. Collect the raw attendance logs before translating those events into ERP records. This separation matters when a device loses its connection, Odoo restarts, PostgreSQL is under maintenance, or the same event arrives more than once.

Perangkat menghasilkan event saat digunakan karyawan. Kumpulkan log kehadiran mentah sebelum menerjemahkannya menjadi catatan ERP. Pemisahan ini penting saat koneksi perangkat terputus, Odoo dimulai ulang, PostgreSQL menjalani pemeliharaan, atau event yang sama diterima lebih dari sekali.

For each event, ask: has it already been imported? Which Odoo employee owns this device user ID? Is the timestamp valid, and which device produced it? Has synchronization completed, and what happens if Odoo is unavailable?

Untuk setiap event, periksa: apakah sudah diimpor? Karyawan Odoo mana yang sesuai dengan ID pengguna perangkat? Apakah waktunya valid, dan perangkat mana yang menghasilkannya? Apakah sinkronisasi sudah selesai, dan apa yang terjadi jika Odoo tidak tersedia?

3. The integration layer

3. Lapisan integrasi

The integration layer bridges the physical attendance system and Odoo. Its responsibility is not only to move data, but to control how that data enters the ERP.

Lapisan integrasi menjembatani sistem kehadiran fisik dan Odoo. Tugasnya bukan sekadar memindahkan data, tetapi mengendalikan bagaimana data masuk ke ERP.

Keep the original payload and record validation errors so malformed events remain diagnosable. Normalize timestamps with the device timezone, use a stable event reference where available, and hold unknown users for review. A repeated delivery should not create a second attendance record.

Simpan payload asli dan catat kesalahan validasi agar event bermasalah tetap dapat ditelusuri. Normalisasikan waktu sesuai zona waktu perangkat, gunakan referensi event yang stabil jika tersedia, dan tahan pengguna yang belum dipetakan untuk ditinjau. Pengiriman ulang tidak boleh membuat catatan kehadiran kedua.

4. Why use PostgreSQL as an intermediate layer?

4. Mengapa memakai PostgreSQL sebagai lapisan perantara?

Odoo already uses PostgreSQL internally. An attendance staging layer serves a different purpose: the device produces raw events, while Odoo manages business records. Keep those responsibilities separate.

Odoo sudah memakai PostgreSQL secara internal. Lapisan staging kehadiran memiliki tujuan berbeda: perangkat menghasilkan event mentah, sedangkan Odoo mengelola catatan bisnis. Pisahkan tanggung jawab tersebut.

TraceabilityKetertelusuran

Retain the original event after processing.Simpan event asli setelah pemrosesan.

TroubleshootingPenelusuran masalah

Locate failures at collection, mapping, or synchronization.Temukan kegagalan pada pengumpulan, pemetaan, atau sinkronisasi.

Duplicate controlKontrol duplikasi

Track a unique reference and processing state.Lacak referensi unik dan status pemrosesan.

RecoveryPemulihan

Keep pending events until Odoo is available again.Simpan event tertunda hingga Odoo tersedia kembali.

AuditabilityAudit

Compare the device event with the resulting attendance record.Bandingkan event perangkat dengan catatan kehadiran hasilnya.

The staging store may use a separate database or custom integration models managed by Odoo, depending on the implementation. It is not a requirement to run another PostgreSQL server. Synchronize business records through Odoo application logic; direct SQL writes to attendance tables bypass that logic.

Staging dapat memakai database terpisah atau model integrasi kustom yang dikelola Odoo, bergantung pada implementasinya. Tidak selalu diperlukan server PostgreSQL tambahan. Sinkronkan catatan bisnis melalui logika aplikasi Odoo; penulisan SQL langsung ke tabel kehadiran melewati logika tersebut.

5. Odoo 19 as the business layer

5. Odoo 19 sebagai lapisan bisnis

Once data is validated, the integration maps the device user to an Odoo employee and processes eligible events in the Attendances application. User 10025 on a terminal is not automatically employee record 10025 in Odoo.

Setelah data divalidasi, integrasi memetakan pengguna perangkat ke karyawan Odoo dan memproses event yang memenuhi syarat di aplikasi Attendances. Pengguna 10025 pada terminal tidak otomatis menjadi record karyawan 10025 di Odoo.

Define how check-in and check-out events form valid attendance intervals. Missing punches, overnight shifts, out-of-order events, and repeated scans need explicit rules or human review. A raw event is not necessarily a complete attendance record.

Tentukan bagaimana event masuk dan keluar membentuk interval kehadiran yang valid. Pencatatan yang hilang, shift lintas hari, urutan event yang tidak sesuai, dan pemindaian berulang memerlukan aturan jelas atau peninjauan manual. Satu event mentah belum tentu menjadi satu catatan kehadiran lengkap.

6. Import and synchronization are different processes

6. Impor dan sinkronisasi adalah proses berbeda

Separate collecting device logs from creating Odoo attendance records. Each stage has its own checkpoint and can be inspected independently.

Pisahkan pengumpulan log perangkat dari pembuatan catatan kehadiran Odoo. Setiap tahap memiliki checkpoint sendiri dan dapat diperiksa secara independen.

When a record is missing, first ask whether the event arrived from the device. If it did, inspect why it has not synchronized. This turns an opaque pipeline into two observable processes.

Saat catatan tidak muncul, periksa dahulu apakah event sudah diterima dari perangkat. Jika sudah, telusuri mengapa belum tersinkron. Dengan begitu, alur yang sulit ditelusuri menjadi dua proses yang dapat diamati.

7. Automation

7. Otomatisasi

Administrators should not need to import and synchronize records manually throughout the day. A custom integration can automate these jobs separately, for example with scheduled actions named:

Administrator tidak perlu mengimpor dan menyinkronkan catatan secara manual sepanjang hari. Integrasi kustom dapat mengotomatiskan kedua pekerjaan secara terpisah, misalnya melalui scheduled action bernama:

• Dahua Attendance: Import device logs
• Dahua Attendance: Synchronize attendances

The first job collects new events into attendance history. The second validates eligible events and synchronizes them with Odoo. These are proposed custom job names, not standard Odoo features. Set intervals according to device capabilities and operational needs.

Pekerjaan pertama mengumpulkan event baru ke riwayat kehadiran. Pekerjaan kedua memvalidasi event yang memenuhi syarat dan menyinkronkannya dengan Odoo. Nama tersebut merupakan usulan pekerjaan kustom, bukan fitur standar Odoo. Atur interval sesuai kemampuan perangkat dan kebutuhan operasional.

Record each run, its progress, and any errors. Advance collection checkpoints only after events are safely retained, and make retries safe if a job stops after Odoo has accepted a record.

Catat setiap eksekusi, progres, dan kesalahannya. Majukan checkpoint pengumpulan hanya setelah event tersimpan dengan aman, dan pastikan percobaan ulang aman jika pekerjaan terhenti setelah Odoo menerima catatan.

8. Designing for failure

8. Merancang untuk menghadapi kegagalan

Assume individual components will occasionally become unavailable. Retain events, expose processing states, log errors, and retry when appropriate. Recovery also depends on device retention capacity and a tested backup strategy.

Anggap komponen sesekali tidak tersedia. Simpan event, tampilkan status pemrosesan, catat kesalahan, dan ulangi bila sesuai. Pemulihan juga bergantung pada kapasitas retensi perangkat dan strategi backup yang telah diuji.

Device offlinePerangkat offline

Resume collection when connectivity returns, within device retention limits.Lanjutkan pengumpulan setelah koneksi pulih, dalam batas retensi perangkat.

Odoo restartingOdoo dimulai ulang

Retain pending events and retry synchronization.Simpan event tertunda dan ulangi sinkronisasi.

Staging unavailableStaging tidak tersedia

Do not acknowledge unpersisted events; retry collection.Jangan mengakui event yang belum tersimpan; ulangi pengumpulan.

Missing employee mappingPemetaan karyawan belum ada

Hold the event for review and map the user.Tahan event untuk ditinjau dan petakan pengguna.

Duplicate eventEvent duplikat

Recognize the existing event and avoid a second write.Kenali event yang sudah ada dan hindari penulisan kedua.

Invalid timestampWaktu tidak valid

Retain the original value and flag it for correction.Simpan nilai asli dan tandai untuk diperbaiki.

9. The architecture we will build

9. Arsitektur yang akan kita bangun

Each layer has a clear responsibility, making the solution easier to understand, test, troubleshoot, and extend. The complete path starts with the employee and ends with an Odoo business record.

Setiap lapisan memiliki tanggung jawab yang jelas sehingga solusi lebih mudah dipahami, diuji, ditelusuri, dan dikembangkan. Alur lengkap dimulai dari karyawan dan berakhir pada catatan bisnis Odoo.

The integration reads pending staging records and submits them through Odoo’s application layer. The arrows describe the processing order, not a direct database-to-database connection.

Integrasi membaca catatan staging yang tertunda dan mengirimkannya melalui lapisan aplikasi Odoo. Panah menunjukkan urutan pemrosesan, bukan koneksi langsung antar-database.

What’s next?

Selanjutnya?

Part 2 — Dahua Attendance Device & Network Setup will cover device addressing, server-to-terminal communication, model-specific ports and services, connectivity checks from Ubuntu, and preparing the environment before log collection.

Part 2 — Dahua Attendance Device & Network Setup akan membahas alamat jaringan perangkat, komunikasi server dengan terminal, port dan layanan sesuai model, pengujian koneksi dari Ubuntu, serta persiapan lingkungan sebelum pengumpulan log.

From there, we will continue toward PostgreSQL, attendance log processing, and Odoo 19 synchronization. Build dependable systems, one layer at a time.

Setelah itu, kita akan melanjutkan ke PostgreSQL, pemrosesan log kehadiran, dan sinkronisasi Odoo 19. Bangun sistem yang andal, selapis demi selapis.

Further readingBacaan lanjutan

• Odoo 19 documentation — Attendances
• Dahua ASA1222G / ASA1222G-D — User manual
• Dahua ASA4214F / ASA6214F — User manual