Skema Data — Biro Aset (Master Aset, Mutasi, Penyusutan, Penghapusan)¶
Status: DRAFT (13 Juli 2026) — tahap 5 dari desain skema bertahap
Melanjutkan Skema Data — Fondasi, Skema Data — Akademik Inti, Skema Data — Keuangan, dan Skema Data — HRD. Halaman ini mencakup Modul 7 (Biro Aset). Modul Perpustakaan menyusul di halaman terpisah — bagian terakhir sebelum uji isolasi tenant.
1. Diagram ERD¶
2. Master Aset¶
2.1 KategoriAset (master, dikonfigurasi per tenant)¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| nama | varchar | mis. "Tanah", "Bangunan", "Kendaraan", "Peralatan", "ATK" |
2.2 Aset¶
Cakupan penuh — termasuk aset kecil (kursi, ATK), bukan hanya aset besar (lihat Cakupan Modul, Modul 7).
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| kategori_aset_id | bigint (FK → KategoriAset) | |
| kode_inventaris | varchar, unique per tenant | |
| nama | varchar | |
| fakultas_id | bigint (FK → Fakultas, nullable) | Unit kerja pemegang saat ini |
| program_studi_id | bigint (FK → ProgramStudi, nullable) | |
| unit_nama | varchar, nullable | Untuk unit pendukung tanpa tabel master sendiri (pola sama seperti RiwayatJabatan) |
| tanggal_perolehan | date | |
| nilai_perolehan | decimal | |
| kondisi | enum(baik, rusak_ringan, rusak_berat) | |
| status | enum(aktif, dihapus) |
3. Mutasi Aset¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| aset_id | bigint (FK → Aset) | |
| unit_kerja_asal | varchar | Snapshot teks, bukan FK — lihat catatan di bawah |
| unit_kerja_tujuan | varchar | Snapshot teks |
| tanggal_mutasi | date | |
| dilakukan_oleh_id | bigint (FK → Pegawai) |
Kenapa snapshot teks, bukan pasangan FK asal/tujuan?
Mutasi adalah log historis — mencatat FK unit kerja asal & tujuan berarti butuh 6 kolom
nullable (fakultas/prodi/unit × 2 arah). Snapshot teks lebih ringkas untuk kebutuhan riwayat,
konsisten dengan pola "salin nilai saat kejadian" yang sudah dipakai di TagihanUKT
(Skema Data — Keuangan).
4. Pemeliharaan Aset¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| aset_id | bigint (FK → Aset) | |
| tanggal | date | |
| jenis_pemeliharaan | varchar | |
| biaya | decimal, nullable | |
| keterangan | text |
5. Penyusutan Aset¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| aset_id | bigint (FK → Aset) | |
| tahun | smallint | |
| nilai_penyusutan | decimal | |
| nilai_buku_akhir | decimal | |
| is_manual | boolean | true bila nilai di-override manual dari hasil hitung otomatis |
Otomatis (garis lurus) dengan opsi adjust manual [DIKONFIRMASI]
Default dihitung otomatis metode garis lurus. Kolom is_manual membedakan baris yang murni
hasil sistem vs yang sudah disesuaikan manual — sama seperti keputusan yang sudah disepakati
di Cakupan Modul, Modul 7.
6. Penghapusan Aset¶
6.1 AmbangApprovalAset (konfigurasi per tenant)¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| nilai_ambang | decimal | Nilai aset di atas ini butuh approval sampai Rektor, bukan cuma Wakil Rektor |
6.2 PenghapusanAset¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| aset_id | bigint (FK → Aset) | |
| alasan | text | |
| status | enum(diajukan, disetujui, ditolak) | |
| diajukan_oleh_id | bigint (FK → Pegawai) | |
| disetujui_oleh_id | bigint (FK → Pegawai, nullable) | Kepala Biro Aset, atau naik ke Rektor sesuai AmbangApprovalAset |
| tanggal_pengajuan | date |
Pengecualian keterlibatan Rektor — satu-satunya di seluruh sistem
Sesuai Cakupan Modul §0.1,
Rektor tidak masuk rantai approval operasional — penghapusan aset di atas
AmbangApprovalAset.nilai_ambang adalah pengecualian resmi karena sifatnya legal/strategis,
bukan operasional harian.
7. Opname Aset (Stock Take)¶
7.1 OpnameAset (header)¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| tanggal_opname | date | |
| dilakukan_oleh_id | bigint (FK → Pegawai) |
7.2 OpnameAsetDetail¶
| Kolom | Tipe | Keterangan |
|---|---|---|
| id | bigint (PK) | |
| tenant_id | UUID (FK → Tenant) | |
| opname_aset_id | bigint (FK → OpnameAset) | |
| aset_id | bigint (FK → Aset) | |
| kondisi_fisik | enum(baik, rusak_ringan, rusak_berat, hilang) | |
| sesuai_catatan | boolean | false memicu tindak lanjut manual (investigasi/penghapusan) |
| catatan | text, nullable |
8. Row-Level Security¶
Pola identik dengan halaman sebelumnya — semua tabel di atas memakai tenant_id + kebijakan RLS
yang sama (lihat Skema Data — Fondasi §10).
9. Langkah Berikutnya¶
Skema tabel Perpustakaan menyusul — bagian terakhir dari desain skema bertahap sebelum uji isolasi tenant (item terakhir di Roadmap §1).
Kembali ke Roadmap Implementasi atau Skema Data — HRD.