Alur Proses Void
Rangkaian aktor dan aksi utamanya dari pengajuan sampai eksekusi — detail tiap langkah ada di kartu UC1–UC6 di bawah.
→
Approver Unit
Validasi Paygroup & Persetujuan
→
Operator Pusat
Verifikasi XML
→
Approver Pusat
Persetujuan ke Bank & Eksekusi Void
→
Admin Bank
Konfirmasi & Eksekusi Void Bank
→
Operator Pusat
Eksekusi Void SPAN
Daftar Isi
Rujukan skenario perilaku pengguna
1. Aktor
Daftar kewewenangan per aktor.
| Aktor | Siapa Dia | Tanggung Jawab Utama |
|---|
| Operator Unit | Staf di KPPN yang mengurus dokumen pengajuan pembatalan SP2D (contoh: Operator KPPN) | Membuat pengajuan void |
| Approver Unit | Atasan langsung Operator Unit di instansi yang sama (contoh: Kepala Seksi di KPPN) | Gatekeeper pertama — cek kelengkapan sebelum naik ke Pusat |
| Operator Pusat | Admin SPAN di Kantor Pusat (prakom di PSII 3, SITP) | Verifikasi teknis + eksekusi akhir nantinya di SPAN sebagai admin SPAN staff PM |
| Approver Pusat | Pejabat di Kantor Pusat (kepala seksi di PSII 3, SITP) | Persetujuan final untuk pengalihan pengajuan ke bank dan eksekusi void di SPAN. |
| Admin Bank | Petugas bank mitra (BRI, Mandiri, BNI, dst — satu akun per bank) | Mengeksekusi pembatalan transfer di sisi bank, khusus metode TDE (Sp2d isi) saja |
2. Ringkasan Use Case
| # | Use Case | Siapa yang Mulai | Kapan Terjadi |
|---|
| UC1 | Ajukan Void SP2D | Operator Unit | Setiap kali ada SP2D yang perlu dibatalkan. Saat ini pengajuan diajukan oleh satker dan ND dibuat KPPN (per05) |
| UC2 | Validasi & Setujui Void (Unit) | Approver Unit | Setelah UC1 |
| UC3 | Verifikasi Void (Pusat) | Operator Pusat | Setelah UC2 |
| UC4 | Persetujuan Akhir (Approver Pusat) | Approver Pusat | Setelah UC3 |
| UC5 | Konfirmasi Void Bank | Admin Bank | Setelah UC4, hanya kalau ada SP2D metode TDE |
| UC6 | Eksekusi Void SPAN | Operator Pusat | Setelah UC4 (non-TDE) atau UC5 (TDE) |
| UC7 | Tolak Pengajuan | Approver Unit / Operator Pusat / Approver Pusat / Admin Bank | Kapan saja di titik masing-masing, sekali per pengajuan/SP2D |
| UC8 | Lihat Riwayat Void | Semua aktor | Kapan saja, read-only |
UC1Ajukan Void SP2D
👤 Operator Unit
Operator Unit menemukan SP2D yang salah/perlu dibatalkan (salah rekening, salah nominal, duplikasi, dll), yang merupakan permintaan dari satker dan mengajukan permintaan pembatalan.
Prasyarat
- Operator Unit sudah login dan terverifikasi terhadap satker/KPPN tempat dia bertugas
- SP2D yang mau di-void sudah terbit dan berstatus normal (belum pernah diajukan void sebelumnya, atau pengajuan void sebelumnya untuk SP2D ini sudah pernah ditolak/gagal tapi statusnya masih NEGOTIABLE)
Alur Utama
- Operator Unit membuka menu "Pengajuan Void", klik "Ajukan Void"
- Sistem menampilkan daftar SP2D yang eligible untuk void (yang jadi kewenangan dia)
- Operator Unit memilih satu atau beberapa SP2D — boleh beda paygroup/bank sekaligus dalam satu pengajuan (misal 1 SP2D BRI + 1 SP2D Mandiri jadi satu pengajuan)
- Operator Unit memilih kategori alasan (Kesalahan Satker / Kesalahan KPPN / Kesalahan Sistem / Retur Bank / Alasan Lainnya) dan menulis detail bebas
- Operator Unit mengunggah dokumen pendukung (Surat/Nota Dinas, PDF)
- Operator Unit menekan "Ajukan"
- Sistem membuat 1 pengajuan baru dengan status "Menunggu Approver Unit" dan menotifikasi Approver Unit di instansi yang sama
Alur Alternatif
A1 — Batal di tengah jalan: Operator Unit bisa menutup form kapan saja sebelum klik "Ajukan"; tidak ada data tersimpan
A2 — Field yang terisi belum lengkap: Sistem tidak dapat submit kalau field belum diisi
Pascakondisi (kalau sukses)
- 1 objek pengajuan baru tercipta, berisi array SP2D (bisa 1 atau banyak, bisa beda bank)
- Status pengajuan: Menunggu Approver Unit
- Pengajuan ini satu ID, satu dokumen PDF, selamanya — tidak pernah "dipecah" jadi banyak record meski isinya multi-bank (lihat §11)
UC2Validasi & Setujui Void (Unit)
👤 Approver Unit
Approver Unit mengecek pengajuan dari bawahannya — memastikan alasan dan dokumen sesuai — sebelum meneruskannya ke Kantor Pusat.
Prasyarat
Ada pengajuan berstatus "Menunggu Approver Unit" milik instansi yang sama dengan Approver Unit
Alur Utama
- Approver Unit membuka daftar pengajuan yang perlu tindakan
- Approver Unit memilih satu pengajuan, membaca dokumen pendukung dan detail SP2D (bisa lebih dari satu SP2D dalam 1 pengajuan)
- Approver Unit menekan "Setuju & Teruskan ke Pusat"
- Sistem meminta konfirmasi (dialog ringkasan)
- Approver Unit mengonfirmasi
- Sistem mengubah status pengajuan jadi "Perlu Verifikasi" dan meneruskannya ke worklist Operator Pusat
Aturan penting: Keputusan ini binary untuk seluruh pengajuan — Approver Unit tidak bisa menyetujui sebagian SP2D dan menolak sebagian lainnya dalam 1 pengajuan yang sama.
Alur Alternatif
Pascakondisi (kalau sukses)
- Status pengajuan: Perlu Verifikasi (masuk worklist Operator Pusat)
UC3Verifikasi Void (Pusat)
👤 Operator Pusat
Operator Pusat mengecek keabsahan data secara teknis — apakah data SP2D di lampiran benar-benar cocok dengan data di sistem SPAN — sebelum diteruskan untuk persetujuan akhir.
Prasyarat
Ada pengajuan berstatus "Perlu Verifikasi"
Alur Utama
- Operator Pusat membuka pengajuan, melihat tabel SP2D di dalamnya
- Untuk tiap baris SP2D, Operator Pusat mencocokkan data dan menandai toggle "Sesuai/Tidak" — ini murni catatan visual, bukan gerbang yang memblokir sebagian SP2D
- Kalau ada SP2D metode TDE: Operator Pusat wajib klik "Verifikasi XML" dulu — sistem men-generate nama-nama file XML yang nanti dipakai referensi oleh Admin Bank. Tombol "Setuju & Kirim" baru aktif setelah langkah ini
- Kalau semua SP2D non-TDE (SP3/NIHIL): langkah XML dilewati, langsung bisa lanjut
- Operator Pusat menekan "Setuju & Kirim"
- Sistem mengubah status jadi "Perlu Persetujuan" dan meneruskan ke worklist Approver Pusat
Alur Alternatif
A1 — Tolak: lihat
UC7 — biasanya karena data lampiran tidak cocok dengan SPAN
A2 — Campuran TDE + non-TDE dalam 1 pengajuan: tetap wajib generate XML (karena ada minimal 1 SP2D TDE), tapi hanya SP2D TDE yang tercantum di file XML (real life: tidak pernah terjadi)
Pascakondisi (kalau sukses)
- Status: Perlu Persetujuan (masuk worklist Approver Pusat)
- Nama-nama file XML sudah tergenerate dan tersimpan sebagai referensi
UC4Persetujuan Akhir (Approver Pusat)
👤 Approver Pusat
Ini adalah titik keputusan final sebelum pembatalan benar-benar dieksekusi. Approver Pusat melihat riwayat lengkap (siapa saja yang sudah menyetujui sebelumnya) lalu memberi persetujuan terakhir.
Prasyarat
Ada pengajuan berstatus "Perlu Persetujuan"
Alur Utama
- Approver Pusat membuka pengajuan, melihat checklist riwayat (✓ Divalidasi Approver Unit, ✓ Diverifikasi Operator Pusat) dan tabel SP2D read-only
- Sistem menunjukkan ke mana pengajuan ini akan pergi setelah disetujui — dihitung dari isi SP2D-nya, bukan cuma satu field metode:
| Komposisi SP2D | Label Tombol | Tujuan |
|---|
| Semua TDE | Setuju & Kirim ke Bank | Admin Bank (bisa >1 bank kalau multi-bank) |
| Semua non-TDE | Setuju & Siap Void SPAN | Langsung ke Operator Pusat untuk eksekusi |
| Campuran | Dialog konfirmasi menjelaskan pembagiannya eksplisit ("2 SP2D TDE → Bank BRI, 1 SP2D SP3 → langsung Void SPAN") |
- Approver Pusat menekan tombol setuju sesuai label yang tampil
- Sistem mengonfirmasi, lalu: SP2D TDE → status per-SP2D jadi "Menunggu Bank", otomatis muncul di worklist Admin Bank terkait (per paygroup); SP2D non-TDE → status jadi "Siap Void SPAN", langsung masuk worklist eksekusi Operator Pusat, tidak lewat Admin Bank sama sekali
Aturan penting: Ini keputusan binary untuk seluruh pengajuan — Approver Pusat tidak memilih SP2D mana yang lanjut dan mana yang tidak. Titik "percabangan" per-SP2D (ke bank mana) terjadi otomatis di sistem berdasarkan data, bukan pilihan manual Approver Pusat.
Alur Alternatif
A1 — Tolak: lihat
UC7 — bersifat final,
seluruh SP2D dalam pengajuan gagal bersama, tidak ada yang "diselamatkan sebagian"
Pascakondisi (kalau sukses)
- Tiap SP2D TDE: status Menunggu Bank, muncul di worklist Admin Bank sesuai paygroup-nya
- Tiap SP2D non-TDE: status Siap Void SPAN, muncul di worklist eksekusi Operator Pusat
- Tidak ada record baru dibuat — pengajuan tetap 1 objek yang sama, cuma "terlihat" berbeda dari sudut pandang tiap Admin Bank
UC5Konfirmasi Void Bank
👤 Admin Bank (per-bank)
Setelah disetujui Approver Pusat, tiap SP2D metode TDE perlu dikonfirmasi pembatalannya oleh bank yang bersangkutan — di luar aplikasi ini (di sistem internal bank), baru hasilnya dicatat di sini sebagai bukti.
Prasyarat
- Ada SP2D berstatus "Menunggu Bank" dengan paygroup = bank yang login
- Penting: Admin Bank BRI hanya melihat SP2D miliknya sendiri, lintas semua pengajuan — bukan per pengajuan. Kalau 1 pengajuan punya SP2D BRI + Mandiri, Admin BRI tidak melihat sama sekali baris SP2D milik Mandiri (bukan cuma disembunyikan/di-disable — memang tidak ada di worklist-nya)
Alur Utama
- Admin Bank membuka worklist "Perlu Konfirmasi Bank", memilih satu SP2D
- Admin Bank melihat detail SP2D, nama file XML sebagai referensi, dan dokumen pendukung pengajuan (ditampilkan utuh — bukan versi yang disensor, karena dokumen bukan data rahasia antar-bank)
- Di luar aplikasi ini, Admin Bank memproses pembatalan transfer di sistem bank masing-masing
- Admin Bank kembali ke aplikasi, mengunggah bukti void — wajib, bisa paste screenshot (Ctrl+V) atau upload file PDF/JPG/PNG, maksimal 5 MB
- Admin Bank menekan "Konfirmasi Void Bank"
- Sistem mengubah status SP2D itu jadi "VOIDED Bank" dan mengirim notifikasi ke Operator Pusat
Alur Alternatif
A1 — Tolak (bank menolak pembatalan): lihat
UC7 —
hanya SP2D itu sendiri yang gagal, SP2D lain (bank lain) dalam pengajuan yang sama tidak terpengaruh dan tetap diproses masing-masing secara independen
A2 — Belum ada bukti: tombol "Konfirmasi" menolak aksi dengan pesan error kalau bukti belum diunggah
Pascakondisi (kalau sukses)
- Status SP2D itu: VOIDED Bank
- Kalau ini SP2D TDE terakhir yang belum dijawab dalam pengajuan → seluruh pengajuan otomatis pindah ke "Siap Void SPAN", masuk worklist eksekusi Operator Pusat
- Kalau masih ada SP2D TDE lain yang belum dijawab bank lain → pengajuan tetap menunggu
UC6Eksekusi Void SPAN
👤 Operator Pusat
Ini adalah langkah eksekusi final — begitu semua SP2D TDE sudah dapat jawaban dari bank (apapun jawabannya) dan SP2D non-TDE sudah disetujui Approver Pusat, Operator Pusat menekan tombol konfirmasi yang benar-benar membatalkan SP2D di SPAN (eksekusi void terpisah di SPAN).
Prasyarat
Pengajuan berstatus "Siap Void SPAN" — artinya: semua SP2D non-TDE sudah lewat UC4, ATAU semua SP2D TDE sudah dapat jawaban dari bank (VOIDED atau Ditolak) via UC5 — tidak perlu semua sukses, cukup semua sudah ada jawaban
Alur Utama
- Operator Pusat membuka pengajuan, melihat breakdown per SP2D: mana yang berhasil dikonfirmasi bank (✅), mana yang ditolak bank (❌), mana yang non-TDE (langsung siap)
- Sistem menampilkan ringkasan, contoh: "2 dari 3 SP2D akan divoid. 1 SP2D ditolak bank dan tidak akan divoid."
- Operator Pusat menekan tombol eksekusi — labelnya "Konfirmasi Void SPAN" (kalau semua bersih) atau "Konfirmasi Void SPAN (Partial)" (kalau ada yang ditolak bank)
- Sistem mengeksekusi: SP2D yang VOIDED Bank (atau non-TDE) → benar-benar dibatalkan di SPAN; SP2D yang Ditolak Bank → otomatis di-skip, SP2D aslinya tetap utuh/tidak berubah
- Sistem menentukan status akhir pengajuan (lihat tabel di bawah)
| Kondisi | Status Akhir |
|---|
| Semua SP2D sukses divoid | Selesai (voided) |
| Sebagian sukses, sebagian di-skip | Selesai Partial (voided_partial) |
| Semua SP2D TDE ditolak bank, tidak ada satupun sukses | Gagal — Semua Ditolak Bank (voided_failed) |
Aturan penting: Pengajuan yang sudah selesai di titik ini (apapun hasilnya) ditutup permanen. Tidak ada mekanisme "buka lagi" untuk SP2D yang gagal — kalau unit pengaju mau coba lagi, harus membuat pengajuan void baru dari nol, khusus untuk SP2D yang gagal itu saja.
Pascakondisi
- Status final pengajuan tercatat:
voided / voided_partial / voided_failed
- Seluruh hasil (termasuk breakdown per SP2D) tercapture di Riwayat Void (UC8)
- Notifikasi hasil selalu lewat Operator Pusat dulu (pusat notifikasi/central hub), baru diteruskan turun ke Approver Unit → Operator Unit bila memang perlu
UC7Tolak Pengajuan (lintas role)
👤 Approver Unit / Operator Pusat / Approver Pusat / Admin Bank
Di tiap tahap approval, aktor yang berwenang bisa menolak kalau menemukan masalah. Tapi konsekuensi penolakan beda-beda tergantung siapa yang menolak.
| Siapa Menolak | Yang Gagal | Sifat |
|---|
| Approver Unit | Seluruh pengajuan | Final — kembali ke Operator Unit, harus ajukan ulang dari awal kalau mau coba lagi |
| Operator Pusat (saat verifikasi) | Seluruh pengajuan | Final — misal karena data lampiran tidak cocok dengan data SPAN |
| Approver Pusat | Seluruh pengajuan | Final — misal ada info tidak jadi diajukan void, sehingga perlu ditolak. |
| Admin Bank | Hanya SP2D miliknya sendiri | Final untuk SP2D itu saja — SP2D lain (bank lain) dalam pengajuan yang sama tidak ikut gagal, tetap diproses independen |
Alur Utama (generik, berlaku di semua titik di atas)
- Aktor menekan tombol "Tolak Pengajuan" (atau "Tolak" untuk Admin Bank yang levelnya per-SP2D)
- Sistem menampilkan dialog yang mewajibkan pengisian alasan penolakan
- Aktor mengisi alasan, menekan konfirmasi
- Sistem mencatat status ditolak beserta alasan dan siapa yang menolak + kapan
Aturan penting: Semua penolakan (kecuali Admin Bank) bersifat final untuk seluruh pengajuan — tidak ada undo, tidak ada re-route otomatis. Penolakan Admin Bank bersifat final per-SP2D — tidak menggagalkan pengajuan secara keseluruhan; kalau semua SP2D TDE ditolak bank sekaligus, pengajuan tetap lanjut ke Operator Pusat untuk dieksekusi (hasilnya voided_failed, bukan langsung dianggap "ditolak").
Notifikasi: selalu naik/turun berjenjang — kalau ditolak Operator Pusat, Approver Unit dan Operator Unit langsung diberi tahu; kalau ditolak Admin Bank, selalu lewat Operator Pusat dulu (central hub) sebelum turun ke Approver Unit/Operator Unit.
Pascakondisi
- Status pengajuan (atau SP2D spesifik untuk kasus Admin Bank): Ditolak, dengan alasan tercatat
- Semua penolakan tercapture di Riwayat Void
UC8Lihat Riwayat Void
👤 Semua role (read-only)
Siapapun bisa melihat rekap pengajuan yang sudah final (berhasil atau gagal) untuk keperluan audit/pelacakan, tanpa bisa mengubah apapun.
Prasyarat
Tidak ada — menu ini selalu tersedia di sidebar tiap role
Alur Utama
- Aktor membuka menu "Riwayat Void"
- Sistem menampilkan daftar per SP2D (bukan per pengajuan) — karena satu pengajuan bisa berisi banyak SP2D dengan nasib berbeda-beda (sebagian voided, sebagian ditolak bank) dalam pengajuan multi-bank
- Aktor bisa filter berdasarkan status (lihat tabel di bawah)
- Aktor membuka detail satu baris untuk melihat kronologi lengkap dan alasan
| Status | Arti |
|---|
| Voided | SP2D berhasil dibatalkan |
| Negotiable | Status Awal yg bisa divoid ini sebenarnya. Dalam case ini, Jika sudah diajukan dan ditolak bank, dan ia statusnya negotiable, ia masih terbuka untuk pengajuan ulang dari unit |
| Reconciled | Tidak bisa divoid kecuali ada mekanimse unreconciled di SPAN-nya. Bisa juga dia ditolak dan tidak dapat diajukan void lagi. (krn sudah reconciled) |
Kenapa Negotiable ≠ Reconciled meski sama-sama "ditolak" — bedanya soal apa yang bisa dilakukan selanjutnya. Ditolak bank berarti masih ada peluang (rekening bisa diperbaiki, ajukan ulang), sedangkan ditolak sebelum ke bank biasanya soal kesalahan administratif yang harus diperbaiki dari awal.
Pascakondisi
Tidak ada — murni tampilan, tidak mengubah data apapun.
11. Aturan Bisnis Lintas Use Case
Aturan-aturan ini berlaku di banyak use case sekaligus — dikumpulkan di sini biar tidak diulang-ulang.
- Satu pengajuan = satu objek data selamanya. Meskipun 1 pengajuan berisi SP2D dari 3 bank berbeda, itu tetap 1 ID, 1 dokumen PDF, dari awal (UC1) sampai akhir (UC6). Yang "kelihatan terpecah" cuma cara Admin Bank melihatnya (UC5) — itu hasil filter, bukan pemisahan data.
- Approval selalu binary per-pengajuan, kecuali di titik bank. UC2, UC3, UC4 semuanya keputusan setuju/tolak untuk seluruh pengajuan — tidak bisa pilih-pilih SP2D. Titik satu-satunya yang granular per-SP2D adalah UC5 (konfirmasi bank) dan konsekuensinya di UC6 (eksekusi partial).
- Metode pembayaran menentukan siapa yang terlibat: TDE (Transfer Dana Elektronik) → wajib lewat Admin Bank (UC5). SP3 dan NIHIL → bypass bank sepenuhnya, langsung dari Approver Pusat (UC4) ke eksekusi (UC6). Satu pengajuan boleh campuran — sebagian SP2D-nya TDE, sebagian SP3/NIHIL, dalam pengajuan yang sama.
- Tidak ada "buka lagi" untuk yang gagal. Begitu status final tercapai (
voided_partial, voided_failed, atau ditolak di titik manapun), itu tertutup permanen. Satu-satunya jalan lanjut adalah UC1 baru dari nol, khusus untuk SP2D yang gagal.
- Operator Pusat adalah pusat notifikasi (central hub). Semua hasil dari bank (UC5) — baik sukses, gagal sebagian, atau gagal total — dilaporkan ke Operator Pusat dulu, baru diteruskan turun ke Approver Unit → Operator Unit kalau memang diperlukan.
- Access Control Admin Bank bersifat ketat per-bank. Akun Admin BRI hanya bisa melihat dan mengaksi SP2D dengan paygroup BRI, lintas semua pengajuan yang ada di sistem. SP2D bank lain tidak muncul sama sekali di worklist-nya (bukan cuma disembunyikan/dinonaktifkan).