Solusi yang Anda cari akan bergantung pada model gaya akuntansi dan beberapa tagihan bahan (BOM). Jenis entitas utama Anda akan mencakup:
-
SKU Ini adalah daftar barang yang Anda jual. Properti itu akan mencakup hal-hal seperti deskripsi produk dan harga eceran saat ini. Anda bisa mendapatkan harga mewah dan memecah ke meja anak yang memberikan harga dari waktu ke waktu. Mari kita asumsikan bahwa Anda akan meninggalkan kerutan itu untuk saat ini. Beberapa SKU dapat berupa "kombo" dari jenis yang Anda bicarakan.
-
KOMPONEN Ini adalah daftar hal-hal yang membentuk SKU, seperti serbet, cangkir, roti, roti, sirup coke dll - untuk menggunakan contoh Anda. Sama seperti SKU yang memiliki deskripsi dan harga, KOMPONEN juga memiliki deskripsi dan biaya satuan. (Yang juga dapat dihistori dalam tabel anak.) Tabel ini adalah tempat Anda biasanya menyimpan ROP juga.
-
KOMPOSISI Ini adalah BOM yang memotong SKU dan KOMPONEN dan menyatakan berapa banyak unit dari setiap KOMPONEN yang masuk ke dalam satu unit SKU. Anda memerlukan salah satu dari ini untuk memotong dua SKU juga (untuk kombo). Anda dapat menggunakan satu tabel atau dua tabel untuk ini. Dua meja akan membuat para puritan senang, satu meja akan berguna dari sudut pandang pembuat kode.
-
DIJUAL Ini adalah tabel transaksi yang menyediakan header untuk mencatat penjualan satu atau lebih SKU. Tabel ini akan memiliki hal-hal seperti tanggal transaksi, ID kasir, dan item header lainnya.
-
PROMO_ITEM Ini adalah tabel detail transaksi yang akan mencantumkan SKU mana yang terjual (dan berapa jumlahnya) dan berapa harganya. Berapa denormalisasi harga SKU pada saat penjualan, tetapi juga dapat mencakup penggantian khusus pada harga. Harga yang sebenarnya dibebankan untuk SKU adalah hal yang baik untuk didenormalisasi karena seseorang dapat mengedit daftar harga di SKU dan kemudian Anda akan kehilangan jejak berapa banyak sebenarnya yang ditagih untuk item tersebut pada saat itu.
-
INVENTORY_HDR Ini adalah tabel transaksi yang mirip dengan SALE secara konseptual, tetapi merupakan header untuk transaksi inventaris, seperti menerima inventaris baru, menggunakan inventaris (seperti dalam menjualnya) dan untuk penyesuaian inventaris. Sekali lagi, ini akan menjadi hal tanggal/deskripsi, tetapi dapat menyertakan tautan langsung ke SALE_ITEM untuk pergerakan inventaris yang merupakan penjualan jika Anda mau. Anda tidak harus melakukannya dengan cara itu, tetapi beberapa orang suka membuat hubungan antara pendapatan dan biaya berdasarkan transaksi per transaksi.
-
INVENTORY_DTL Ini adalah detail untuk transaksi persediaan. Ini menunjukkan KOMPONEN mana yang masuk atau keluar, jumlah yang masuk atau keluar, dan transaksi INVENTORY_HDR yang diterapkan oleh gerakan ini. Ini juga akan menjadi tempat Anda menyimpan biaya aktual yang dibayarkan untuk item komponen.
-
LOKASI Anda juga dapat (jika diinginkan) melacak lokasi fisik inventaris yang Anda terima dan gunakan/jual. Di restoran ini mungkin tidak penting tetapi jika Anda memiliki rantai atau jika restoran Anda memiliki gudang di luar lokasi untuk bahan-bahan komponen maka Anda mungkin peduli.
Pertimbangkan ERD berikut: 
Untuk melakukan penghitungan pendapatan, Anda akan menjumlahkan uang yang dicatat dalam tabel SALE_ITEM.
Tingkat stok dihitung berdasarkan menjumlahkan INVENTORY_DTL seluk beluk untuk setiap KOMPONEN. (Jangan simpan tingkat stok saat ini dalam tabel - Ini pasti akan menyebabkan masalah rekonsiliasi.)
Untuk melakukan penghitungan biaya, Anda akan menjumlahkan uang yang dicatat dalam tabel INVENTORY_DTL. Perhatikan bahwa Anda biasanya tidak tahu persis yang mana serbet atau roti yang Anda jual, jadi tidak mungkin menghubungkan penerimaan komponen tertentu dengan penjualan SKU tertentu. Sebagai gantinya, Anda harus memiliki konvensi untuk menentukan komponen mana yang digunakan untuk SKU tertentu. Anda mungkin memiliki aturan akuntansi yang menentukan konvensi apa yang harus Anda gunakan. Kebanyakan orang menggunakan FIFO. Beberapa industri menggunakan LIFO dan saya bahkan pernah melihat akuntansi biaya rata-rata tertimbang.
