Kasir Terpusat Food Court: Satu Pembayaran untuk Banyak Stall

Di food court, satu pelanggan sering memesan dari lebih dari satu stall: nasi dari satu tenant, minuman dari tenant lain. Jika tiap stall punya kasir sendiri-sendiri, pelanggan harus antre dan bayar berkali-kali. Kasir terpusat menyelesaikan ini: satu kasir menerima semua pesanan, pelanggan bayar sekali.

Masalahnya bukan cuma antrean

Tantangan sebenarnya muncul di belakang layar. Jika satu pembayaran mencakup pesanan dari tiga stall, siapa yang mencatat penjualan yang mana? Bagaimana jika ada promo yang cuma berlaku untuk satu stall? Jika dibulatkan, dibulatkan di mana, per stall atau sekali di total akhir? Tanpa sistem yang tepat, jawaban sederhananya adalah rekap manual lagi, persis masalah bagi hasil yang sudah dibahas sebelumnya.

Pertanyaan-pertanyaan itu tampak teknis, tetapi semuanya berakhir di tempat yang sama: berapa yang Anda setorkan ke tiap tenant pada akhir bulan. Kasir terpusat yang tidak menjawabnya hanya memindahkan antrean pelanggan menjadi pekerjaan malam Anda.

Cara kerja kasir terpusat di Grafena

1. Stall mengirim pesanan ke kasir, bukan menagih sendiri. Saat stall menekan “Kirim ke kasir”, pesanan itu masuk ke papan kasir terpusat secara langsung, dan diperbarui lagi setiap kali pesanan diubah.
2. Kasir mengambil alih pesanan itu. Kasir mengklaim pesanan yang mau diproses, supaya dua kasir tidak menagih pelanggan yang sama dua kali.
3. Satu pembayaran, struk tetap per stall. Pelanggan bayar sekali di kasir, tapi sistem tetap menerbitkan struk terpisah untuk tiap stall dalam satu kelompok penyelesaian, lengkap dengan struk gabungan untuk pelanggan.
4. Promo dan pembulatan tetap benar. Promo yang berlaku untuk satu stall tetap dihitung per pesanan asalnya, dan pembulatan Rupiah dilakukan sekali di total akhir, bukan berulang di tiap pesanan, yang biasanya jadi sumber selisih kecil yang sulit dilacak.
5. Stall langsung tahu pesanannya sudah dibayar. Begitu kasir berhasil memproses pembayaran, layar stall ikut memperbarui status pesanan itu jadi lunas, tidak perlu menagih ulang atau menanyakan ke kasir.

Lima langkah itu singkat di daftar dan menentukan banyak hal di lapangan. Tiga di antaranya layak dibahas lebih panjang.

Papan kasir dan alasan pesanan perlu diklaim

Papan kasir terpusat menampilkan pesanan yang sudah dikirim stall dan belum dibayar. Selama papan itu hanya dilihat satu kasir, urutannya tidak pernah menjadi masalah. Begitu ada dua titik bayar di jam makan siang, papan yang sama dilihat dua orang sekaligus, dan keduanya bisa memilih pesanan yang sama dalam selisih beberapa detik.

Karena itu pesanan perlu diklaim sebelum ditagih. Klaim adalah cara sistem menyatakan bahwa satu pesanan sedang ditangani satu kasir, dan bahwa kasir lain sebaiknya mengambil pesanan berikutnya. Tanpa langkah itu, pelanggan bisa ditagih dua kali untuk pesanan yang sama, dan kedua penagihan itu sama-sama terlihat sah di laporan malam.

Yang perlu Anda sepakati dengan kasir adalah kebiasaannya, bukan hanya mekanismenya. Klaim pesanan sebelum memanggil pelanggan, bukan sesudahnya. Jika sebuah pesanan sudah diklaim kasir lain, ambil pesanan berikutnya dan biarkan kasir itu menyelesaikannya, alih-alih menunggu di depan pesanan yang sama.

Saat dua kasir mengklaim satu pesanan

Klaim mengurangi kemungkinan tabrakan, tetapi tidak menghapusnya. Dua kasir bisa menekan pesanan yang sama hampir bersamaan, dan jaringan food court yang padat membuat jarak beberapa detik itu nyata.

Yang terjadi kemudian sederhana. Satu klaim menang, dan pesanan itu menjadi milik satu kasir sampai pembayarannya selesai. Klaim yang lain kalah, dan pesanan itu tidak lagi bisa diproses oleh kasir kedua. Aturan praktis untuk kasir Anda satu kalimat: pesanan yang sudah ditangani orang lain tidak perlu dikejar.

Yang lebih penting adalah apa yang terjadi pada uang jika kasir kedua sempat menerima pembayaran sebelum kalah klaim. Struk yang kalah klaim ditandai perlu ditindaklanjuti lewat alur retur, bukan dibiarkan sebagai data yang tidak jelas statusnya. Retur itu sendiri meminta PIN manajer, sehingga penyelesaiannya meninggalkan catatan tentang siapa yang menyetujuinya, dan angka stall yang terkait ikut dikoreksi di laporan, bukan hanya di laci.

Untuk Anda sebagai pengelola, kejadian seperti ini adalah alasan memeriksa daftar void dan retur setiap malam, saat kasirnya masih ada di tempat. Kebiasaan itu dan sisa urutan tutup malam ada di panduan mengelola food court.

Satu pembayaran, struk yang tetap bisa ditelusuri

Pelanggan hanya membutuhkan satu struk gabungan, dan itulah yang ia bawa dari meja kasir. Tenant membutuhkan yang lain: bukti bahwa item miliknyalah yang terjual, dengan harga yang ia tetapkan, pada transaksi yang bisa ditunjuk.

Karena itu struk per stall bukan formalitas. Ia adalah versi kecil dari laporan bulanan, diterbitkan saat kejadiannya masih segar. Stall yang menerima struknya sendiri di hari yang sama bisa menemukan keganjilan ketika kasirnya masih ingat, alih-alih menanyakannya empat minggu kemudian lewat satu angka total.

Untuk Anda, manfaatnya muncul saat menelusuri selisih. Satu kelompok penyelesaian mengikat struk gabungan pelanggan dan struk tiap stall menjadi satu rangkaian, sehingga pertanyaan tentang satu stall tidak mengharuskan Anda membuka seluruh transaksi hari itu.

Kenapa pembulatan dilakukan sekali di akhir

Pembulatan terdengar seperti detail yang tidak layak dibahas, sampai Anda mencocokkan laci kasir dengan laporan. Jika satu pembayaran berisi pesanan dari tiga stall dan tiap pesanan dibulatkan sendiri-sendiri, jumlah dari ketiganya belum tentu sama dengan hasil pembulatan total yang sebenarnya dibayar pelanggan. Selisihnya kecil, tetapi ia muncul pada setiap transaksi gabungan, dan arahnya tidak selalu sama.

Selisih seperti itu paling merepotkan karena tidak punya pemilik. Ia bukan kesalahan kasir, bukan kelebihan bayar pelanggan, dan bukan milik satu stall tertentu. Saat Anda menelusurinya di akhir bulan, yang Anda cari adalah sesuatu yang tidak pernah terjadi sebagai satu peristiwa.

Membulatkan sekali di total akhir menghapus sumbernya. Pelanggan membayar satu angka, dan angka itulah yang dibagi kembali ke stall, sehingga jumlah bagian tiap stall selalu sama dengan uang yang benar-benar diterima. Promo mengikuti aturan yang sama: ia tetap melekat pada pesanan stall asalnya, sehingga potongan tidak menyebar ke tenant yang tidak menawarkannya.

Tetap satu prinsip: offline dulu, sinkron kemudian

Kasir terpusat tetap mengikuti cara kerja dasar Grafena POS: setiap pesanan dan pembayaran tercatat dulu di perangkat, baru disinkronkan. Jaringan food court yang padat saat jam makan siang bukan alasan pelanggan harus menunggu.

Konsekuensinya perlu Anda ketahui sejak awal. Selama gangguan, papan kasir bisa tertinggal beberapa detik dari kenyataan, sehingga klaim dan status lunas baru seragam setelah semua perangkat tersinkron. Jalankan laporan per stall setelah sinkronisasi selesai, bukan di tengah gangguan, dan angka yang Anda pakai untuk bagi hasil akan sama dengan yang dilihat tenant. Layar-layar yang disebut di tulisan ini bisa dilihat satu per satu di halaman food court.