Kenapa Rekap Bagi Hasil Food Court Selalu Salah di Spreadsheet

Skema bagi hasil adalah jantung bisnis food court: pengelola menyediakan tempat dan kasir, tenant menyediakan makanan, lalu omzet dibagi sesuai kesepakatan, umumnya potongan 10–30% dari penjualan kotor tiap stall. Itu rentang yang umum disebut, bukan patokan baku, dan faktor yang menggerakkannya dibahas di bagian model bagi hasil pada panduan mengelola food court.

Hampir semua pengelola memulainya dengan spreadsheet, dan itu keputusan yang masuk akal. Spreadsheet gratis, sudah ada di komputer Anda, dan rumusnya bisa ditulis dalam satu menit. Yang jarang disadari adalah bahwa pekerjaan yang berat bukan rumusnya, melainkan memasukkan data yang benar ke dalamnya setiap malam.

Rumusnya bukan bagian yang sulit

Hak tenant = penjualan kotor stall − (penjualan kotor × persentase komisi). Persentase komisinya adalah angka yang Anda sepakati dengan tiap stall, di dalam rentang yang disebut di atas. Jika Anda hanya perlu menghitungnya, kalkulator bagi hasil menghitungkan untuk tiap stall, termasuk totalnya.

Rumus itu tidak pernah menjadi sumber perselisihan. Tenant tidak meragukan cara Anda mengalikan. Yang mereka ragukan adalah angka penjualan kotor yang Anda masukkan ke rumus itu, dan angka itu adalah hasil dari pekerjaan yang jauh lebih panjang daripada perkalian.

Yang membuatnya rumit bukan rumusnya, tapi datanya:

• Volume. Ratusan transaksi per hari, masing-masing bisa berisi item dari beberapa stall sekaligus.
• Pembatalan. Void dan retur harus mengurangi omzet stall yang tepat. Jika tidak, tenant dipotong komisi untuk penjualan yang batal.
• Waktu. Rekap harus selesai malam itu juga; tenant menunggu setorannya.

Ketiganya layak dibahas satu per satu, karena masing-masing menghasilkan jenis kesalahan yang berbeda, dan ketiganya berakhir di tempat yang sama: setoran yang tidak cocok dengan catatan tenant.

Volume: satu transaksi bukan satu baris

Kesulitan pertama muncul sebelum penjumlahan dimulai. Satu pembayaran di kasir terpusat bisa berisi nasi dari satu stall dan minuman dari stall lain, sehingga satu transaksi sebenarnya adalah beberapa baris yang harus dipisahkan lebih dulu. Selama pemisahan itu dikerjakan manusia, ia menjadi pekerjaan penyalinan berulang pada jam paling larut.

Kegagalan yang dihasilkannya selalu mirip. Baris disalin, lalu rentang rumus di bawahnya tidak ikut melebar, sehingga sepuluh baris terakhir hari itu tidak pernah masuk hitungan siapa pun. Kolom diurutkan untuk merapikan tampilan, dan nama stall ikut berpindah sementara angkanya tetap di tempat. Filter ditinggalkan aktif dari pekerjaan kemarin, dan penjumlahan hanya mencakup baris yang kebetulan terlihat. Tidak satu pun dari kesalahan ini menimbulkan pesan galat. Semuanya menghasilkan angka yang kelihatan wajar, dan itulah yang membuatnya bertahan sampai tenant menghitung sendiri.

Pencocokan berdasarkan nama menu memperparah keadaan. Dua stall yang sama-sama menjual es teh membuat pencarian nama mengembalikan stall pertama yang ditemukan, bukan stall yang benar. Selisihnya kecil setiap hari dan konsisten ke arah yang sama, sehingga baru terlihat pada akhir bulan, ketika menelusurinya berarti membuka kembali tiga puluh lembar kerja.

Pembatalan: pengurangan yang salah alamat

Kesulitan kedua lebih halus. Void dan retur biasanya masuk ke spreadsheet sebagai satu angka di tingkat transaksi, karena begitulah bentuknya di rekap kasir. Satu angka di tingkat transaksi tidak tahu item mana yang dibatalkan, jadi pengurangannya mendarat di total, bukan di stall pemilik item itu.

Akibatnya berjalan ke dua arah sekaligus. Stall yang item-nya dibatalkan tetap dipotong komisi untuk penjualan yang tidak pernah terjadi, dan dua stall lain di transaksi yang sama ikut kehilangan omzet yang sebenarnya sah. Tidak ada yang dirugikan secara mencolok pada satu transaksi, tetapi ketiga tenant menerima angka yang tidak bisa mereka cocokkan dengan catatan mereka sendiri.

Yang membuat kesalahan ini sulit diperbaiki di spreadsheet adalah informasinya memang tidak ada di sana. Anda tidak bisa membagi sesuatu yang tidak pernah dicatat per stall. Perbedaan antara void dan retur, dan kenapa keduanya harus mengenai stall yang tepat, dibahas lebih lengkap di panduan mengelola food court.

Tenggat: rekap yang dikerjakan saat semua orang sudah lelah

Kesulitan ketiga bukan soal data, melainkan soal jam. Rekap harus selesai malam itu juga karena tenant menunggu setorannya, dan malam itu juga adalah waktu ketika kasir sudah pulang, ingatan sudah kabur, dan Anda sudah bekerja sejak pagi.

Tenggat mengubah cara Anda bekerja, bukan hanya kecepatannya. Pemeriksaan silang yang biasanya Anda lakukan dilewati karena angkanya sudah mendekati. Selisih kecil ditutup dengan satu penyesuaian manual supaya totalnya rapi, dan penyesuaian itu tidak pernah dicatat alasannya. Sebulan kemudian, penyesuaian itulah satu-satunya baris yang tidak bisa Anda jelaskan kepada siapa pun.

Tenggat juga membuat kesalahan menjadi permanen. Rekap yang sudah dikirim ke tenant berubah menjadi angka resmi, dan memperbaikinya minggu depan berarti menarik kembali angka yang sudah dipakai tenant untuk pembukuannya sendiri. Kebanyakan pengelola memilih tidak memperbaikinya, dan selisih itu ikut terbawa ke bulan berikutnya.

Kenapa spreadsheet selalu bermasalah

Excel tidak tahu transaksi mana milik stall mana. Seseorang harus memasukkannya, setiap malam, tanpa salah ketik. Void yang lupa dicatat, baris yang tergeser, rumus yang tertimpa: satu kesalahan kecil berarti setoran yang salah dan tenant yang kecewa. Dan saat food court makin ramai, beban rekapnya ikut tumbuh.

Pertumbuhan itu yang paling sering mengejutkan. Beban rekap tidak naik seiring jumlah transaksi saja, tetapi seiring jumlah pasangan stall yang bisa muncul dalam satu pembayaran. Stall keempat tidak menambah seperempat pekerjaan, ia menambah lebih dari itu, dan penambahan itu jatuh seluruhnya pada satu orang yang sama.

Ada satu keterbatasan lain yang jarang disebut: sebuah sel hanya menyimpan hasilnya. Saat tenant bertanya kenapa angkanya sekian, yang bisa Anda tunjukkan adalah rumus dan totalnya, bukan daftar transaksi yang menghasilkannya. Untuk menjawab satu pertanyaan, Anda menyusun ulang jejaknya dari lembar kerja kemarin, dan jawaban itu tetap berupa penjelasan Anda sendiri, bukan catatan yang bisa diperiksa tenant tanpa bantuan Anda. Perselisihan yang seharusnya selesai dalam satu menit berubah menjadi pekerjaan setengah hari.

Alternatifnya: hitung di sumbernya

Jika kasir mencatat identitas stall pada setiap item sejak awal, bagi hasil bukan lagi pekerjaan malam hari. Laporannya terbentuk sendiri, termasuk pengurangan dari void dan retur.

Itulah pendekatan Grafena POS: setiap penjualan tercatat per stall, komisi terhitung otomatis, dan laporan per tenant siap setiap malam. Tablet kasir tiap stall hanya menampilkan penjualan stall itu, dan laporan penjualan dapat diekspor ke CSV atau PDF, jadi tenant punya lampiran yang sama untuk pembukuannya dan Anda punya lampiran yang sama untuk tagihan akhir bulan.

Perpindahannya tidak menghapus spreadsheet dari hidup Anda, dan tidak perlu. Yang berubah adalah apa yang Anda kerjakan di dalamnya. Spreadsheet berhenti menjadi tempat data disusun, dan menjadi tempat data yang sudah benar dianalisis.

Jika pembayarannya juga terpusat, cara kasir terpusat membagi satu pembayaran ke banyak stall menjelaskan sisanya.