Disposal Asset (PML04)

01Informasi Dokumen

03Quick Overview

Aset gudang yang rusak dan tidak layak dipertahankan dihapus dari daftar aset aktif lewat tiga langkah. Fase 1: admin meninjau riwayat aset (usia, harga perolehan, jumlah perbaikan dan klaim garansi) lalu menyubmit keputusan: alasan, metode (lelang/jual, donasi, pemusnahan), nilai sisa, catatan; aset menjadi menunggu_disposal. Fase 2: disposal fisik terjadi di luar sistem; admin mencatat hasilnya (pembeli dan harga, penerima donasi, atau cara pemusnahan) beserta bukti wajib. Fase 3: admin menekan Selesaikan Disposal; aset menjadi disposed dan tidak muncul lagi di daftar aktif, sementara datanya tetap tersimpan sebagai arsip audit.

04Ringkasan Fitur

05Tujuan Fitur

5.1 Tujuan Bisnis (dari dokumen bisnis dan kode)

• Penghapusan aset punya keputusan, alasan, dan bukti yang dapat diaudit.
• Status perantara menunggu_disposal mencegah penghapusan tanpa bukti pelaksanaan.
• Data historis aset tidak dihapus, hanya dikeluarkan dari daftar aktif.

5.2 Tujuan Sistem

• Menjaga aset yang sedang di-disposal tidak bisa dipakai alur lain.
• Memvalidasi field wajib per metode dan bukti.
• Mencatat pelaksana, waktu, asset_trx_log, dan notifikasi penyelesaian.

06Aktor

07Hak Akses

Seluruh endpoint hanya untuk admin asset (Asset_m::isAdmin). Non-admin menerima 403. Tidak ada endpoint karyawan/PIC.

08Terminologi

09Business Rules

BR-001 — Aset yang boleh di-disposal

Hanya pemegang_asset = gudang dan status_asset = rusak. Karena proses lain mengubah status (dalam_perbaikan, dalam_proses_klaim, menunggu serah terima), syarat "tidak ada proses aktif" terpenuhi otomatis. Tidak boleh masih dalam onboarding aktif. Pesan: "Hanya asset rusak di gudang yang dapat di-disposal."

BR-002 — Keputusan

alasan_disposal wajib; metode_disposal ∈ tiga nilai; nilai_sisa opsional dan tidak negatif; catatan opsional.

BR-003 — Status perantara

Setelah keputusan, aset menjadi menunggu_disposal dan keluar dari daftar pilihan aset gudang rusak (tidak bisa diajukan dua kali).

BR-004 — Pelaksanaan menurut metode

Tanggal pelaksanaan tidak boleh setelah hari ini. Field milik metode lain dikosongkan.

BR-005 — Bukti wajib

Semua metode wajib bukti. Pembaruan tanpa bukti baru mempertahankan bukti lama; bila belum pernah ada bukti, ditolak.

BR-006 — Pelaksanaan dapat diperbarui

Selama status = proses, admin boleh memperbarui data pelaksanaan. Setelah selesai, tidak dapat diubah.

BR-007 — Penyelesaian

Hanya bila pelaksanaan sudah dicatat (tgl_pelaksanaan terisi) dan data masih lengkap sesuai metode. Aset harus masih di gudang dengan status menunggu_disposal. Hasil: aset disposed, transaksi selesai, asset_trx_log disposal_gudang.

BR-008 — Arsip, bukan hapus

Baris transaksi dan baris asset_data (status disposed) tetap ada. Daftar aset admin dan total ringkasan mengecualikan disposed bila filter status kosong; filter status disposed eksplisit tetap menampilkannya.

BR-009 — Penomoran

id = id_company + YYYYMM + 3 digit; no_trx = PML04-YYYYMMNNN; maksimum 999 per bulan per perusahaan.

BR-010 — Skema harus sudah diterapkan

skemaSiap() menjaga dashboard tetap berjalan sebelum SQL diterapkan.

10Business Flow

1. Admin membuka Disposal → + → memilih satu aset gudang rusak dan meninjau riwayatnya.
2. Admin mengisi alasan, metode, nilai sisa, catatan → Submit Keputusan. Aset menunggu_disposal.
3. Disposal fisik dilakukan di luar sistem.
4. Admin membuka detail → Catat Pelaksanaan (field sesuai metode + tanggal + bukti).
5. Admin menekan Selesaikan Disposal dan mengonfirmasi.
6. Aset disposed; notifikasi ringkasan dikirim ke admin.

11Flow Berdasarkan Role

11.1 Admin/HR

Seluruh alur di atas.

11.2 System

Validasi, kunci status, log, notifikasi, penyaringan daftar aktif.

12Flow Diagram

flowchart TD
    A[Aset gudang rusak] --> B[Admin tinjau riwayat]
    B --> C[Submit keputusan<br/>alasan, metode, nilai sisa]
    C --> D[status proses<br/>asset menunggu_disposal]
    D --> E[Disposal fisik di luar sistem]
    E --> F{Metode}
    F -- lelang_jual --> G[Pembeli, harga, tanggal, bukti]
    F -- donasi --> H[Penerima, tanggal, bukti]
    F -- pemusnahan --> I[Cara, tanggal, bukti]
    G --> J[Pelaksanaan tercatat]
    H --> J
    I --> J
    J --> K[Selesaikan Disposal]
    K --> L[status selesai<br/>asset disposed, data diarsipkan]

13Sequence Diagram

sequenceDiagram
    actor Admin
    participant App as Mobile
    participant API
    participant DB
    Admin->>App: Pilih aset + isi keputusan
    App->>API: POST asset/disposal
    API->>DB: insert trx (proses), asset menunggu_disposal
    Admin->>App: Catat pelaksanaan + foto bukti
    App->>API: POST asset/disposal/{id}/pelaksanaan
    API->>DB: simpan pelaksanaan + file_bukti
    Admin->>App: Selesaikan Disposal (konfirmasi)
    App->>API: POST asset/disposal/{id}/selesai
    API->>DB: trx selesai, asset disposed, asset_trx_log
    API-->>Admin: Notifikasi disposal.selesai

14Status Transaksi

Tidak ada kolom fase terpisah; tahap pelaksanaan ditandai terisinya tgl_pelaksanaan.

15State Transition

stateDiagram-v2
    [*] --> MenungguDisposal: Submit keputusan
    MenungguDisposal --> SiapDiselesaikan: Catat pelaksanaan
    SiapDiselesaikan --> SiapDiselesaikan: Perbarui pelaksanaan
    SiapDiselesaikan --> Dihapus: Selesaikan Disposal
    Dihapus --> [*]

16Struktur Database

Tabel lama asset_trx_disposal_item dan kolom approval dihapus (struktur lama berbasis approval, belum dipakai API).

17Relasi Database

erDiagram
    asset_trx_disposal }o--|| asset_data : "asset"
    asset_trx_disposal }o--o| asset_lokasi_m : "gudang asal"
    asset_data ||--o{ asset_trx_log : "jejak"

18Data Dictionary

18.1 asset_trx_disposal

18.2 asset_trx_log (jenis_log = disposal_gudang)

Ditulis saat penyelesaian: posisi gudang → gudang, kondisi_awal/kondisi_akhir = kondisi aset, user_input = pelaksana.

19Database Index

20Backend Architecture

21Backend Business Logic

21.1 Keputusan — store

Kunci perusahaan; validasi alasan, metode, nilai sisa; kunci aset (lockForUpdate), cek BR-001; nomor urut; insert transaksi (snapshot aset dan gudang asal); aset → menunggu_disposal.

21.2 Pelaksanaan — pelaksanaan

Hanya status = proses. pelaksanaanFields memvalidasi tanggal, bukti, dan field sesuai metode; kolom metode lain dikosongkan; harga_jual dinormalisasi.

21.3 Penyelesaian — selesai

Validasi ulang kelengkapan pelaksanaan, cek aset masih menunggu_disposal di gudang; aset → disposed; asset_trx_log; transaksi selesai dengan tgl_selesai/user_selesai.

21.4 Query baca

getPage (tab proses|selesai, paginasi limit+1), getDetail (aset + riwayat, keputusan, pelaksanaan, penyelesaian, aksi), getAdminOptions (aset gudang rusak + metode), getPendingForAdmin, countPendingForAdmin.

21.5 Riwayat aset

riwayat() menghitung usia (bulan) dari tgl_perolehan, harga_perolehan, serta jumlah baris di asset_trx_perbaikan_item dan asset_trx_garansi_item untuk aset tersebut (0 bila tabel belum ada). Biaya perbaikan tidak dicatat sistem.

22Dampak terhadap asset_data

Aset disposed tidak muncul di daftar aset admin bawaan dan tidak dihitung pada total_asset.

23API Documentation

24Detail Setiap API

API-001 — Opsi

{"asset": [{"id_asset_data": "LP-1", "kode_asset": "KD-LP-1", "nama_asset": "Laptop Lama",
  "kategori_asset": "Laptop", "merek": "", "keterangan_rusak": "Mati total", "lokasi_gudang": "Gudang Utama",
  "riwayat": {"tgl_perolehan": "2019-10-01", "usia_bulan": 85, "harga_perolehan": 15000000,
              "jumlah_perbaikan": 2, "jumlah_klaim_garansi": 1}}],
 "metode": [{"value": "lelang_jual", "label": "Lelang / Jual"}]}

API-002 — Daftar

Query tab (proses|selesai), limit (1–50, default 20), offset. Respons {filters, records[], pagination}; record: id, no_trx, status, status_label, tab, id_asset_data, nama_asset, kategori_asset, metode_disposal, metode_label, alasan_disposal, pelaksanaan_tercatat, tgl_input.

API-003 — Keputusan

{"id_asset_data": "LP-1", "alasan_disposal": "Motherboard rusak total",
 "metode_disposal": "donasi", "nilai_sisa": 250000, "catatan": "Data sudah dihapus"}

Respons CREATED {id, no_trx, status, status_label, tab}.

API-004 — Pelaksanaan

{"tgl_pelaksanaan": "2026-10-09", "pembeli": "PT Pembeli", "harga_jual": 1500000,
 "penerima_donasi": "", "metode_pemusnahan": "", "file_bukti": "<base64 atau file multipart>"}

Hanya field milik metode transaksi yang dipakai. file_bukti kosong = bukti lama dipertahankan. Bukti disimpan di object storage dengan key <company>/asset/disposal/<id_karyawan>/<hex>.<ext>; kolom file_bukti menyimpan key tersebut.

API-005 — Selesai

Tanpa body. Respons {id, no_trx, status: "selesai", status_label: "Dihapus (Disposed)"}.

API-006 — Detail

Grup asset (dengan riwayat), keputusan, pelaksanaan (tercatat, file_bukti_url), penyelesaian, dan aksi: {pelaksanaan, selesai}.

25Mobile Architecture

26Mobile Screen

26.1 Daftar — HalamanAssetDisposal

Tab Menunggu/Selesai, AssetDisposalRecordCard, tombol +.

26.2 Buat — HalamanBuatDisposal

Pilih satu aset (radio); aset terpilih menampilkan kartu riwayat; Lanjut membuka sheet keputusan (alasan, metode chip, nilai sisa, catatan).

26.3 Detail — HalamanDetailAssetDisposal

Kartu status, petunjuk langkah berikutnya, aset + riwayat, keputusan, pelaksanaan (dengan foto bukti), penyelesaian. Tombol bawah: Catat/Ubah Data Pelaksanaan dan Selesaikan Disposal (dialog konfirmasi).

26.4 Sheet pelaksanaan

Field mengikuti metode, picker tanggal (tidak boleh melewati hari ini), foto bukti dari kamera/galeri.

26.5 Entry point

Beranda admin: menu Disposal dan kartu "perlu diproses" (langkah berikutnya: Catat pelaksanaan / Selesaikan disposal). Notifikasi membuka asset_admin_detail_disposal.

27Mobile → API

28API → Mobile

Respons dipetakan ke AssetDisposalRecord, Page, Options. Daftar mengirim data datar, detail mengirim grup; model menangani keduanya. 422 tampil snackbar warning, lainnya error; sukses menutup halaman dengan pesan dan memuat ulang daftar/ringkasan.

29Mapping Mobile → API → Database

30Mapping Database → API → Mobile

31Validation

31.1 Mobile

Alasan dan metode wajib; nilai sisa angka tidak negatif; pada pelaksanaan: field metode, tanggal, dan bukti wajib.

31.2 Backend

Aturan Laravel: id_asset_data wajib, alasan_disposal wajib ≤255, metode_disposal ∈ tiga nilai, nilai_sisa numerik ≥ 0, tgl_pelaksanaan Y-m-d, harga_jual numerik ≥ 0. Aturan bisnis di model (§9).

31.3 Database

Enum metode_disposal, status; FK aset dan gudang.

32Error Handling

33Audit Trail

user_input/tgl_input = keputusan, user_update/tgl_update = pelaksanaan terakhir, user_selesai/tgl_selesai = penyelesaian (format nik - nama). asset_trx_log disposal_gudang saat selesai.

34Notification

Pencatatan pelaksanaan tidak mengirim notifikasi. Notifikasi dikirim setelah transaksi commit.

35Security

JWT; semua endpoint admin-only; filter id_company; transaksi + lockForUpdate; bukti diunggah ke bucket MinIO privat lewat Asset_c::uploadAssetImage (AssetImageStorage): hanya JPEG/PNG/WebP valid, maks 5 MB dan 25 megapiksel; key memuat id_company dan id_karyawan dari JWT; URL bukti berupa presigned URL berumur singkat (lihat dokumentasi-minio-object-storage.md).

36Manual Book User/Admin

A. Membuat keputusan disposal

1. Beranda Asset → Disposal → tombol +.
2. Pilih aset; tinjau usia, harga perolehan, jumlah perbaikan dan klaim.
3. Lanjut → isi alasan, pilih metode, (opsional) nilai sisa dan catatan → Submit Keputusan.

B. Mencatat pelaksanaan

1. Setelah disposal fisik selesai, buka transaksi di tab Menunggu.
2. Catat Pelaksanaan: isi field sesuai metode, tanggal, dan foto bukti → Simpan.
3. Data dapat diubah lagi lewat Ubah Data Pelaksanaan sebelum diselesaikan.

C. Menyelesaikan disposal

Selesaikan Disposal → baca konfirmasi → konfirmasi. Aset berstatus DIHAPUS dan hilang dari daftar aktif.

37Kondisi Button

38Testing Scenario

Cakupan otomatis: API 7 test, mobile 13 test (teks id/en, parsing, payload, bloc, detail 320/400 px, konfirmasi selesai, validasi sheet, alur buat).

39Temuan Ketidaksesuaian

40Edge Case

• Dua admin memilih aset yang sama: yang kedua gagal karena aset sudah menunggu_disposal.
• Status aset berubah antara keputusan dan penyelesaian: penyelesaian ditolak.
• Harga jual berformat koma (1500,50): dinormalisasi di mobile sebelum dikirim.
• Tabel PML02/PML03 belum ada: riwayat menampilkan 0 tanpa error.

41Potential Bug / Technical Risk

RISK-001 — Skema dari SQL manual (TINGGI)

Endpoint gagal bila sql-pml04-disposal.sql belum dijalankan. Jalankan setelah SQL PML01 gudang, PML03, dan PML02 (blok enum menulis ulang daftar penuh).

RISK-002 — Tidak ada pembatalan (SEDANG)

Keputusan yang salah mengunci aset di menunggu_disposal; perbaikan membutuhkan intervensi manual di database.

RISK-003 — Penyelesaian tidak dapat dibatalkan (SEDANG)

Dialog konfirmasi memitigasi di UI; di API tidak ada rollback.

RISK-004 — Bukti lama di disk lokal (RENDAH)

Bukti baru disimpan di object storage. Bukti lama di UPLOAD_DIR tetap terbaca lewat fallback URL lokal. Object lama tidak dihapus saat bukti diganti; object baru yang yatim dibersihkan otomatis bila transaksi gagal.

RISK-005 — Kapasitas penomoran 999/bulan (RENDAH)

Batas 999 transaksi per bulan per perusahaan.

42Dependency

Asset_m/Asset_c, AssetImageStorage, AssetNotification, AssetPemeliharaanKaryawan_m (format tanggal), tabel asset_data, asset_kategori_m, asset_lokasi_m, asset_trx_log; asset_trx_perbaikan_item dan asset_trx_garansi_item (riwayat, opsional).

43Source Code Reference

44Developer Notes

• Desain disederhanakan dari struktur header+item: satu aset per transaksi, satu tabel.
• mutateAssetTrx menerima event null untuk langkah tanpa notifikasi.
• pelaksanaanFields dipakai ulang oleh selesai untuk memastikan data tetap lengkap.
• Teks UI memakai AssetDisposalText.t(key); kunci dinamis: fase_*, hint_*, metode_*, bukti_*, tgl_pelaksanaan_*, aksi_*.

45End-to-End Traceability

45.4 Walkthrough Lengkap dengan Contoh Data

Bagian ini mengikuti satu disposal dari keputusan sampai asset dihapus dari daftar aktif, langkah demi langkah: apa yang dilakukan admin di mobile, apa yang dikirim, apa yang diproses API, dan apa yang tersimpan di database. Data bersifat sintetis, tetapi format ID, nama kolom, urutan proses, label status, dan pesan diambil dari kode (AssetDisposal_m, AssetAdminDisposal_c, AssetNotification). Disposal hanya dilakukan admin (tanpa approval) dan tidak ada PIC.

Skenario: Laptop lama di gudang rusak total dan tidak layak dipertahankan. Admin meninjau riwayatnya lalu memutuskan disposal dengan metode Lelang / Jual. Setelah laptop terjual, admin mencatat pelaksanaan (pembeli, harga, tanggal, bukti), memperbaruinya satu kali karena harga terkoreksi, lalu menyelesaikan disposal.

Data awal

Company CMP001. Keputusan diambil 22 Oktober 2026, periode ID 202610. Belum ada transaksi disposal, log, atau notifikasi pada periode ini.

asset_data A70: CMP00120260100070 (LPT-0070), Laptop Lama, kategori Laptop, pemegang_asset = gudang, status_asset = rusak, kondisi_awal = rusak, ket_rusak = Mati total, id_asset_lokasi_m = CMP001202601001 (Gudang Pusat), tgl_perolehan = 2019-10-01, harga_perolehan = 15000000. Asset ini pernah 2 kali masuk Perbaikan dan 1 kali Klaim Garansi.

Admin: KRY0099 (ADM-001, Siti Admin) sebagai pelaksana, KRY0100 (ADM-002, Rudi Admin).

Penomoran: id_company + YYYYMM + 3 digit, no_trx = PML04-YYYYMMNNN; log dan notifikasi 5 digit. Satu transaksi = satu asset; tidak ada tabel item terpisah dan tidak ada kolom fase: tahap pelaksanaan ditandai terisinya tgl_pelaksanaan.

Langkah 0 — Admin memuat opsi dan riwayat

Mobile: Pemeliharaan (admin) → Disposal → buat → AssetDisposalApi memuat opsi.

Dikirim

GET /asset/disposal/options
Authorization: Bearer <access_token_admin>

Diproses API (AssetDisposal_m::getAdminOptions): asset gudang berstatus rusak (asset yang sudah menunggu_disposal tidak muncul lagi), masing-masing dengan riwayat: usia dalam bulan dari tgl_perolehan, harga_perolehan, jumlah baris di asset_trx_perbaikan_item, dan jumlah baris di asset_trx_garansi_item (0 bila tabel belum ada). Biaya perbaikan tidak dicatat sistem. Ditambah daftar metode.

Database: hanya SELECT.

Diterima mobile (ringkas)

{ "asset": [ { "id_asset_data": "CMP00120260100070", "kode_asset": "LPT-0070", "nama_asset": "Laptop Lama",
    "kategori_asset": "Laptop", "keterangan_rusak": "Mati total", "lokasi_gudang": "Gudang Pusat",
    "riwayat": { "tgl_perolehan": "2019-10-01", "usia_bulan": 84, "harga_perolehan": 15000000,
                 "jumlah_perbaikan": 2, "jumlah_klaim_garansi": 1 } } ],
  "metode": [ { "value": "lelang_jual", "label": "Lelang / Jual" }, { "value": "donasi", "label": "Donasi" },
              { "value": "pemusnahan", "label": "Pemusnahan" } ] }

Langkah 1 — Admin menyubmit keputusan

Mobile: admin memilih laptop, meninjau riwayat, mengisi alasan, memilih metode, nilai sisa, dan catatan → Submit → AssetDisposalApi.store.

Dikirim

POST /asset/disposal

{ "id_asset_data": "CMP00120260100070", "alasan_disposal": "Motherboard rusak total",
  "metode_disposal": "lelang_jual", "nilai_sisa": 250000, "catatan": "Data sudah dihapus" }

Diproses API (AssetAdminDisposal_c::storeDisposal → store, satu DB::transaction) 1. Validasi: alasan_disposal wajib, metode_disposal ∈ lelang_jual/donasi/pemusnahan; nilai_sisa opsional dan tidak negatif ("Nilai sisa harus berupa angka tidak negatif."). 2. lockCompany; cek admin; asset dikunci FOR UPDATE dan harus tepat satu ("Asset tidak ditemukan."). 3. Asset harus gudang dan rusak ("Hanya asset rusak di gudang yang dapat di-disposal."); tidak ada di onboarding aktif. Karena proses lain mengubah status (dalam_perbaikan, dalam_proses_klaim, menunggu serah terima), syarat "tidak ada proses aktif" terpenuhi otomatis. 4. Generate ID: CMP001202610001, no_trx = PML04-202610001. 5. INSERT transaksi (snapshot asset dan gudang asal, status = proses, tgl_pelaksanaan NULL) dan UPDATE asset_data → menunggu_disposal. 6. Tidak ada notifikasi pada tahap ini (event null).

Hasil database

asset_trx_disposal

asset_data A70: status_asset rusak → menunggu_disposal, tgl_update = 09:00:00, user_update = ADM-001 - Siti Admin.

Diterima mobile (HTTP 201)

{ "code": "CREATED", "message": "…",
  "data": { "id": "CMP001202610001", "no_trx": "PML04-202610001", "status": "proses",
            "status_label": "Menunggu Disposal", "tab": "proses" } }

Asset kini hilang dari opsi sehingga tidak dapat diajukan dua kali.

Langkah 2 — Admin mencatat pelaksanaan

Mobile: detail disposal (aksi.pelaksanaan = true) → form pelaksanaan sesuai metode Lelang / Jual: tanggal, pembeli, harga jual, dan foto bukti (kamera atau galeri) → Simpan.

Dikirim (multipart karena ada file)

POST /asset/disposal/CMP001202610001/pelaksanaan

{ "tgl_pelaksanaan": "2026-10-23", "pembeli": "PT Pembeli Sejahtera", "harga_jual": 1500000,
  "penerima_donasi": "", "metode_pemusnahan": "", "file_bukti": "<file multipart atau base64>" }

Diproses API (buktiPath lalu pelaksanaan) 1. Validasi controller: tgl_pelaksanaan wajib Y-m-d; harga_jual numerik ≥ 0. 2. prepareImageUpload memastikan transaksi masih proses sebelum file diunggah ("Disposal sudah selesai dan tidak dapat diubah."). File diunggah dengan key CMP001/asset/disposal/<id_karyawan>/<hex>.<ext>; hanya key yang disimpan. File tidak valid → "File bukti tidak valid.". 3. pelaksanaanFields menerapkan aturan menurut metode transaksi (bukan menurut input): tanggal wajib dan tidak boleh setelah hari ini; bukti wajib (bila tidak mengunggah baru, bukti lama dipertahankan; bila belum pernah ada, ditolak). Untuk lelang_jual: pembeli dan harga_jual wajib. Field milik metode lain dikosongkan. 4. UPDATE transaksi dengan kolom pelaksanaan, tgl_update, user_update. asset_data belum berubah. Tidak ada notifikasi.

Hasil database

Diterima mobile (HTTP 200): status = proses, status_label = "Siap Diselesaikan" (karena tgl_pelaksanaan sudah terisi), tab = "proses", message "Data pelaksanaan disposal berhasil disimpan.". Detail menampilkan pelaksanaan.tercatat = true dan file_bukti_url.

Langkah 3 — Admin memperbarui pelaksanaan

Pelaksanaan boleh diperbarui selama status = proses. Admin mengoreksi harga jual.

Dikirim: POST /asset/disposal/CMP001202610001/pelaksanaan dengan harga_jual = 1750000, tanpa file_bukti baru dan tanpa mengulang field lain.

Diproses API: pelaksanaanFields memakai nilai lama untuk field yang tidak dikirim (pakai(key, nilai lama)), sehingga pembeli dan tanggal tetap; bukti lama dipertahankan karena file_bukti kosong. Hasil database: harga_jual 1500000.00 → 1750000.00, tgl_update = 2026-10-23 10:30:00; kolom lain tetap.

Langkah 4 — Admin menyelesaikan disposal

Mobile: Selesaikan Disposal (dialog konfirmasi) → AssetDisposalApi.selesai.

Dikirim

POST /asset/disposal/CMP001202610001/selesai

Tanpa body.

Diproses API (selesai) 1. Transaksi harus proses ("Disposal sudah selesai."). 2. tgl_pelaksanaan harus terisi ("Data pelaksanaan disposal belum dicatat."); pelaksanaanFields dijalankan ulang untuk memastikan data masih lengkap menurut metode. 3. Asset dikunci dan harus masih gudang dengan status menunggu_disposal ("Status asset sudah berubah atau tidak lagi berada di gudang."). 4. UPDATE asset_data → disposed; INSERT asset_trx_log (jenis_log = disposal_gudang, posisi gudang → gudang, kondisi tidak berubah). 5. UPDATE transaksi: status = selesai, tgl_selesai, user_selesai, tgl_update, user_update. 6. Notifikasi disposal.selesai ke seluruh admin.

Hasil database

asset_trx_log (1 baris)

notif_data (2 baris, satu per admin)

Diterima mobile (HTTP 200)

{ "code": "UPDATED", "message": "Disposal berhasil diselesaikan.",
  "data": { "id": "CMP001202610001", "no_trx": "PML04-202610001", "status": "selesai",
            "status_label": "Dihapus (Disposed)", "tab": "selesai" } }

Kondisi akhir data

asset_trx_disposal: CMP001202610001 / PML04-202610001, status = selesai, metode_disposal = lelang_jual, harga_jual = 1750000.00, tgl_pelaksanaan = 2026-10-23, bukti tersimpan sebagai key object storage.

asset_data A70: status_asset = disposed. Baris asset tidak dihapus (arsip): daftar asset admin dan total ringkasan mengecualikan disposed bila filter status kosong, tetapi filter status disposed eksplisit tetap menampilkannya. asset_trx_log: 1 baris. notif_data: 2 baris.

Variasi

Donasi. metode_disposal = donasi: pelaksanaan wajib penerima_donasi ("Penerima donasi wajib diisi."), tanggal, dan bukti; pembeli, harga_jual, dan metode_pemusnahan dikosongkan. Notifikasi menyebut "(Donasi)".

Pemusnahan. metode_disposal = pemusnahan: pelaksanaan wajib metode_pemusnahan ("Metode pemusnahan wajib diisi."), tanggal, dan bukti; field metode lain dikosongkan. Notifikasi menyebut "(Pemusnahan)".

Disposal sebagai tindak lanjut modul lain. Asset rusak di gudang yang berasal dari Pemeliharaan (hasil 4–5), Perbaikan ("diganti unit baru" atau "tidak bisa diperbaiki"), atau Klaim Garansi (ditolak dengan tindak lanjut disposal) hanya ditandai nama_tabel_tindak_lanjut = asset_trx_disposal; transaksi Disposal tetap harus dibuat manual lewat langkah 1.

Kasus gagal yang umum

Semua pelanggaran aturan dilempar sebagai InvalidArgumentException di dalam DB::transaction, sehingga seluruh perubahan request itu dibatalkan. Pesan tersedia dalam bahasa Indonesia dan Inggris mengikuti header locale.

Ringkasan siapa mengerjakan apa

46Ringkasan Database Impact

Tabel asset_trx_disposal dibuat ulang (tabel lama asset_trx_disposal dan _item di-drop bila kosong). asset_data.status_asset +menunggu_disposal; asset_trx_log.jenis_log +disposal_gudang.

47Checklist Implementasi

Database

• DBML diperbarui
• SQL manual + guard + rollback
• SQL dijalankan di setiap environment

Backend

• Model, controller, route, notifikasi, pengecualian aset disposed
• Test otomatis

Mobile

• Daftar, buat, detail, sheet keputusan dan pelaksanaan
• Kartu beranda admin, rute notifikasi, teks id/en
• Test otomatis

Documentation

• Dokumen ini

48Changelog