Datenbank Design: Inventar und Vertriebssystem?
Ich muss ein Inventar- und Verkaufssystem entwickeln.
Für den Lagerbestand muss ich in der Lage sein, den idealen Lagerbestand, den aktuellen Lagerbestand, den Bestellpunkt, die Kosten, den Verkaufspreis usw. zu verfolgen.
Nicht jeder Artikel im Inventar ist "verkaufbar". Zum Beispiel möchte ich den Bestand an Plastikbechern für Limonaden aufbewahren. Das bedeutet, jedes Mal, wenn ich eine Limonade verkaufe, muss ich eine von der Anzahl der Plastikbecher abziehen. Somit ist ein "mittlerer Koks" tatsächlich der Plastikbecher, einige Servietten und die Flüssigkeit, wobei jeder Artikel seine eigenen aktuellen Lagerbestände, Kosten usw. hat.
Dann gibt es das Konzept der "Combos". Vielleicht werden ein $ 1 Medium Coke und ein $ 3 Hamburger zusammen als Combo für nur $ 3,50 (ein $ 0,50 Einsparungen) verkauft. Der Coke wurde erwähnt, einige Servietten zu enthalten. Nehmen wir an, der Hamburger enthält auch selbst Servietten. Als Kombination bekommt der Käufer jedoch nicht die Serviette für die Cola und den Hamburger; Der Käufer erhält nur die gleiche Menge an Servietten, als wenn er nur die Cola kaufen würde.
Für das Verkaufssystem muss ich jeden Verkauf verfolgen und möglicherweise eine Beziehung zu den Bestandsaufzeichnungen aufrechterhalten (dies würde bedeuten, dass ich einen Artikel im Lager niemals löschen könnte, wenn einmal ein Verkauf getätigt wurde - für historische Zwecke) ). Wenn ich eine "mittelgroße Cola" für 1 $ verkaufe, sollte ich sie vielleicht als 0,90 $ für die Flüssigkeit und 0,10 $ für den Plastikbecher abbrechen.
Und wenn ich eine "Combo" verkaufe, muss ich vielleicht angeben können, dass der Hamburger tatsächlich für 3 $ verkauft wurde und das Medium Coke nur 0,50 $ (nur die Limonade wurde abgezinst, um die Combo attraktiver zu machen). p>
Dies kann kein neues Problem sein. Hat jemand irgendwelche Ideen (oder Beispiele), die ich mir ansehen kann, um dieses Problem zu lösen? Ich bin nicht sicher, wie man Inventar, die verkaufbaren Artikel (besonders die Combos) modelliert und wie man die Verkäufe aufzeichnet .
2 Antworten
Die Lösung, nach der Sie suchen, basiert auf einem Buchhaltungsstilmodell und einigen Stücklisten. Zu den wichtigsten Entitätstypen gehören:
-
SKU Dies ist die Liste der Dinge, die Sie verkaufen. Seine Eigenschaften beinhalten Dinge wie Produktbeschreibung und aktuellen Verkaufspreis. Sie können Phantasie und brechen Preis in eine Kinder-Tabelle, die Preise im Laufe der Zeit gibt. Nehmen wir an, dass Sie diese Falte für jetzt verlassen werden. Einige SKUs können "Kombos" der Art sein, über die Sie sprechen.
-
KOMPONENTE Dies ist die Liste der Dinge, aus denen eine SKU besteht, z. B. Servietten, Tassen, Brötchen, Pasteten, Cola-Sirup usw. - um Ihr Beispiel zu verwenden. Genau wie SKU Beschreibungen und Preise hat, haben Komponenten Beschreibungen und Stückkosten. (Dies kann auch in einer untergeordneten Tabelle historisiert werden.) In dieser Tabelle speichern Sie normalerweise auch Ihr ROP.
-
COMPOSITION Dies ist eine Stückliste, die SKU und COMPONENT schneidet und angibt, wie viele Einheiten jedes COMPONENT in eine Einheit einer SKU gehen. Du brauchst 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 wird aus Codersicht sinnvoll sein.
-
VERKAUF Dies ist eine Transaktionstabelle, die eine Kopfzeile für die Aufzeichnung eines Verkaufs einer oder mehrerer SKUs bereitstellt. Diese Tabelle würde Dinge wie Transaktionsdatum, Kassierer-ID und andere Kopfzeilenelemente enthalten.
-
SALE_ITEM Dies ist die Transaktionsdetails-Tabelle, die angibt, welche SKU (und wie viele) verkauft wurde und für wie viel. Wie hoch ist eine Denormalisierung des SKU-Preises zum Zeitpunkt des Verkaufs, sondern könnte auch jegliche Sonderüberschreibungen auf den Preis beinhalten. Der Preis, der tatsächlich für die SKU berechnet wird, ist eine gute Sache, um zu denormalisieren, weil jemand den Listenpreis in SKU bearbeiten könnte und dann den Überblick darüber verlieren würde, wie viel tatsächlich für den Artikel zu der Zeit berechnet wurde.
-
INVENTORY_HDR Dies ist eine transaktionale Tabelle, die konzeptionell dem SALE ähnelt, aber es ist die Kopfzeile für eine Inventartransaktion, z. B. das Empfangen neuen Inventars, das Verwenden von Inventar (wie beim Verkauf) es) und für Bestandsanpassungen. Auch dies wäre ein Datum / eine Beschreibung, aber es kann einen direkten Link zu einem SALE_ITEM für Lagerbewegungen enthalten, die Verkäufe sind, wenn Sie möchten. Sie müssen es nicht so machen, aber manche Leute möchten die Verbindung zwischen Einnahmen und Kosten auf Transaktionsbasis herstellen.
-
INVENTORY_DTL Dies ist das Detail für eine Inventartransaktion. Dies gibt an, welche COMPONENT ein- oder ausgehen, welche Menge ein- oder ausgegangen ist und welche INVENTORY_HDR-Transaktion diese Bewegung angewendet hat. Dies wäre auch, wo Sie die tatsächlichen Kosten für den Komponentenartikel behalten.
-
LOCATION Sie können (wenn Sie es wünschen) auch den physischen Standort des Inventars verfolgen, das Sie erhalten und verwenden / verkaufen. In einem Restaurant ist dies möglicherweise nicht wichtig, aber wenn Sie eine Kette haben oder wenn Ihr Restaurant ein externes Lager für Bestandteilebestandteile hat, dann interessieren Sie sich vielleicht.
Betrachten Sie die folgende ERD:
Um Ihre Einnahmenabrechnung durchzuführen, würden Sie das in der Tabelle SALE_ITEM aufgezeichnete Geld addieren.
Die Lagerbestände werden basierend auf der Addition der INVENTORY_DTL-INS und -OUTs für jede KOMPONENTE berechnet. (Speichern Sie die aktuellen Lagerbestände nicht in einer Tabelle. Dies führt zwangsläufig zu Abstimmungsproblemen.)
Für Ihre Kostenrechnung würden Sie das in der Tabelle INVENTORY_DTL aufgezeichnete Geld aufaddieren. Beachten Sie, dass Sie normalerweise nicht wissen, welche Serviette oder welches Brötchen Sie verkauft haben, so dass es nicht möglich ist, bestimmte Komponentenempfehlungen mit bestimmten SKU-Verkäufen zu verknüpfen. Stattdessen müssen Sie über eine Konvention verfügen, um zu bestimmen, welche Komponenten für eine bestimmte SKU verwendet wurden. Möglicherweise verfügen Sie über Abrechnungsregeln, die angeben, welche Konvention Sie verwenden müssen. Die meisten Leute benutzen FIFO. Einige Branchen nutzen LIFO und ich habe sogar eine gewichtete durchschnittliche Kostenrechnung gesehen.
Ich würde vorschlagen, die Bestandstabellen vollständig von den Geldrechnungstabellen zu trennen. Zum Beispiel, das Beispiel, das Sie gegeben haben, weiß ich, um lächerlich zu sein: Für Ihr durchschnittliches Fastfood-Restaurant kostet ein $ .90 Cent-Koks ungefähr $ .05 - $. 07 für den Becher, und weniger als ein Penny für die Flüssigkeit, eine Ordnung verlassend Gewinn von $ .83ish. Warum müssen die Kosten bis zu $ .90 betragen?
Tabellen:
InventoryItems Felder: InventoryItemId, Name, CurrentInventoryLevel, IdealInventoryLevel
InventoryChangeRecords Felder: InventoryChangeId, InventoryItemId, Change (int)
RetailItems Felder: RetailItemId, Name, Preis
RetailItemMakeup Felder: RetailItemId, InventoryItemId, Menge
SaleTransactions Felder: SaleTransactionId, DateTime, TotalSale
SaleTransactionItems Felder: SaleTransactionId, RetailItemId, Menge
Bei jedem Verkauf sollten Sie einen Sproc (oder Trigger) verwenden, um CurrentInventoryLevel zu aktualisieren und Datensätze in InventoryChangeRecords einzufügen. Sie können leicht herausfinden, wie sich ein Verkauf auf das Inventar ausgewirkt hat, indem Sie von SaleTransaction zu SaleTransactionItems zu RetailItemMakeup gekommen sind.
Wenn Sie es in einer noch stärkeren (aber IMO-fremden) Weise machen wollten, könnten Sie eine andere Viele-zu-Viele-Tabelle zwischen SaleTransactionItems und InventoryChangeRecords erstellen.
Tags und Links mysql database database-design