De oplossing die u zoekt, is gebaseerd op een boekhoudmodel en een aantal stuklijsten (BOM). Uw belangrijkste entiteitstypen zijn onder meer:
-
SKU Dit is de lijst met dingen die je verkoopt. De eigenschappen van het product bevatten zaken als een productbeschrijving en de huidige verkoopprijs. U kunt fantasie krijgen en de prijs uitsplitsen in een kindertabel die prijzen in de loop van de tijd geeft. Laten we aannemen dat je die rimpel voor nu weglaat. Sommige SKU's kunnen "combo's" zijn van het soort waar u het over heeft.
-
COMPONENT Dit is de lijst met dingen waaruit een SKU bestaat, zoals servetten, kopjes, broodjes, pasteitjes, colasiroop enz. - om uw voorbeeld te gebruiken. Net zoals SKU beschrijvingen en prijzen heeft, hebben COMPONENT's beschrijvingen en eenheidskosten. (Die ook in een onderliggende tabel kan worden gehistorieerd.) In deze tabel zou u normaal gesproken ook uw ROP opslaan.
-
SAMENSTELLING Dit is een stuklijst die SKU en COMPONENT doorsnijdt en aangeeft hoeveel eenheden van elke COMPONENT in een eenheid van een SKU gaan. Je hebt een van deze nodig om ook twee SKU's te kruisen (voor combo's). U kunt hiervoor één tafel of twee tabellen gebruiken. Twee tafels zullen de puristen tevreden houden, één tafel is handig vanuit het oogpunt van de programmeur.
-
VERKOOP Dit is een transactietabel die een koptekst biedt voor het vastleggen van een verkoop van een of meer SKU's. Deze tabel bevat zaken als transactiedatum, kassier-ID en andere kopteksten.
-
SALE_ITEM Dit is de transactiedetailtabel die zou bevatten welke SKU is verkocht (en hoeveel) en voor hoeveel. De hoeveel is een denormalisatie van de SKU-prijs op het moment van verkoop, maar kan ook speciale overschrijvingen van de prijs omvatten. De prijs die daadwerkelijk voor de SKU in rekening wordt gebracht, is een goede zaak om te denormaliseren, omdat iemand de catalogusprijs in SKU zou kunnen bewerken en dan zou je uit het oog verliezen hoeveel er op dat moment daadwerkelijk voor het artikel in rekening is gebracht.
-
INVENTORY_HDR Dit is een transactietabel die conceptueel vergelijkbaar is met de VERKOOP, maar het is de kop voor een voorraadtransactie, zoals het ontvangen van nieuwe voorraad, het opgebruiken van voorraad (zoals bij het verkopen ervan) en voor voorraadaanpassingen. Nogmaals, dit zou data/beschrijvingsdingen zijn, maar het kan een directe link naar een SALE_ITEM bevatten voor voorraadbewegingen die verkopen zijn als je wilt. Je hoeft het niet zo te doen, maar sommige mensen leggen graag het verband tussen opbrengsten en kosten per transactie.
-
INVENTORY_DTL Dit is het detail voor een voorraadtransactie. Dit geeft aan welke COMPONENT in- of uitgaat, de hoeveelheid die in- of uitging en de INVENTORY_HDR-transactie waarop deze verplaatsing van toepassing was. Hier bewaart u ook de werkelijke kosten die voor het onderdeel zijn betaald.
-
LOCATIE U kunt (indien u dat wenst) ook de fysieke locatie volgen van de inventaris die u ontvangt en gebruikt/verkoopt. In een restaurant is dit misschien niet belangrijk, maar als je een keten hebt of als je restaurant een extern magazijn heeft voor ingrediënten, kan het je wat schelen.
Overweeg de volgende ERD: 
Om uw inkomstenboekhouding te doen, zou u het geld optellen dat is geregistreerd in de SALE_ITEM-tabel.
Voorraadniveaus worden berekend gebaseerd op het optellen van de INVENTORY_DTL ins en outs voor elke COMPONENT. (Sla de huidige voorraadniveaus niet op in een tabel - dit is gedoemd om afstemmingsproblemen te veroorzaken.)
Om uw kostenberekening te maken, zou u het geld optellen dat is geregistreerd in de INVENTORY_DTL-tabel. Houd er rekening mee dat u meestal niet precies weet welke servet of broodje dat je hebt verkocht, dus het is niet mogelijk om specifieke onderdeelontvangsten te koppelen aan specifieke SKU-verkopen. In plaats daarvan moet u een conventie hebben om te bepalen welke componenten voor een bepaalde SKU zijn gebruikt. Mogelijk hebt u boekhoudregels die specificeren welke conventie u moet gebruiken. De meeste mensen gebruiken FIFO. Sommige industrieën gebruiken LIFO en ik heb zelfs gewogen gemiddelde kostenberekeningen gezien.