Skema Data — Keuangan (UKT, Biaya Flat, Pembayaran, Gaji)¶
Status: DRAFT (13 Juli 2026) — tahap 3 dari desain skema bertahap
Melanjutkan Skema Data — Fondasi dan Skema Data — Akademik Inti. Halaman ini mencakup Modul 5 (Keuangan). Modul HRD, Aset, dan Perpustakaan menyusul di halaman terpisah.
1. Diagram ERD¶
2. Migrasi Tambahan ke Tabel Mahasiswa¶
Satu kolom baru ditambahkan ke Mahasiswa (sudah didefinisikan di
Skema Data — Akademik Inti) — bukan tabel baru, jadi dicatat di
sini sebagai perubahan (migration), bukan pengulangan definisi tabel:
| Kolom baru | Tipe | Keterangan |
|---|---|---|
| kelompok_ukt_id | bigint (FK → KelompokUKT, nullable) | Ditentukan saat PMB dari data ekonomi (Modul 1a) |
3. UKT Berjenjang¶
3.1 KelompokUKT (master, dikonfigurasi per tenant)¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| nama | varchar | mis. "Kelompok 1", "Kelompok 2" |
3.2 TarifUKT (nominal per kelompok, per prodi, per tahun akademik)¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| kelompok_ukt_id | bigint (FK → KelompokUKT) | |
| program_studi_id | bigint (FK → ProgramStudi) | Nominal bisa beda per prodi |
| tahun_akademik_id | bigint (FK → TahunAkademik) | Nominal bisa naik/turun per tahun |
| nominal | decimal |
3.3 TagihanUKT¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| mahasiswa_id | bigint (FK → Mahasiswa) | |
| tahun_akademik_id | bigint (FK → TahunAkademik) | |
| nominal | decimal | Disalin dari TarifUKT saat tagihan dibuat (agar histori tidak berubah bila tarif direvisi belakangan) |
| status | enum(belum_bayar, lunas) | |
| tanggal_jatuh_tempo | date |
4. Biaya Non-UKT (Flat)¶
4.1 JenisBiayaFlat (master, dikonfigurasi per tenant)¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| nama | varchar | mis. "Wisuda", "KKN", "Praktikum" |
| nominal | decimal | Sama untuk semua mahasiswa (flat) |
4.2 TagihanBiayaFlat¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| mahasiswa_id | bigint (FK → Mahasiswa) | |
| jenis_biaya_flat_id | bigint (FK → JenisBiayaFlat) | |
| status | enum(belum_bayar, lunas) | |
| tanggal_jatuh_tempo | date |
5. Pembayaran (Rekonsiliasi Manual)¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| tagihan_ukt_id | bigint (FK → TagihanUKT, nullable) | |
| tagihan_biaya_flat_id | bigint (FK → TagihanBiayaFlat, nullable) | Hanya salah satu dari dua kolom ini terisi |
| nominal_dibayar | decimal | |
| bukti_transfer | varchar, nullable | Path file upload dari mahasiswa |
| status_verifikasi | enum(menunggu, terverifikasi, ditolak) | |
| diverifikasi_oleh_id | bigint (FK → Pegawai, nullable) | Staf Keuangan |
| tanggal_bayar | timestamp | |
| tanggal_verifikasi | timestamp, nullable |
Kenapa dua kolom nullable, bukan satu referensi ke 'Tagihan' generik?
Pola yang sama seperti RiwayatJabatan di Skema Data — Fondasi —
menghindari Generic FK supaya RLS dan integritas referensial tetap terjaga di level database.
Rekonsiliasi manual — bukan integrasi payment gateway
Sesuai keputusan di Cakupan Modul: mahasiswa transfer manual lalu unggah
bukti_transfer, staf Keuangan memverifikasi dan mengubah status_verifikasi. Begitu
terverifikasi, TagihanUKT.status/TagihanBiayaFlat.status diperbarui jadi lunas — yang
lalu dibaca RegistrasiUlang (Akademik Inti) sebagai gerbang KRS.
6. Gaji (Ringkas)¶
Lingkup terbatas di tahap ini
Hanya header slip gaji yang dirancang di sini — rincian komponen gaji yang terhubung ke jabatan akademik/kepegawaian dosen menyusul lebih detail saat desain skema Modul 6 (HRD).
6.1 SlipGaji¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| pegawai_id | bigint (FK → Pegawai) | |
| bulan | smallint | |
| tahun | smallint | |
| total_gaji | decimal | |
| status | enum(draft, final) |
7. Row-Level Security¶
Pola identik dengan halaman sebelumnya — semua tabel di atas memakai tenant_id + kebijakan RLS
yang sama (lihat Skema Data — Fondasi §10).
8. Langkah Berikutnya¶
Skema tabel HRD (data personal pegawai, evaluasi kinerja, BKD detail), Biro Aset, dan Perpustakaan menyusul di halaman terpisah.
Kembali ke Roadmap Implementasi atau Skema Data — Akademik Inti.