Keunggulan: Piutang Karyawan

Tier 3 — Keunggulan-keunggulan Booku yang muncul saat user memakai menu Piutang Karyawan.

Aspek	Keterangan
Nama Menu	Piutang Karyawan
Lokasi (Tahun NORMAL)	Sidebar → Buku Pengawasan → Piutang → Piutang Karyawan
Lokasi (Tahun LAMPAU)	Sidebar → Data Awal → Piutang → Saldo Akhir Piutang Karyawan
Deskripsi User-Facing	`deskripsi/buku-pengawasan/piutang/piutang-karyawan.md`

2. Ringkasan Keunggulan

#	Keunggulan	Tagline Singkat	Tier 2 Terkait
1	Modul khusus untuk pinjaman ke karyawan	Bukan 1 ember “Piutang” generic — pinjaman karyawan punya modul sendiri dengan COA terpisah	#08
2	Form input minimalis — Sarana Pembayaran ditentukan saat Posting	Catatan piutang awal hanya butuh jumlah & karyawan; detail bank di-isi saat pencairan	#08, #10
3	Auto-fetch Jabatan dari Data Karyawan	User cukup pilih kode karyawan — Nama & Jabatan otomatis tertarik	#02
4	Cross-Modul Atomic Posting	Tombol Posting menjurnalkan pencairan via Bukti Pengeluaran dalam single atomic transaction	#01, #02
5	Bar Saldo dengan reconciliation List vs COA realtime	Selisih List dan COA langsung terlihat di atas tabel	#01
6	Dua Mode: Buku Pengawasan & Data Awal	Halaman yang sama dipakai di tahun NORMAL untuk transaksi aktif & tahun LAMPAU untuk input saldo akhir historis	#08

3. Detail per Keunggulan

3.1 Modul Khusus untuk Pinjaman ke Karyawan

Apa: Piutang Karyawan adalah modul terpisah dari Piutang Usaha, Piutang Pihak Ketiga, Piutang Afiliasi, dll. Diperuntukkan khusus untuk pinjaman dana yang perusahaan berikan ke karyawan — kasus tipikal: bantuan kesehatan, cicilan untuk kebutuhan personal, dana darurat keluarga karyawan.

Bagaimana: Modul punya COA Tautan sendiri (Piutang Karyawan = 11508), tabel master sendiri (tbl_pengawasanpiutangkaryawan), dan flow input yang spesifik. Reporting saldo piutang ke karyawan langsung ter-segregasi dari piutang usaha, piutang pihak ketiga, dll. — tanpa filter manual.

📄 Cross-ref: #08 Simple for User

3.2 Form Input Minimalis — Sarana Pembayaran Ditentukan saat Posting

Apa: Form input Piutang Karyawan lebih ringkas dibanding Hutang Karyawan — tidak ada field Sarana Pembayaran, Biaya Administrasi, Ditanggung Oleh, atau Pembebanan saat input awal.

Mengapa: Mengikuti pola sistem internal mode Piutang yang sengaja tidak menampilkan Sarana Pembayaran di form input. Filosofinya: saat mencatat piutang awal (Anda berniat meminjamkan ke karyawan), Anda belum tentu tahu via Bank apa atau Kas mana yang akan dipakai untuk pencairan. Detail bank/cash relevan saat pencairan dana — dan itu dikerjakan via Bukti Pengeluaran saat klik tombol Posting.

Bagaimana: Form input cukup minta: Tanggal Pinjam, Karyawan, Jumlah Pinjaman, (opsional) Nomor Kontrak, Saldo Awal (sama dengan Jumlah Pinjaman), Keterangan. Saat user klik Posting, modal Bukti Pengeluaran muncul untuk memilih Sarana Pembayaran (Bank/Kas) — di sinilah jurnal pencairan ter-generate.

📄 Cross-ref: #08 Simple for User, #10 UI Dinamis Kontekstual

3.3 Auto-Fetch Jabatan dari Data Karyawan

Apa: Saat user input Piutang Karyawan baru, cukup klik picker Karyawan dan pilih dari daftar — Kode Karyawan, Nama Karyawan, dan Jabatan otomatis terisi.

Bagaimana: Form input memanggil KaryawanPickerDialog yang share data master Karyawan. Saat user pilih satu karyawan, 3 field langsung di-populate. Saat mode Edit, Jabatan auto-fetch ulang dari master via karyawanService.getById() — sehingga kalau Jabatan karyawan berubah di master (mis. promosi), info terbaru langsung muncul tanpa user perlu refresh manual.

📄 Cross-ref: #02 Automatic Everything

3.4 Cross-Modul Atomic Posting

Masalah klasik di aplikasi akuntansi: Pencairan piutang melibatkan 2 tabel: tabel master Piutang Karyawan + tabel Bukti Pengeluaran + tabel jurnal. Kalau salah satu gagal disimpan, data jadi inconsistent: master ter-update tapi jurnal hilang (atau sebaliknya).

Solusi Booku: Tombol Posting di context menu Piutang Karyawan men-trigger flow yang menjurnalkan pencairan via Bukti Pengeluaran dalam single atomic transaction. Implementasi:

Interface IPiutangKaryawanPostingOps — share DbContext antar service
Method MarkAsPostedAsync — track perubahan saja, sync COA Sarana yang dipilih user ke master Piutang
BuktiPengeluaranService.CreateAsync — satu-satunya caller yang commit

Hasilnya: master Piutang Karyawan (update NomorJV + COA_Kredit + section Bank) + entry Bukti Pengeluaran + jurnal lines — semua atau tidak sama sekali. Tidak ada partial commit.

📄 Cross-ref: #01 Realtime Accuracy, #02 Automatic Everything

3.5 Bar Saldo dengan Reconciliation List vs COA Realtime

Setiap halaman Piutang Karyawan punya Bar Saldo di atas tabel yang menampilkan:

Angle	Penjelasan
Saldo (List)	Akumulasi saldo dari semua record Piutang Karyawan di tabel
Saldo (COA) + AJP	Saldo COA `Piutang Karyawan` (11508) dari jurnal, ditambah AJP (Adjusment Jurnal Penyesuaian) saat tahun NORMAL
Selisih	`List − (COA + AJP)`, ideal = 0 → warna merah kalau ≠ 0

User langsung lihat apakah catatan individu cocok dengan saldo akuntansi. Kalau selisih ≠ 0: ada record yang belum dijurnal, jurnal manual yang tidak match, atau data master yang terhapus tidak sengaja.

Implementation: helper terpusat _coaService.GetCoaSaldoAsync(KodeTautanCOA_PiutangKaryawan) yang juga dipakai dashboard Validasi Saldo Awal — single source of truth untuk perhitungan saldo COA.

📄 Cross-ref: #01 Realtime Financial Accuracy

3.6 Dua Mode: Buku Pengawasan & Data Awal

Halaman Piutang Karyawan dipakai di 2 lokasi sidebar dengan komponen page yang sama:

Lokasi	Mode	Judul Halaman	Kegunaan
Tahun NORMAL → Buku Pengawasan → Piutang Karyawan	`BukuPengawasan` (default)	“Buku Pengawasan Piutang Karyawan”	Input transaksi aktif tahun ini + Posting jurnal
Tahun LAMPAU → Data Awal → Piutang	`DataAwal`	”Saldo Akhir Piutang Karyawan”	Input saldo akhir historis (menjadi saldo awal tahun NORMAL berikutnya)

Behavior CRUD identik di kedua mode; yang berbeda hanya judul, subtitle, dan tombol Posting (otomatis disembunyikan di LAMPAU karena tidak ada jurnal di tahun LAMPAU).

📄 Cross-ref: #08 Simple for User

4. Nilai Tambah untuk User

“Catat pinjaman ke karyawan dengan modul khusus — form input ringkas tanpa harus tahu detail bank dari awal, auto-fetch jabatan dari Data Karyawan, dan pencairan dana via Posting sekali klik tanpa risiko data setengah jadi.”

Modul Piutang Karyawan menjawab kebutuhan praktis: saat memutuskan memberi pinjaman ke karyawan, biasanya jumlah dan tanggal sudah pasti, tapi via Bank/Kas mana yang akan dipakai sering belum pasti (tergantung saldo bank, ketersediaan cash, dll.). Booku memungkinkan catat dulu komitmen piutang, eksekusi pencairan kemudian via tombol Posting — semua dalam satu flow yang konsisten dengan modul piutang lainnya.

Kombinasi form minimalis + single source of truth (data karyawan) + atomic posting + reconciliation realtime mengurangi friksi input & risiko kesalahan akuntansi dibandingkan tracking manual.

5. Dokumentasi Terkait

Dokumen	Relevansi
Deskripsi: Piutang Karyawan	Panduan operasional user-facing
Keunggulan: Hutang Karyawan	Modul saudara (pinjaman dari karyawan)
Keunggulan: Piutang Pihak Ketiga	Modul sejenis dengan pattern form input minimalis yang sama
Keunggulan: Validasi Saldo Awal	Dashboard reconciliation lintas modul (Piutang Karyawan ter-cover)

Terakhir diperbarui: 08-05-2026