Bagi Hasil Otomatis Dihitung Sejak Item Dipesan

Mengelola food court berarti mengelola banyak usaha kecil sekaligus. Setiap stall punya menu sendiri, omzet sendiri, dan kesepakatan bagi hasil sendiri, tetapi pembayaran sering masuk lewat satu kasir terpusat.

Pertanyaan yang menentukan seberapa panjang malam Anda bukan berapa persentase komisinya, melainkan pada detik ke berapa angka bagi hasil itu dihitung. Ada dua jawaban saja: dihitung saat transaksi terjadi, atau disusun ulang setelah tutup. Tulisan ini membahas jarak di antara keduanya, dan kenapa jarak itu tidak bisa ditutup dengan bekerja lebih teliti.

Masalahnya: rekap manual

Tanpa sistem yang tepat, pengelola menghitung ulang penjualan tiap stall setiap malam: mengumpulkan struk, mencocokkan angka kasir, lalu menghitung komisi di spreadsheet. Prosesnya lambat dan rawan salah. Satu angka keliru, tenant kehilangan kepercayaan.

Yang memberatkan sebenarnya bukan jumlah barisnya. Ratusan baris bisa dijumlahkan dengan cepat. Yang memakan waktu adalah baris yang tidak jelas miliknya siapa: menu dengan nama mirip di dua stall, item yang berpindah dari satu pesanan ke pesanan lain, dan transaksi yang batal di tengah jalan. Setiap baris seperti itu berhenti menjadi penjumlahan dan berubah menjadi penyelidikan kecil, dan Anda mengerjakannya pada jam ketika ingatan semua orang sudah paling lemah.

Identitas stall melekat pada item, bukan disusun ulang dari struk

Inti dari pendekatan yang lain hanya satu kalimat: saat kasir memasukkan sebuah item ke pesanan, item itu sudah membawa identitas stall-nya. Bukan sebagai kategori menu yang mirip nama stall, dan bukan sebagai catatan di kolom keterangan, melainkan sebagai bagian dari baris pesanan itu sendiri.

Perbedaannya terlihat saat sesuatu berubah. Jika identitas stall hanya melekat pada struk, maka yang Anda punya di akhir hari adalah sekumpulan struk dengan total, dan pembagian ke stall harus ditebak dari nama menu. Jika identitas itu melekat pada baris, setiap baris bisa ditanyai sendiri: item ini milik stall mana, harganya berapa saat itu, dan apakah ia bertahan sampai pembayaran.

Dari situ, bagi hasil berhenti menjadi pekerjaan tersendiri. Ia menjadi sifat dari data yang sudah ada. Pilihan antara kasir terpusat dan kasir per stall pun berubah menjadi pilihan operasional biasa, bukan penentu seberapa berat rekap Anda, selama keduanya menulis ke catatan yang sama. Syarat itu perlu Anda periksa sendiri, dan pertimbangan memilih di antara keduanya dibahas di panduan mengelola food court.

Saat pesanan diubah di tengah jalan

Pesanan yang tidak pernah berubah adalah pesanan yang jarang ada. Pelanggan menambah minuman setelah makanan sudah masuk. Satu porsi dibatalkan karena stall-nya kehabisan bahan. Item dari stall lain ditambahkan ke pesanan yang sama, dan pembayarannya tetap sekali di kasir terpusat.

Di sistem yang menyimpan identitas per baris, perubahan itu tidak menimbulkan pertanyaan baru. Baris yang ditambahkan membawa stall barunya sendiri, dan baris yang dihapus berhenti dihitung untuk stall asalnya. Total pesanan berubah, tetapi komposisinya tetap bisa dibaca. Grafena POS memungkinkan kasir mengubah pesanan langsung di meja, dan setiap perubahan tetap mempertahankan asal tiap item.

Di rekap malam, perubahan yang sama meninggalkan jejak yang jauh lebih miskin. Yang tersisa hanyalah bentuk akhir pesanan itu. Anda tidak bisa membedakan pesanan yang sejak awal berisi dua item dari pesanan yang sempat berisi lima lalu menyusut, dan Anda juga tidak bisa tahu stall mana yang item-nya dicabut. Yang Anda lakukan akhirnya adalah menghitung bentuk akhirnya saja, lalu berharap kasirnya masih ingat jika ada tenant yang bertanya.

Saat transaksi dibatalkan

Pembatalan tidak mengurangi satu angka, ia mengurangi angka milik satu stall. Jika satu pesanan berisi item dari tiga stall dan hanya satu item yang dibatalkan, yang berkurang hanyalah omzet stall pemilik item itu. Dua stall lainnya tidak boleh ikut terpotong, dan tidak boleh pula dibiarkan menanggung komisi atas penjualan yang tidak pernah terjadi.

Alamat pengurangan itu ditentukan pada detik pembatalan, bukan pada malam hari. Saat kasir membatalkan sebuah item, baris yang dibatalkan masih membawa stall-nya, jadi tidak ada yang perlu ditebak. Setelah tutup, yang tersisa hanyalah selisih antara apa yang sempat dipesan dan apa yang akhirnya dibayar, dan selisih itu tidak menyebut nama stall mana pun. Di situlah rekap manual menaruh pengurangannya di tingkat transaksi, lalu membaginya rata atau menebaknya, dan kedua jalan itu keliru dengan cara yang tidak bisa diperiksa tenant.

Perbedaan antara void dan retur, siapa yang boleh menyetujui pembatalan, dan apa yang sebaiknya disebut di kontrak tenant dibahas di panduan mengelola food court.

Kenapa rekap malam tidak bisa menyusun ulang keduanya

Perubahan pesanan dan pembatalan punya satu kesamaan: keduanya adalah peristiwa, bukan keadaan. Peristiwa hanya terlihat oleh sistem yang sedang menonton saat ia terjadi. Rekap malam datang setelah semuanya selesai dan hanya melihat hasil akhirnya, sehingga informasi yang dibutuhkan bagi hasil sudah hilang sebelum pekerjaan rekap dimulai.

Karena itu, ketelitian tidak menyelesaikan masalah ini. Anda bisa mengerjakan rekap dua kali dan tetap mendapat angka yang sama-sama tidak bisa dipertanggungjawabkan, karena yang kurang bukan usaha, melainkan data. Inilah sebabnya perselisihan dengan tenant biasanya tidak selesai dengan menghitung ulang: kedua pihak menghitung dari daftar transaksi yang sama-sama tidak lengkap.

Komisi dihitung dari kesepakatan, bukan dari ingatan

Setengah lainnya dari pekerjaan ini adalah persentasenya. Persentase komisi tiap stall adalah isi kontrak, dan tempatnya bukan di kepala Anda atau di satu tab spreadsheet yang hanya Anda yang tahu rumusnya. Grafena POS menyimpan kesepakatan itu di sistem dan menghitung bagi hasil per stall otomatis untuk setiap transaksi, termasuk ketika tiap stall punya persentase yang berbeda.

Jika Anda sedang menyusun atau meninjau angka itu, uji dampaknya lebih dulu. Kalkulator bagi hasil menghitung dengan rumus yang sama seperti laporan, sehingga Anda bisa melihat sisa untuk kedua pihak sebelum angkanya masuk ke kontrak tenant.

Laporan malam yang sudah jadi

Jika ketiga hal di atas berjalan, laporan akhir hari berhenti menjadi pekerjaan baru. Penjualan kotor, komisi, dan hak tenant sudah terbentuk sepanjang hari, dan yang Anda lakukan hanyalah membukanya. Waktu yang tadinya habis untuk menyusun angka berpindah ke hal yang memang butuh penilaian Anda: stall yang angkanya jauh dari kebiasaannya, jumlah void yang tidak wajar, dan selisih kas yang perlu ditanyakan malam itu juga.

Efek keduanya ada di sisi tenant. Setiap stall bisa membuka laporannya sendiri tanpa melihat stall lain, sehingga transparansi tidak berubah menjadi saling intip. Tenant yang bisa memeriksa angkanya sendiri lebih jarang mempertanyakan totalnya, dan jika ia tetap bertanya, pertanyaannya menjadi spesifik pada satu transaksi, bukan pada seluruh bulan.

Jangan lupakan offline

Food court ramai justru saat jaringan padat. Pastikan aplikasi kasir Anda tetap bisa mencatat transaksi saat internet mati, lalu menyinkronkan datanya sendiri saat koneksi kembali. Di Grafena POS, transaksi dicatat di perangkat sebelum dikirim ke mana pun, jadi transaksi tetap jalan tanpa internet dan antrean tidak berhenti karena jaringan.

Untuk bagi hasil, satu aturan mengikutinya: jalankan laporan setelah semua perangkat selesai tersinkron, bukan di tengah gangguan. Catatan kertas yang sempat dibuat berguna sebagai pembanding, bukan sebagai sumber angka.

Grafena POS dibangun untuk pola ini: pencatatan per stall, bagi hasil otomatis, kasir terpusat, dan mode offline penuh. Halaman food court menunjukkan layar-layarnya satu per satu, dari kasir sampai laporan per stall.