Di layar, tombol “Ajukan” terlihat seperti satu tindakan. Di belakangnya, ada pertanyaan yang lebih penting: kapan barang benar-benar dianggap masuk atau keluar dari gudang?
Dalam sistem inventaris Rumah Plastik, staf dapat mengajukan barang masuk atau keluar. Admin memeriksa pengajuan, lalu kepala memberi persetujuan akhir. Stok baru berubah setelah keputusan terakhir itu. Pilihan ini terdengar kecil, tetapi menentukan apakah angka di layar masih bisa dipercaya saat beberapa orang bekerja bersamaan.
Pengajuan bukan transaksi stok
Ketika staf mengirim permintaan, sistem menyimpan niat untuk memindahkan barang. Permintaan itu masih bisa ditolak atau diminta diperbaiki. Kalau stok langsung dikurangi saat tombol ditekan, penolakan harus membuat sistem mengembalikannya. Itu menambah jalur koreksi yang mudah terlewat.
Saya lebih suka memisahkan tiga hal: pengajuan dicatat, jumlah yang diminta diperhitungkan, dan stok fisik diubah setelah persetujuan final. Setiap tahap punya status dan penanggung jawab sendiri. Orang yang melihat permintaan pending tidak akan salah mengira barang sudah keluar.
Stok tersedia tidak selalu sama dengan stok tercatat
Menahan perubahan stok sampai akhir bukan berarti permintaan pending boleh diabaikan. Untuk barang keluar, sistem perlu memperhitungkan jumlah yang sedang menunggu persetujuan agar barang yang sama tidak dijanjikan dua kali.
Misalnya stok tercatat 10 unit. Satu pengajuan meminta 7 unit dan masih menunggu keputusan. Permintaan baru untuk 5 unit tidak semestinya dianggap aman hanya karena kolom stok masih menunjukkan 10. Jumlah yang tersedia untuk pengajuan baru perlu mempertimbangkan 7 unit yang sudah dialokasikan. Di sinilah stok tercatat dan stok yang masih dapat diajukan menjadi dua angka berbeda.
Perbedaan ini juga perlu terlihat dalam antarmuka. Bila kedua angka disatukan tanpa penjelasan, pengguna dapat mengira aplikasi salah menghitung. Label yang jelas sering lebih berguna daripada menambah satu grafik lagi.
Keputusan akhir harus aman dari klik bersamaan
Validasi di formulir hanya menjaga satu sisi. Dua orang bisa membuka halaman pada waktu yang hampir sama, sama-sama melihat stok cukup, lalu menyetujui permintaan yang saling bertabrakan. Karena itu, pemeriksaan akhir harus dilakukan lagi ketika data akan ditulis.
Alur persetujuan pada aplikasi ini memakai transaksi database dan penguncian baris saat memproses keputusan yang mengubah stok. Pemeriksaan status juga mencegah keputusan yang sama diproses ulang seolah-olah masih baru. Intinya bukan sekadar mencegah error, tetapi membuat satu perubahan stok memiliki satu sebab yang dapat ditelusuri.
Riwayat keputusan sama pentingnya dengan angka akhir
Ketika stok berubah, pertanyaan berikutnya biasanya bukan “berapa sekarang?” melainkan “kenapa berubah?”. Catatan pengajuan, pemeriksaan admin, keputusan kepala, serta riwayat barang masuk dan keluar memberi konteks untuk menjawabnya. Tanpa jejak ini, angka akhir terlihat rapi tetapi sulit diperiksa.
Itu sebabnya saya tidak memperlakukan halaman persetujuan sebagai aksesori admin. Halaman tersebut adalah bagian dari model data: siapa meminta, siapa memeriksa, siapa memutuskan, dan kapan stok benar-benar bergerak.
Pelajaran yang bisa dibawa ke sistem lain
Prinsip yang sama berlaku pada pembelian, peminjaman alat, pengajuan dana, atau reservasi fasilitas. Jangan biarkan satu tombol mewakili beberapa peristiwa bisnis sekaligus. Tentukan dulu kapan suatu permintaan menjadi komitmen, kapan ia hanya menahan kapasitas, dan kapan perubahan akhirnya boleh tercatat.
Jika tiga momen itu dibedakan sejak awal, tampilan dashboard, aturan validasi, dan laporan biasanya menjadi jauh lebih mudah dijelaskan. Detail implementasi dan tampilan aplikasinya ada di studi kasus sistem inventaris Rumah Plastik.