Cara Membuat PRD Aplikasi Kasir & Toko Online yang Lengkap

Kebanyakan draft PRD aplikasi kasir atau toko online berhenti di jalur bahagia: pelanggan lihat produk, masukin keranjang, checkout, transaksi tersimpan, selesai. Enak dibaca, gampang dibayangin, dan itu memang bagian paling penting. Masalahnya, aplikasi kasir sungguhan ketemu situasi yang nggak sebahagia itu tiap hari: dua orang checkout barang yang stoknya tinggal satu di detik yang sama, harga berubah pas promo abis di tengah proses bayar, atau saldo kepotong tapi status transaksinya nggantung.

Kalau kasus-kasus ini nggak ditulis di PRD, agent coding-mu cuma bakal ngoding jalur bahagianya. Bukan karena agentnya males, tapi karena dia nggak tahu kasus itu perlu dipikirkan sampai kamu yang bilang.

Satu hal dulu sebelum lanjut. Artikel ini beda dari cara membuat aplikasi kasir dengan Google Spreadsheet yang sudah ada di Skematik. Panduan itu bahas implementasi teknis spesifik di Google Apps Script, lengkap kode Code.gs dan HTML-nya. Artikel ini sudut pandangnya beda: fokusnya ke proses nulis PRD kasir dan toko online secara umum, platform apa saja, entah itu GAS, Next.js, atau aplikasi mobile.

Kalau platform yang kamu incar memang GAS, dua artikel ini saling melengkapi: baca yang ini buat proses PRD-nya, baca yang itu buat lihat implementasinya jadi kode. Kalau kamu malah belum tahu platform mana yang mau dipakai, mulai dari sini dulu. Skema data dan kasus tepi di bawah ini bentuknya tetap sama, apa pun teknologi yang akhirnya kamu pilih.

Kunci skema data dulu: produk, stok, transaksi

Sebelum masuk ke kasus tepi, PRD-mu harus tegas soal tiga entitas inti ini. Nggak perlu bikin skema selengkap enterprise, cukup jelas dan konsisten.

• Produk: nama, harga, stok tersedia, dan status aktif atau nonaktif, biar produk yang habis nggak langsung dihapus, cukup disembunyikan
• Stok: bukan cuma angka statis, tapi juga riwayat perubahannya, berkurang karena penjualan, retur, atau koreksi manual
• Transaksi: item yang dibeli, jumlah, harga per item saat transaksi itu terjadi (bukan link ke harga produk sekarang), status, dan waktu

Poin terakhir ini penting. Harga di baris transaksi harus disimpan sebagai angka beku saat itu terjadi, bukan referensi ke harga produk yang bisa berubah kapan saja. Ini juga fondasi buat kasus tepi kedua di bawah.

Kalau kamu mau cek aplikasi yang sudah berjalan, lihat transaksi lamanya: kalau kolom harga di situ keisi angka yang sama persis dengan harga produk sekarang padahal transaksinya bulan lalu, itu tanda harganya belum dipotret sebagai angka beku.

Tiga kasus tepi yang wajib jadi task, bukan cuma asumsi di kepala

Ini bagian yang paling sering bikin PRD kasir gagal di lapangan. Bukan karena lupa, tapi karena kasusnya cuma "diketahui" si penulis PRD, nggak pernah dituliskan sebagai task eksplisit yang wajib dikerjakan agent-nya.

1. Stok minus: dua pembeli, satu barang terakhir

Kalau stok tinggal satu dan dua pembeli checkout hampir bersamaan, tanpa penjagaan keduanya bisa sama-sama "berhasil" dan stok jadi minus satu. PRD-mu harus nulis eksplisit: pengecekan dan pengurangan stok wajib jadi satu operasi yang nggak bisa diselak transaksi lain di tengah jalan, dan kalau stoknya ternyata sudah habis duluan, transaksi kedua wajib gagal dengan pesan yang jelas, bukan diam-diam saldo kepotong tapi barangnya nggak ada.

2. Harga berubah di tengah proses checkout

Pelanggan buka halaman produk waktu masih promo, taruh di keranjang, tapi pas beneran bayar sepuluh menit kemudian promonya udah abis atau admin baru saja naikin harga. PRD-mu harus tegas: total akhir dihitung ulang pakai harga yang berlaku saat checkout final, bukan harga yang nempel di keranjang sejak awal. Kalau harganya berubah, kasih tahu pelanggan sebelum pembayaran diproses, jangan langsung potong dengan harga baru diam-diam.

3. Pembayaran dobel atau gagal-tapi-kepotong

Pelanggan nekan tombol bayar dua kali karena loading lama, atau notifikasi dari payment gateway telat masuk padahal saldo udah kepotong. PRD-mu wajib nyebut penanganan ini: satu transaksi harus punya nomor referensi unik biar percobaan bayar yang sama nggak diproses dua kali, dan ada jalur buat transaksi yang statusnya nggantung, dicek ulang ke payment gateway, bukan langsung dianggap gagal atau langsung dianggap berhasil. Kalau payment gateway-nya nyediain webhook status, PRD juga harus nyebut siapa yang jadi sumber kebenaran terakhir: status dari webhook itu, bukan status yang keburu diasumsikan di sisi aplikasi.

Alur diskon dan promo, kalau ada

Kalau tokomu pakai diskon atau promo, PRD wajib jelasin jenisnya dari awal: potongan persentase atau nominal tetap, berlaku ke produk tertentu atau semua produk, ada minimum belanja atau enggak, dan boleh tidaknya digabung dengan promo lain. Tanpa ini ditulis, agent bakal milih salah satu aturan sendiri, dan yang paling sering dipilih adalah "semua promo bisa numpuk", yang biasanya bukan itu yang kamu mau.

Laporan penjualan dasar

Terakhir, sebutkan laporan minimal yang kamu butuh: omzet harian atau mingguan, produk paling laku, dan cara ekspornya (unduh CSV biasanya cukup buat toko kecil-menengah). Nggak perlu dashboard analitik canggih di versi pertama, tapi kalau nggak disebut sama sekali, laporan ini sering ketinggalan sampai kamu baru sadar butuh pas mau tutup buku bulanan.

PRD kasir atau toko online yang lengkap bukan yang paling tebal. Yang penting skema datanya jelas, tiga kasus tepi di atas jadi task tertulis, dan alur promo plus laporan udah disebut dari awal. Itu bedanya antara toko yang laporannya rapi dan toko yang WA admin-nya rame tiap ada komplain stok minus.