Lewati ke konten
Booku — Dokumentasi Dokumentasi Booku

Keunggulan Booku: Buku Pengawasan Turunan Gaji

Tier 3 — keunggulan-keunggulan Booku yang muncul saat user memakai menu Buku Pengawasan Turunan Gaji (4 varian: BPJS Kesehatan, BPJS Ketenagakerjaan, Koperasi Karyawan, Serikat Pekerja).

📘 Deskripsi user-friendly: deskripsi/buku-pengawasan-turunan-gaji.md

Deskripsi Singkat Menu

Buku Pengawasan Turunan Gaji adalah 4 halaman buku pengawasan untuk hutang yang muncul dari potongan gaji karyawan:

  • BPJS Kesehatan — iuran BPJS Kesehatan (porsi karyawan + perusahaan)
  • BPJS Ketenagakerjaan — iuran BPJS TK (JHT, JP, JKK, JKM)
  • Koperasi Karyawan — simpanan/angsuran koperasi
  • Serikat Pekerja — iuran serikat

Setiap bulan, sistem mencatat potongan dari gaji (tbl_pengawasangaji) lalu user input nilai tagihan ke pihak ketiga. Booku memastikan tagihan sinkron dengan potongan, dan pembayaran ke pihak ketiga tercatat per bulan dengan lookup multi-tahun.

Daftar Keunggulan di Menu Ini

#KeunggulanTier 2 Terkait
1Cek Selisih Realtime (Tagihan vs Potongan Gaji)#01
2Adjustment Selisih dengan Jurnal Otomatis#02, #11
3Validasi Block Pembayaran Saat Ada Selisih#01
4Telusur Pembayaran Multi-Tahun Otomatis#02
5UI Cerdas Per Konteks (LAMPAU vs NORMAL, tahun aktif vs closed)#08, #10
6Konsep Buku Pengawasan untuk Pembayaran Per Bulan#13

Detail per Keunggulan

1. Cek Selisih Realtime (Tagihan vs Potongan Gaji)

Apa yang dirasakan user: Saat membuka menu, setiap baris bulan menampilkan kolom Selisih Tagihan dan Selisih yang dihitung otomatis — Jumlah Tagihan (yang dibayar ke pihak ketiga) dikurangi Jumlah Potongan (yang dipotong dari gaji karyawan). Jika selisih ≠ 0, seluruh baris berubah warna oranye sebagai peringatan visual.

Mengapa penting:

  • Potongan dari gaji harus = tagihan ke pihak ketiga. Selisih biasanya muncul karena: pembulatan iuran, perubahan tarif BPJS, koreksi kepesertaan, atau salah input.
  • Tanpa kontrol ini, perusahaan bisa kurang/lebih bayar ke BPJS / koperasi / serikat tanpa sadar.

Bagaimana Booku Melakukannya:

  • Jumlah Potongan di-agregasi otomatis dari tbl_pengawasangaji (kolom potongan sesuai jenis turunan, di-SUM lintas baris per bulan)
  • Pewarnaan baris cell-level (bukan row-level) supaya warna oranye benar-benar muncul mengalahkan CSS default antd
  • Total di baris JUMLAH paling bawah juga ikut menampilkan total selisih — user langsung tahu apakah ada bulan yang bermasalah

→ Cross-link: #01 Realtime Accuracy

2. Adjustment Selisih dengan Jurnal Otomatis

Apa yang dirasakan user: Kalau ada selisih, klik kanan baris bulan → Adjustment Selisih → modal muncul dengan preview jurnal yang akan dibuat (Debet/Kredit COA + nominal sudah ditentukan otomatis). User cukup pilih tanggal jurnal & klik Simpan — jurnal koreksi tersimpan, dan kolom Koreksi Selisih di tabel otomatis ter-update sehingga Selisih jadi 0.

Mengapa penting:

  • User tidak perlu tahu COA mana yang harus di-Debet/Kredit
  • Tidak perlu input jurnal manual yang rawan typo
  • Koreksi di tabel turunan + jurnal di Buku Besar selalu sinkron (atomic save)

Bagaimana Booku Melakukannya:

  • Algoritma COA mirror Booku Lama:
    • Selisih > 0 → Debet Hutang Lancar Lainnya, Kredit COA Hutang varian
    • Selisih < 0 → kebalikan
  • Save jurnal + update Koreksi_Selisih dalam satu transaksi database (AddLinesToContextAsync + SaveChangesAsync) — kalau gagal, rollback otomatis
  • Lawan Transaksi otomatis: konstanta Internal (INT / Internal) — sesuai konvensi jurnal otomatis V2 untuk reklasifikasi antar COA hutang
  • Validasi: tanggal jurnal wajib di Tahun Buku Aktif (defense-in-depth di FE + BE)

→ Cross-link: #02 Automatic Everything, #11 Jurnal Multi-line

3. Validasi Block Pembayaran Saat Ada Selisih

Apa yang dirasakan user: Klik kanan baris bulan → Bayar. Kalau bulan tersebut masih ada selisih (Selisih ≠ 0), Booku memblok flow dengan peringatan jelas: “Tidak dapat melakukan pembayaran karena masih ada selisih sebesar Rp X. Selesaikan selisih terlebih dahulu (lakukan Adjustment Selisih atau koreksi data di Buku Pengawasan Gaji).”

Mengapa penting:

  • Mencegah jurnal pembayaran yang tidak konsisten dengan posisi hutang di Buku Besar (kalau hutang di COA ≠ tagihan di buku pengawasan, jurnal pembayaran bisa bikin saldo COA jadi minus atau timpang)
  • Memaksa user menyadari selisih sebelum bayar — bukan menyembunyikan masalah
  • Berbeda dengan Booku Lama yang langsung trigger Adjustment otomatis sebagai jalan keluar — V2 sengaja eksplisit, paksa user pakai tombol Adjustment Selisih secara sadar

Bagaimana Booku Melakukannya:

  • Validasi Selisih = 0 di handler tombol Bayar (frontend) — return + warning kalau tidak lulus
  • Validasi HANYA aktif di Tahun Buku NORMAL — di LAMPAU validasi di-skip (konsisten dengan rule kolom Selisih hidden di LAMPAU; mirror Booku Lama yang sidebar pembayaran-nya juga absent di LAMPAU)

→ Cross-link: #01 Realtime Accuracy

4. Telusur Pembayaran Multi-Tahun Otomatis

Apa yang dirasakan user: Kalau perusahaan telat bayar BPJS dari tahun lalu (misalnya tagihan Desember 2022 dibayar di Januari 2024), pembayaran tersebut tetap tercatat dengan benar di baris tagihan Desember 2022. Saat user membuka filter Tahun 2022, kolom Jumlah Pembayaran & Sisa Pembayaran sudah memperhitungkan pembayaran yang terjadi di 2023, 2024, dst.

Mengapa penting:

  • Pembayaran tagihan lama lintas tahun adalah skenario nyata (perusahaan sering telat bayar BPJS karena cashflow, dispute, dll.)
  • Tanpa lookup lintas DB, kolom Sisa Pembayaran tahun lama tetap nampak utuh meskipun sebenarnya sudah dilunasi di tahun berikutnya — bikin laporan keuangan menyesatkan

Bagaimana Booku Melakukannya:

  • Booku V2 punya 1 database transaksi per tahun (bookuid_booku_{tenant}_{tahun}). Pembayaran di-SUM lintas database via loop tahun-tahun.
  • TahunCutOff (tahun pertama register) ditangani khusus karena bisa menampung data backfill LAMPAU multi-tahun
  • Pola di-share dengan modul Hutang Pajak (cross-year payment lookup)

→ Cross-link: #02 Automatic Everything

5. UI Cerdas Per Konteks (LAMPAU vs NORMAL, Tahun Aktif vs Closed)

Apa yang dirasakan user: Tampilan menu otomatis menyesuaikan dengan konteks tahun buku:

KonteksYang Berubah
Tahun Buku LAMPAU (input data awal)Kolom Potongan/Selisih/Koreksi sembunyi; menu Bayar/Detail/Adjustment sembunyi; field Jumlah Potongan di form Input juga sembunyi; tombol [+]/[-] muncul untuk input data multi-tahun; pewarnaan baris non-aktif
Tahun Buku NORMAL, tahun aktifSemua kolom & menu visible; pewarnaan aktif; Adjustment & Bayar available
Tahun Buku NORMAL, telusur tahun lampau (closed)Kolom Potongan/Selisih/Koreksi sembunyi (karena potongan tidak relevan untuk tahun closed); menu Input/Edit Tagihan sembunyi (read-only)

Mengapa penting:

  • User tidak dibingungkan oleh kolom/tombol yang tidak applicable di mode aktif
  • Mode LAMPAU = input data historis, jadi tidak perlu lihat kolom yang berurusan dengan jurnal/pembayaran realtime
  • Tahun closed = sudah final, tidak boleh diubah — sehingga tombol Edit/Adjustment otomatis hilang

Bagaimana Booku Melakukannya:

  • Visibility kolom dikendalikan oleh kombinasi JenisTahunBuku === NORMAL && tahunTelusur === TahunBukuAktif
  • Visibility menu aksi di-filter per-baris berdasarkan kondisi data + mode
  • Header SummaryBar label dinamis: “Saldo Awal” (mode aktif) vs “Saldo Akhir” (mode lampau/closed)
  • Label tombol Tagihan dinamis: “Input Tagihan” (jumlahTagihan=0) vs “Edit Tagihan” (jumlahTagihan>0)
  • Judul halaman dinamis: “Buku Pengawasan Hutang …” (Normal) vs “Saldo Akhir Hutang …” (Data Awal saat LAMPAU)

→ Cross-link: #08 Simple for User, #10 UI Dinamis

6. Konsep Buku Pengawasan untuk Pembayaran Per Bulan

Apa yang dirasakan user: Setiap bulan punya Nomor BPH unik (mis. BPHKS-2024-1 untuk Januari 2024 BPJS Kesehatan). Saat klik Bayar, modal Input Pengeluaran Bank-Cash otomatis ter-preset dengan Kategori “Pembayaran Hutang”, Peruntukan sesuai varian (BPJS Kesehatan / dst.), Kode/Nama Lawan Transaksi (BPJS-KS, BPJS-TK, KOPKAR, SP), dan tabel kanan menampilkan 1 baris tagihan otomatis dengan Jumlah Tagihan, Sudah Dibayar, Sisa Tagihan, Jumlah Bayar. User tinggal pilih sarana pembayaran (bank/cash) lalu Simpan — jurnal pembayaran terbentuk otomatis dengan COA yang benar.

Mengapa penting:

  • Pembayaran tagihan tidak perlu input ulang Lawan Transaksi atau Uraian — semua sudah pre-fill dari konteks bulan & jenis turunan
  • Konsep NomorBP = NomorBPH memungkinkan filter pembayaran yang spesifik per bulan & per varian → tracking yang akurat
  • Backend GetOutstandingHutangTurunanGajiAsync parse NomorBP (awalan + tahun + nomor urut), query tagihan + sudah-dibayar, return outstanding ke modal

Bagaimana Booku Melakukannya:

  • Frontend: helper getKodeLawanTransaksiConstant + getNamaLawanTransaksiConstant mapping TurunanGajiType → konstanta Lawan Transaksi Internal (sumber publik @/constants/lawanTransaksiInternal, tidak duplikasi)
  • Backend: switch Peruntukan di BuktiPengeluaranService.GetOutstandingHutangAsync punya case khusus untuk 4 Peruntukan Turunan Gaji
  • Drawer Detail Pembayaran: menampilkan riwayat pembayaran per bulan + tombol Bayar dengan validasi Sisa>0 dan Selisih=0
  • Drawer auto-action: klik menu Bayar dari tabel utama langsung buka drawer + modal pembayaran (tanpa user perlu klik tombol Bayar lagi di dalam drawer) — pattern share dengan modul Hutang/Piutang Karyawan, Pemegang Saham, dll.

→ Cross-link: #13 Buku Pengawasan Penerimaan/Pengeluaran

Catatan Implementasi

Detail teknis lengkap (algoritma, sumber kebenaran Booku Lama, audit bug fixes) ada di:

Terakhir diperbarui: 13-05-2026