Den løsning, du leder efter, vil være afhængig af en regnskabsstilsmodel og et par styklister (BOM). Dine vigtigste enhedstyper vil omfatte:
-
SKU Dette er listen over ting, du sælger. Dets egenskaber vil omfatte ting som produktbeskrivelse og nuværende udsalgspris. Du kan blive fancy og bryde prisen ud i et børnebord, der giver priser over tid. Lad os antage, at du vil udelade den rynke for nu. Nogle SKU'er kan være "kombinationer" af den slags, du taler om.
-
KOMPONENT Dette er listen over ting, der udgør en SKU, såsom servietter, kopper, boller, frikadeller, kokssirup osv. - for at bruge dit eksempel. Ligesom SKU har beskrivelser og priser, har KOMPONENTER beskrivelser og enhedsomkostninger. (Som også kan historiseres i en undertabel.) Denne tabel er, hvor du typisk også vil gemme din ROP.
-
KOMPOSITION Dette er en stykliste, der skærer SKU og COMPONENT og siger, hvor mange enheder af hver COMPONENT, der går ind i en enhed af en SKU. Du skal bruge en af disse for også at krydse to SKU'er (til kombinationer). Du kan enten bruge et bord eller to borde til dette. To borde vil holde puristerne glade, et bord vil være hensigtsmæssigt fra et kodersynspunkt.
-
UDSALG Dette er en transaktionstabel, der giver en header til registrering af et salg af en eller flere SKU'er. Denne tabel ville have ting som transaktionsdato, kasse-id og andre overskriftselementer.
-
SALE_ITEM Dette er transaktionsdetaljetabellen, der vil inkludere, hvilken SKU der blev solgt (og hvor mange) og for hvor meget. Hvor meget er en denormalisering af SKU-prisen på salgstidspunktet, men kan også inkludere eventuelle særlige tilsidesættelser af prisen. Den pris, der faktisk opkræves for SKU'en, er en god ting at denormalisere, fordi nogen kunne redigere listeprisen i SKU, og så ville du miste overblikket over, hvor meget der faktisk blev opkrævet for varen på det tidspunkt.
-
INVENTORY_HDR Dette er en transaktionstabel, der ligner SALE konceptuelt, men det er overskriften for en lagertransaktion, såsom modtagelse af nyt lager, opbrug af lager (som ved salg af det) og for lagerjusteringer. Igen, dette ville være dato-/beskrivelsesting, men det kan inkludere et direkte link til et SALE_ITEM for lagerbevægelser, der er salg, hvis du vil. Du behøver ikke at gøre det på den måde, men nogle mennesker kan lide at etablere sammenhængen mellem indtægter og omkostninger på en transaktion for transaktion basis.
-
INVENTORY_DTL Dette er detaljen for en lagertransaktion. Dette angiver, hvilken KOMPONENT der går ind eller ud, mængden der gik ind eller ud, og INVENTORY_HDR-transaktionen, som denne bevægelse gjaldt. Det ville også være her, du beholder de faktiske omkostninger betalt for komponenten.
-
LOCATION Du kan (hvis du ønsker det) også spore den fysiske placering af det varelager, du modtager og bruger/sælger. I en restaurant er dette måske ikke vigtigt, men hvis du har en kæde, eller hvis din restaurant har et offsite lager for komponentingredienser, så er du måske ligeglad.
Overvej følgende ERD: 
For at gøre dit indtægtsregnskab skal du lægge de penge sammen, der er registreret i tabellen SALE_ITEM.
Lagerniveauer beregnes baseret på sammenlægning af INVENTORY_DTL ins og outs for hver KOMPONENT. (Opbevar ikke de nuværende lagerbeholdninger i en tabel - dette er dømt til at forårsage afstemningsproblemer.)
For at lave dit omkostningsregnskab ville du lægge de penge sammen, der er registreret i INVENTORY_DTL-tabellen. Bemærk, at du normalt ikke ved præcis hvilken serviet eller bolle, du har solgt, så det vil ikke være muligt at sammenkæde specifikke komponentkvitteringer med specifikke SKU-salg. I stedet skal du have en konvention til at bestemme, hvilke komponenter der blev brugt til en given SKU. Du kan have regnskabsregler, der specificerer, hvilken konvention du skal bruge. De fleste bruger FIFO. Nogle brancher bruger LIFO, og jeg har endda set regnskab med vægtede gennemsnitlige omkostninger.