Lösningen du letar efter kommer att förlita sig på en redovisningsmodell och ett par stycklistor (BOM). Dina huvudsakliga enhetstyper inkluderar:
-
SKU Det här är listan över saker du säljer. Dess egenskaper kommer att innehålla saker som produktbeskrivning och aktuellt pris. Du kan bli snygg och bryta ut pris i ett barnbord som ger priser över tid. Låt oss anta att du kommer att lämna den där rynkan för tillfället. Vissa SKU:er kan vara "kombinationer" av det slag du pratar om.
-
KOMPONENT Det här är listan över saker som utgör en SKU, som servetter, koppar, bullar, biffar, cola sirap etc. - för att använda ditt exempel. Precis som SKU har beskrivningar och priser, har KOMPONENTER beskrivningar och enhetskostnader. (Som också kan historiska i en underordnad tabell.) Den här tabellen är där du vanligtvis också lagrar din ROP.
-
KOMPOSITION Detta är en BOM som skär SKU och COMPONENT och anger hur många enheter av varje COMPONENT som går in i en enhet av en SKU. Du behöver en av dessa för att skära två SKU:er också (för kombinationer). Du kan antingen använda ett bord eller två bord för detta. Två bord kommer att hålla puristerna nöjda, ett bord kommer att vara lämpligt ur kodarsynpunkt.
-
REA Detta är en transaktionstabell som tillhandahåller en rubrik för att registrera en försäljning av en eller flera SKU:er. Den här tabellen skulle ha saker som transaktionsdatum, kassa-ID och andra rubriker.
-
SALE_ITEM Detta är transaktionsdetaljtabellen som skulle inkludera vilken SKU som såldes (och hur många) och för hur mycket. Hur mycket är en denormalisering av SKU-priset vid försäljningstillfället, men kan också inkludera särskilda åsidosättanden av priset. Priset som faktiskt tas ut för SKU:n är bra att avnormalisera eftersom någon kan redigera listpriset i SKU och då tappar du koll på hur mycket som faktiskt debiterades för objektet vid den tidpunkten.
-
INVENTORY_HDR Detta är en transaktionstabell som liknar SALE begreppsmässigt, men det är rubriken för en lagertransaktion, som att ta emot nytt lager, använda upp lager (som vid försäljning) och för lagerjusteringar. Återigen, detta skulle vara datum/beskrivningsgrejer, men det kan inkludera en direktlänk till en SALE_ITEM för lagerförflyttningar som är försäljning om du vill. Du behöver inte göra det på det sättet, men vissa människor gillar att fastställa sambandet mellan intäkter och kostnader på transaktionsbasis.
-
INVENTORY_DTL Detta är detaljen för en lagertransaktion. Detta indikerar vilken KOMPONENT som går in eller ut, kvantiteten som gick in eller ut och INVENTORY_HDR-transaktionen som denna rörelse gällde. Det skulle också vara där du behåller den faktiska kostnaden för komponenten.
-
PLATS Du kan (om du vill) även spåra den fysiska platsen för inventeringen som du tar emot och använder/säljer. På en restaurang kanske detta inte är viktigt, men om du har en kedja eller om din restaurang har ett externt lager för komponentingredienser så kanske du bryr dig.
Tänk på följande ERD: 
För att göra din intäktsredovisning skulle du lägga ihop pengarna som registrerats i tabellen SALE_ITEM.
Lagernivåer beräknas baserat på att lägga ihop INVENTORY_DTL ins och outs för varje KOMPONENT. (Lagra inte aktuella lagernivåer i en tabell – detta är dömt att orsaka avstämningsproblem.)
För att göra din kostnadsredovisning skulle du lägga ihop pengarna som registrerats i tabellen INVENTORY_DTL. Observera att du vanligtvis inte vet exakt vilken servett eller bulle du sålt, så det går inte att koppla specifika komponentkvitton till specifika SKU-försäljningar. Istället måste du ha en konvention för att bestämma vilka komponenter som användes för en given SKU. Du kan ha redovisningsregler som anger vilken konvention du är skyldig att använda. De flesta använder FIFO. Vissa branscher använder LIFO och jag har till och med sett vägda genomsnittliga kostnadsredovisningar.