Die Lösung, nach der Sie suchen, basiert auf einem Buchhaltungsstilmodell und einigen Stücklisten (BOM). Zu Ihren wichtigsten Entitätstypen gehören:
-
SKU Dies ist die Liste der Dinge, die Sie verkaufen. Zu den Eigenschaften gehören Dinge wie die Produktbeschreibung und der aktuelle Verkaufspreis. Sie können ausgefallen sein und den Preis in eine untergeordnete Tabelle aufteilen, die die Preise im Laufe der Zeit angibt. Nehmen wir an, Sie lassen diese Falte vorerst weg. Einige SKUs können "Kombinationen" der Art sein, von der Sie sprechen.
-
KOMPONENTE Dies ist die Liste der Dinge, die eine SKU ausmachen, wie Servietten, Tassen, Brötchen, Bratlinge, Cola-Sirup usw. - um Ihr Beispiel zu verwenden. So wie SKUs Beschreibungen und Preise haben, haben KOMPONENTEN Beschreibungen und Stückkosten. (Die auch in einer untergeordneten Tabelle historisiert werden kann.) In dieser Tabelle würden Sie normalerweise auch Ihre ROP speichern.
-
ZUSAMMENSETZUNG Dies ist eine Stückliste, die SKU und KOMPONENTE schneidet und angibt, wie viele Einheiten jeder KOMPONENTE in eine Einheit einer SKU passen. Sie benötigen auch eine davon, um zwei SKUs zu schneiden (für Combos). Sie können dafür entweder eine Tabelle oder zwei Tabellen verwenden. Zwei Tische werden die Puristen glücklich machen, ein Tisch ist aus Programmierersicht sinnvoll.
-
VERKAUF Dies ist eine Transaktionstabelle, die einen Header zum Aufzeichnen eines Verkaufs einer oder mehrerer SKUs bereitstellt. Diese Tabelle enthält Dinge wie das Transaktionsdatum, die Kassierer-ID und andere Kopfzeilenelemente.
-
SALE_ITEM Dies ist die Transaktionsdetailtabelle, die enthält, welche SKU verkauft wurde (und wie viele) und für wie viel. Das Wie viel ist eine Denormalisierung des SKU-Preises zum Zeitpunkt des Verkaufs, könnte aber auch spezielle Überschreibungen des Preises beinhalten. Es ist gut, den tatsächlich für die SKU berechneten Preis zu denormalisieren, da jemand den Listenpreis in der SKU bearbeiten könnte und Sie dann den Überblick darüber verlieren würden, wie viel tatsächlich für den Artikel zu diesem Zeitpunkt berechnet wurde.
-
INVENTORY_HDR Dies ist eine Transaktionstabelle, die dem SALE konzeptionell ähnlich ist, aber es ist die Kopfzeile für eine Inventartransaktion, wie z. B. den Erhalt von neuem Inventar, das Aufbrauchen von Inventar (wie beim Verkauf) und für Inventaranpassungen. Auch dies wäre Datums-/Beschreibungsmaterial, aber es kann einen direkten Link zu einem SALE_ITEM für Bestandsbewegungen enthalten, die Verkäufe sind, wenn Sie möchten. Sie müssen es nicht so machen, aber manche Leute ziehen es vor, den Zusammenhang zwischen Einnahmen und Kosten von Transaktion zu Transaktion herzustellen.
-
INVENTORY_DTL Dies ist das Detail für eine Bestandstransaktion. Dies gibt an, welche KOMPONENTE ein- oder ausgeht, die Menge, die ein- oder ausgeht, und die INVENTORY_HDR-Transaktion, auf die sich diese Bewegung bezog. Hier verwahren Sie auch die tatsächlichen Kosten, die für den Komponentenartikel bezahlt wurden.
-
STANDORT Sie können (wenn Sie möchten) auch den physischen Standort des Inventars verfolgen, das Sie erhalten und verwenden/verkaufen. In einem Restaurant mag dies nicht wichtig sein, aber wenn Sie eine Kette haben oder wenn Ihr Restaurant ein externes Lager für Zutaten hat, dann ist es Ihnen vielleicht wichtig.
Betrachten Sie die folgende ERD: 
Um Ihre Umsatzbuchhaltung durchzuführen, würden Sie die in der SALE_ITEM-Tabelle aufgezeichneten Beträge addieren.
Lagerbestände werden berechnet basierend auf dem Addieren der INVENTORY_DTL-Eingänge und -Ausgänge für jede KOMPONENTE. (Speichern Sie aktuelle Lagerbestände nicht in einer Tabelle – dies kann zu Abstimmungsproblemen führen.)
Für Ihre Kostenrechnung würden Sie die in der Tabelle INVENTORY_DTL erfassten Beträge addieren. Beachten Sie, dass Sie normalerweise nicht genau wissen, welche Serviette oder Brötchen, die Sie verkauft haben, daher ist es nicht möglich, bestimmte Komponentenquittungen mit bestimmten SKU-Verkäufen zu verknüpfen. Stattdessen benötigen Sie eine Konvention, um zu bestimmen, welche Komponenten für eine bestimmte SKU verwendet wurden. Möglicherweise haben Sie Abrechnungsregeln, die angeben, welche Konvention Sie verwenden müssen. Die meisten Leute verwenden FIFO. Einige Branchen verwenden LIFO und ich habe sogar die gewichtete Durchschnittskostenrechnung gesehen.
