Keunggulan #13: Buku Pengawasan Penerimaan & Pengeluaran Terintegrasi
Tagline: “Satu form, semua jenis pembayaran — satu kali simpan, tiga data terintegrasi”
Ringkasan
Booku memiliki sistem Buku Pengawasan Penerimaan & Pengeluaran yang unik — menggunakan satu form dinamis untuk semua jenis transaksi kas/bank, dengan dua jalur masuk yang fleksibel, dan penyimpanan terintegrasi yang mencatat data pengawasan, bukti transaksi, dan jurnal secara serentak.
Masalah di Aplikasi Lain
Kebanyakan aplikasi akuntansi menggunakan pendekatan modular terpisah:
| Masalah | Dampak |
|---|---|
| Menu terpisah per jenis | 15+ menu berbeda untuk tiap jenis pembayaran/penerimaan |
| Satu jalur masuk | Hanya bisa input dari modul AP/AR, tidak dari buku pengawasan |
| Simpan bertahap | Input bukti → simpan → buka jurnal → input manual → simpan lagi |
| Data tidak sinkron | Resiko data pengawasan dan jurnal tidak cocok |
| Learning curve tinggi | User harus hafal lokasi menu masing-masing jenis transaksi |
Solusi Booku
1. Satu Form Dinamis untuk Semua Jenis Transaksi
┌─────────────────────────────────────────────────────────────────┐│ FORM DINAMIS SINGLE-ENTRY │├─────────────────────────────────────────────────────────────────┤│ ││ Aplikasi Lain: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Menu Pembayaran Hutang Usaha [Form terpisah #1] │ ││ │ Menu Pembayaran Hutang Karyawan [Form terpisah #2] │ ││ │ Menu Pembayaran Hutang Afiliasi [Form terpisah #3] │ ││ │ Menu Pembayaran Hutang Pajak [Form terpisah #4] │ ││ │ Menu Setoran Modal [Form terpisah #5] │ ││ │ Menu Biaya Operasional [Form terpisah #6] │ ││ │ ... dan seterusnya (15+ form) │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Booku: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ SATU FORM: Input Bukti Pengeluaran │ ││ │ │ ││ │ Kategori: [▼ Pembayaran Hutang ] │ ││ │ Peruntukan: [▼ Hutang Usaha ] │ ││ │ ↓ │ ││ │ UI menyesuaikan otomatis! │ ││ │ - Field yang relevan muncul │ ││ │ - Field yang tidak relevan sembunyi │ ││ │ - Validasi sesuai konteks │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ User cukup hafal SATU form, sisanya sistem yang handle! ││ │└─────────────────────────────────────────────────────────────────┘2. Klasifikasi Granular: Kategori + Peruntukan
┌─────────────────────────────────────────────────────────────────┐│ DUA LEVEL KLASIFIKASI │├─────────────────────────────────────────────────────────────────┤│ ││ Level 1: KATEGORI (menentukan arah arus kas) ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Bukti Penerimaan: Bukti Pengeluaran: │ ││ │ • Penerimaan Piutang • Pembayaran Hutang │ ││ │ • Investasi Modal • Pencairan Pinjaman │ ││ │ • Pencairan Pinjaman • Pembelian │ ││ │ • Penerimaan Lainnya • Pengeluaran Lainnya │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Level 2: PERUNTUKAN (menentukan detail akun) ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Kategori "Pembayaran Hutang": │ ││ │ • Hutang Usaha → COA: Hutang Usaha │ ││ │ • Hutang Karyawan → COA: Hutang Karyawan │ ││ │ • Hutang Afiliasi → COA: Hutang Afiliasi │ ││ │ • Hutang Pemegang Saham → COA: Hutang Pemegang Saham │ ││ │ • Hutang Pihak Ketiga → COA: Hutang Pihak Ketiga │ ││ │ • Hutang Bank-Leasing → COA: Hutang Bank-Leasing │ ││ │ • Hutang Pajak → COA: Hutang Pajak │ ││ │ • Deposit Operasional → COA: Deposit Operasional │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Kombinasi Kategori + Peruntukan = Logika Jurnal yang TEPAT ││ │└─────────────────────────────────────────────────────────────────┘3. Dua Jalur Masuk (Dual Entry Point)
┌─────────────────────────────────────────────────────────────────┐│ FLEKSIBILITAS JALUR MASUK │├─────────────────────────────────────────────────────────────────┤│ ││ JALUR 1: Dari Menu Utama ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Menu → Bukti Pengeluaran → Input Baru │ ││ │ │ ││ │ • User pilih Kategori dan Peruntukan manual │ ││ │ • User pilih Lawan Transaksi manual │ ││ │ • Cocok untuk: Transaksi baru tanpa referensi │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ JALUR 2: Dari Buku Pengawasan ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Buku Pengawasan Hutang Usaha → Klik "Bayar" │ ││ │ │ ││ │ • Kategori: Otomatis "Pembayaran Hutang" │ ││ │ • Peruntukan: Otomatis "Hutang Usaha" │ ││ │ • Lawan Transaksi: Otomatis terisi dari buku │ ││ │ • Invoice: Otomatis terisi (jika bayar per invoice) │ ││ │ • Jumlah: Otomatis terisi dari sisa hutang │ ││ │ │ ││ │ Cocok untuk: Pembayaran dari catatan yang sudah ada │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Jalur berbeda, HASIL SAMA — data tersimpan dengan benar! ││ │└─────────────────────────────────────────────────────────────────┘Keuntungan Dual Entry Point:
| Jalur | Cocok Untuk | Efisiensi |
|---|---|---|
| Menu Utama | Transaksi baru, tidak ada referensi sebelumnya | Manual input |
| Buku Pengawasan | Pembayaran/pencairan dari hutang/piutang yang sudah tercatat | Pre-filled, minimal input |
4. Penyimpanan Terintegrasi (3-in-1)
┌─────────────────────────────────────────────────────────────────┐│ SEKALI SIMPAN, TIGA DATA TERINTEGRASI │├─────────────────────────────────────────────────────────────────┤│ ││ Aplikasi Lain: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Step 1: Input bukti pembayaran → Simpan │ ││ │ Step 2: Buka modul jurnal → Input manual │ ││ │ Step 3: Input jurnal → Simpan │ ││ │ Step 4: Update buku pengawasan → Manual/terpisah │ ││ │ │ ││ │ ⚠️ Resiko: Data tidak sinkron jika ada step terlewat │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Booku: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Input Bukti Pengeluaran → Klik SIMPAN │ ││ │ ↓ │ ││ │ ┌──────────────────────────────────────────────────┐ │ ││ │ │ DALAM 1 TRANSACTION (All-or-Nothing): │ │ ││ │ │ │ │ ││ │ │ ✓ Data Bukti Pengeluaran (tbl_pengeluaran) │ │ ││ │ │ ✓ Data Buku Pengawasan (tbl_xxx sesuai jenis) │ │ ││ │ │ ✓ Jurnal Otomatis (tbl_transaksi) │ │ ││ │ │ │ │ ││ │ │ Semua SUKSES atau semua ROLLBACK │ │ ││ │ └──────────────────────────────────────────────────┘ │ ││ │ │ ││ │ ✅ Data PASTI sinkron, tidak mungkin tidak cocok │ ││ └─────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘Data yang Tersimpan Serentak:
| Tabel | Isi | Contoh |
|---|---|---|
tbl_pengeluaran / tbl_penerimaan | Bukti transaksi | Nomor KK, tanggal, jumlah, sarana |
tbl_hutang_usaha (atau tabel pengawasan lain) | Update saldo pengawasan | Status jadi “Dibayar”, sisa hutang berkurang |
tbl_transaksi | Jurnal otomatis | Debet/Kredit sesuai peruntukan |
5. Sistem Approval & Bundel (Pengeluaran)
Catatan: Fitur ini sudah ada di Booku Lama dan akan diterapkan di Booku Baru.
┌─────────────────────────────────────────────────────────────────┐│ SISTEM APPROVAL & BUNDEL │├─────────────────────────────────────────────────────────────────┤│ ││ FLOW TANPA APPROVAL: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Input → Simpan → Langsung Posted (status: Dibayar) │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ FLOW DENGAN APPROVAL: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Step 1: Input Pengajuan │ ││ │ Status: "Open" (belum disetujui) │ ││ │ Jurnal: Belum dibuat │ ││ │ │ ││ │ Step 2: Review oleh Atasan │ ││ │ Bisa: Setujui / Tolak / Edit │ ││ │ │ ││ │ Step 3: Bundel (opsional) │ ││ │ Gabungkan beberapa pengajuan dalam 1 bundel │ ││ │ Untuk efisiensi pembayaran │ ││ │ │ ││ │ Step 4: Cetak & Realisasi │ ││ │ Status: "Dibayar" │ ││ │ Jurnal: Otomatis dibuat saat realisasi │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Fleksibel: Perusahaan bisa pilih pakai approval atau tidak ││ │└─────────────────────────────────────────────────────────────────┘Perbandingan dengan Kompetitor
| Fitur | Accurate | Zahir | Jurnal.id | SAP/Oracle | Booku |
|---|---|---|---|---|---|
| Form Dinamis Single-Entry | ❌ Menu terpisah | ❌ Menu terpisah | ❌ Menu terpisah | ⚠️ Kompleks | ✅ Satu form |
| Dual Entry Point | ❌ | ❌ | ❌ | ⚠️ | ✅ |
| Klasifikasi Granular | ⚠️ 1 level | ⚠️ 1 level | ⚠️ 1 level | ✅ Multi-level | ✅ 2 level |
| Penyimpanan 3-in-1 | ⚠️ Partial | ⚠️ Partial | ⚠️ Partial | ✅ | ✅ |
| Sistem Bundel | ❌ | ❌ | ❌ | ✅ | ✅ |
| Kompleksitas Setup | Rendah | Rendah | Rendah | Tinggi | Rendah |
Value Proposition:
- Booku memberikan fitur level enterprise (SAP/Oracle) dengan kompleksitas level UKM (Accurate/Zahir)
Keunggulan
| Aspek | Aplikasi Lain | Booku |
|---|---|---|
| Jumlah Menu | 15+ menu terpisah | 1 form |
| Learning Curve | Hafal banyak menu | Hafal 1 form |
| Konsistensi Data | Resiko tidak sinkron | Pasti sinkron (transaction) |
| Kecepatan Input | Banyak langkah | Minimal langkah |
| Fleksibilitas Workflow | Satu jalur | Dua jalur |
| Kontrol Approval | Tidak ada / terpisah | Terintegrasi |
Target User
| User Type | Manfaat |
|---|---|
| Staff Akuntan | Efisien setelah terbiasa, workflow fleksibel |
| Owner UKM | Tidak perlu hafal banyak menu, cukup pilih kategori/peruntukan |
| Supervisor | Kontrol approval terintegrasi dalam satu alur |
Catatan Mitigasi
Karena sistem ini memiliki kompleksitas tersembunyi, perlu investasi di onboarding:
| Strategi | Implementasi |
|---|---|
| Guided Tour | Tooltip saat pertama kali buka form |
| Contextual Help | Ikon (?) di dropdown kategori/peruntukan |
| Visual Feedback | Animasi saat field muncul/hilang |
| Default Cerdas | Pre-select kategori/peruntukan yang paling sering |
| Dokumentasi User | Panduan “Kapan pakai kategori/peruntukan apa?” |
UX Refinement Cerdas
Selain prinsip “satu form dinamis”, Bukti Penerimaan/Pengeluaran punya detail-detail UX cerdas yang bekerja di belakang layar — UI selalu serasi dengan konteks transaksi.
1. DJP Override — Section Bank Hide Total
Saat Lawan Transaksi = DJP (Direktorat Jenderal Pajak), seluruh section Bank di-hide — override semua kondisi lain (termasuk saat Sarana Pembayaran = Bank).
Alasan: Pembayaran pajak tidak menggunakan konsep biaya admin, transfer bank, atau rekening penerima dari sisi form ini. Menampilkan section Bank hanya membuat user bingung.
2. Daftar Tagihan Reaktif (0/1/>1 Baris)
Tabel “Daftar Tagihan” (panel kanan) menyesuaikan jumlah data:
| Jumlah Baris | Panel Kanan | Baris TOTAL | Tombol Simpan |
|---|---|---|---|
| 0 | Hide (modal lebih sempit) | — | Disabled + tooltip |
| 1 | Tampil | Hide (redundan) | Enabled |
| >1 | Tampil | Tampil (grand total) | Enabled |
Tidak ada baris TOTAL “palsu” yang isinya sama dengan baris satu-satunya. User tidak bisa simpan form kosong.
3. Sarana Pembayaran Consolidated (4-in-1 Dropdown)
Dropdown Sarana Pembayaran/Pencairan memuat semua jenis akun kas/bank dalam 1 list:
- Petty Cash (1110x)
- Kas (112xx)
- Bank (113xx)
- Cash Advance (1140x)
Plus range “selipan” 11001-11499 untuk custom COA. User tidak perlu pilih sub-kategori dulu — 1 klik dropdown menggantikan 2 langkah.
4. Visibility & State State Reactivity Lain
| Fitur | Perilaku |
|---|---|
| Field Rekening/Atas Nama Penerima | Hide saat LT Internal (8 kode: CUST/INT/DJP/KRY/BPJS-KS/BPJS-TK/KOPKAR/SP) atau Kategori Pemindahbukuan |
| Field Kurs | ReadOnly + auto-fetch dari Master Kurs berdasarkan tanggal & mata uang |
| Field Biaya Admin/Ditanggung Oleh | Reset otomatis ke 0/” saat LT berubah ke DJP |
| Daftar Tagihan | Auto-reset saat modal open atau preset berubah (cegah row tertinggal dari sesi sebelumnya) |
Nilai Jual
“Satu form untuk semua jenis pembayaran dan penerimaan — sistem pintar yang menyesuaikan konteks, bukan user yang harus cari-cari menu.”
“Sekali simpan, tiga data langsung terintegrasi — tidak ada lagi resiko jurnal tidak cocok dengan bukti transaksi.”
“UI yang tidak menampilkan field yang tidak relevan — user fokus pada apa yang penting saat itu.”
Kembali ke: Keunggulan Booku | Detail Menu
Terakhir diperbarui: 21-05-2026 (tambah section “UX Refinement Cerdas” — DJP override, Daftar Tagihan reaktif, Sarana Pembayaran consolidated, visibility/state reactivity)