Sistem Kasir untuk Kontrol Transaksi Acara

Sistem Kasir membantu penyelenggara mengendalikan transaksi acara sejak penjualan awal hingga financial close. Fokus artikel ini adalah arsitektur pencatatan uang dan pertanggungjawaban lintas penyelenggara, tenant, vendor, sponsor, serta kanal penjualan—bukan panduan teknis mengoperasikan satu booth atau mengatur produksi panggung.

Acara dapat hanya berlangsung beberapa jam, tetapi memiliki tiket pra-acara, merchandise, makanan-minuman, add-on, deposit, voucher sponsor, refund, dan bagi hasil. Tanpa ID serta aturan settlement yang konsisten, omzet yang terlihat besar dapat sulit dijelaskan setelah acara berakhir.

Jawaban singkat

Buat ID unik untuk event, sesi, kanal, booth, tenant, produk, order, pembayaran, dan settlement. Pisahkan uang milik penyelenggara dari dana yang harus dibayarkan kepada mitra. Rekonsiliasi order ke pembayaran, refund, stok, kas, serta settlement pada checkpoint yang ditentukan.

Bekukan konfigurasi sebelum penjualan, uji skenario pengecualian, dan siapkan mode gangguan. Setelah acara, jangan menutup laporan hanya karena pintu sudah tutup; tunggu callback pembayaran, retur perangkat, penghitungan stok, klaim voucher, serta dokumen mitra selesai.

Petakan model komersial acara

Tentukan apakah penyelenggara menjual langsung, menyewakan booth, mengambil revenue share, menerima minimum guarantee, atau memakai gabungan model. Setiap hubungan harus memiliki kontrak, basis perhitungan, periode, potongan, pajak, biaya, serta jadwal settlement.

Jangan menyimpulkan kepemilikan uang dari siapa yang mengoperasikan terminal. Satu alat dapat menerima pembayaran untuk beberapa principal, tetapi ledger dan settlement harus tetap terpisah.

Bentuk dimensi pelaporan

Gunakan event ID sebagai induk, lalu session, zone, booth, terminal, shift, operator, tenant, channel, product, order, dan payment. Nama acara dapat berubah untuk pemasaran; ID tidak boleh berubah karena menjadi penghubung lintas sistem.

Product master membedakan tiket, merchandise, menu, add-on, deposit, dan biaya. Satuan serta pajak tidak boleh dibiarkan pada teks bebas. Untuk tenant, simpan merchant ID, kontrak, commission rule, rekening terverifikasi, dan status onboarding.

Informasi fitur Kasair dapat membantu mengevaluasi produk, pengguna, stok, transaksi, dan laporan. Gunakan panduan Kasair untuk simulasi alur kasir, serta Kasair POS sebagai titik awal evaluasi—kebutuhan ticketing, gate, dan settlement multi-pihak tetap harus diuji secara khusus.

Pisahkan pre-sale dan transaksi hari-H

Pre-sale memiliki lead time panjang, perubahan jadwal, e-ticket, biaya platform, dan potensi refund sebelum acara. Transaksi hari-H menuntut throughput, perangkat, koneksi, persediaan lokal, serta kontrol shift. Keduanya menggunakan event ID yang sama tetapi mempunyai risiko berbeda.

Order menyimpan channel, item, quantity, price, discount, fee, tax, buyer reference, payment status, dan fulfillment status. Jangan menandai order lunas hanya karena pelanggan kembali dari payment page; gunakan status dari penyedia pembayaran atau rekonsiliasi resmi.

Jika tiket dijual oleh partner, terima file atau API dengan schema serta cut-off yang disepakati. Catat gross sales, refund, chargeback, fee, tax, payout, dan exception. Jangan hanya menerima satu angka transfer bank.

Kelola tenant dan booth

Onboarding tenant mencakup identitas usaha, kontrak, katalog yang diizinkan, harga, pajak, komisi, rekening, akses pengguna, perangkat, dan contact person. Perubahan rekening memerlukan verifikasi independen untuk mengurangi risiko pengalihan pembayaran.

Setiap transaksi tenant menyimpan merchant ID dan booth ID. Bila satu order berisi produk dari beberapa tenant, tentukan apakah sistem mendukung split settlement atau perlu order terpisah. Dokumentasikan siapa menanggung refund, promo, payment fee, dan komplain.

Berikan tenant laporan terbatas atas transaksinya sendiri. Organizer tidak boleh mengirim spreadsheet gabungan yang mengekspos data merchant lain atau data pelanggan yang tidak diperlukan.

Rancang voucher dan hak sponsor

Voucher dapat berupa diskon, nilai uang, entitlement makanan, complimentary ticket, atau kuota staf. Setiap voucher mempunyai issuer, sponsor, scope, periode, batas penggunaan, combinability, serta settlement rule.

Kode harus sulit ditebak dan redemption menggunakan ID unik. Offline redemption perlu membagi daftar atau quota agar satu token tidak dipakai serentak di dua booth. Setelah koneksi pulih, konflik masuk exception queue—bukan dihapus tanpa jejak.

Untuk voucher sponsor, laporan klaim memuat voucher issued, activated, redeemed, expired, cancelled, nilai, lokasi, merchant, serta bukti aturan. Sponsor membayar berdasarkan definisi kontrak, bukan sekadar jumlah kode yang dibuat.

Kendalikan perangkat dan shift

Inventaris mencatat terminal, printer, scanner, charger, router, cash drawer, serial number, lokasi, penanggung jawab, waktu serah terima, dan kondisi. Akun digunakan per individu atau per role yang dapat ditelusuri; password bersama membuat void dan refund sulit diselidiki.

Opening shift memverifikasi perangkat, katalog, harga, stok, koneksi, metode pembayaran, kas awal, serta test receipt. Closing shift membandingkan sales, cash expected, cash counted, non-cash, void, refund, tip, dan exception.

Cash drop dilakukan bila saldo melewati batas. Setiap perpindahan memakai dual count, bag ID, waktu, pihak menyerahkan, pihak menerima, dan tujuan. Keselamatan fisik harus disusun bersama pengelola venue serta petugas yang kompeten.

Antisipasi koneksi padat

Jaringan yang bekerja saat venue kosong dapat gagal saat ribuan perangkat aktif. Uji pada lokasi, jam, dan beban yang representatif. Pisahkan jaringan operasional bila memungkinkan dan siapkan operator atau teknologi cadangan.

Tentukan fungsi yang boleh offline: melihat katalog lokal, membuat order ber-ID unik, atau menerima metode tertentu. Transaksi pembayaran offline mempunyai risiko dan aturan penyedia masing-masing. Jangan menyatakan pembayaran berhasil sebelum bukti otorisasi yang sah tersedia.

Skenario latihan setidaknya mencakup:

1. Internet utama putus.

2. Terminal atau printer gagal.

3. QR atau barcode tidak terbaca.

4. Harga salah setelah pintu dibuka.

5. Pembayaran pending dan pelanggan mencoba ulang.

6. Booth berpindah lokasi.

7. Voucher terdeteksi ganda.

8. Acara berhenti atau dijadwal ulang.

Setiap skenario mempunyai decision owner, jalur komunikasi, bukti yang dicatat, dan prosedur pemulihan.

Tangani refund dan perubahan acara

Kebijakan harus terlihat sebelum pembelian: perubahan line-up, reschedule, cancel, force majeure, barang rusak, order ganda, serta tenggat klaim. Sistem menyimpan original order, alasan, approval, nilai, metode, payment reference, dan refund reference.

Refund tidak selalu selesai ketika tombol ditekan. Pantau requested, approved, submitted, processed, failed, dan settled. Informasikan estimasi secara jujur kepada pelanggan. Dana yang belum selesai tetap berada pada daftar kewajiban atau exception.

Untuk pembatalan massal, jangan mengekspor data lalu memproses tanpa kontrol. Gunakan batch ID, maker-checker, total yang diharapkan, hasil per transaksi, retry aman, serta rekonsiliasi bank.

Bangun settlement mitra

Settlement statement harus dapat direproduksi dari transaksi. Mulai dengan gross valid sales, lalu tampilkan refund, chargeback, discount allocation, tax, commission, payment fee, advance, penalty yang sah, serta net payable.

Tenant diberi periode review dan jalur dispute. Adjustment setelah statement dikunci menggunakan dokumen koreksi; jangan mengubah diam-diam laporan lama.

Lakukan financial close bertahap

Gunakan soft close pada akhir shift untuk melihat selisih awal, preliminary close setelah seluruh booth ditutup, dan final close setelah payment, refund, stok, serta partner file lengkap. Status laporan mencegah angka sementara diperlakukan sebagai hasil final.

Closing pack minimal berisi ringkasan penjualan, metode pembayaran, kas, refund, void, diskon, voucher, stok, incident log, receivable, payable, settlement tenant, dan daftar exception. Setiap angka mempunyai owner dan sumber.

Pelindungan data pelanggan, staf, dan tenant perlu mengikuti Undang-Undang Pelindungan Data Pribadi. Batasi akses serta retensi, terutama pada ekspor yang tersebar setelah acara.

Evaluasi ekonomi acara

Omzet bukan keuntungan. Hitung payment fee, komisi kanal, venue, produksi, keamanan, staf, perangkat, jaringan, transportasi, waste, refund, chargeback, pajak, dan settlement mitra. Pisahkan biaya tetap serta variabel agar perbandingan antarevent lebih adil.

Pantau net revenue, contribution margin, revenue per attendee, average transaction, attach rate, stock loss, refund rate, payment failure, queue time, dan settlement ageing. Catat cuaca, perubahan jadwal, kapasitas, serta insiden sebagai konteks; jangan mengklaim sebab-akibat hanya dari korelasi.

Rencana implementasi

Enam hingga delapan minggu sebelum acara, tetapkan model komersial, kontrak, dimensi data, metode pembayaran, dan pemilik proses. Empat minggu sebelumnya, onboarding tenant, katalog, rekening, serta perangkat. Dua minggu sebelumnya, bekukan perubahan besar dan lakukan simulasi end-to-end.

Pada hari-H, operasikan command center untuk transaksi, jaringan, perangkat, stok, dan incident. Setelah acara, jalankan close sesuai cut-off, terbitkan statement, selesaikan dispute, dan simpan post-event review. Jangan mengandalkan ingatan; catat keputusan serta bukti saat kejadian berlangsung.

FAQ

Apakah POS dapat menggantikan sistem ticketing?

Tidak selalu. Ticketing menangani kapasitas, identitas tiket, dan akses. Integrasikan bila perlu, tetapi tetapkan sumber data masing-masing.

Bagaimana membedakan omzet organizer dan tenant?

Gunakan merchant ID, kontrak, product ownership, commission rule, serta settlement ledger pada setiap transaksi.

Kapan laporan acara boleh dianggap final?

Setelah pembayaran, refund, kas, stok, partner file, dan exception direkonsiliasi sesuai cut-off yang disepakati.

Bagaimana jika jaringan mati?

Aktifkan hanya fungsi offline yang telah diuji, gunakan ID unik, batasi risiko pembayaran, dan rekonsiliasi setelah koneksi pulih.

Apa fungsi voucher sponsor dalam laporan?

Voucher memerlukan issuer, redemption valid, nilai, merchant, serta aturan klaim agar hak sponsor dan pembayaran dapat dibuktikan.

Data apa yang diberikan kepada tenant?

Berikan transaksi serta perhitungan miliknya sendiri, dengan data pelanggan diminimalkan dan akses merchant lain tertutup.

Sistem Kasir untuk acara harus menghasilkan jejak dari order hingga settlement, bukan hanya struk saat keramaian. Identitas yang konsisten, kontrol tenant, kesiapan gangguan, refund tertib, dan financial close bertahap membuat semua pihak dapat memahami uang yang diterima, dimiliki, dan masih harus diselesaikan.