Mysql
 sql >> Database >  >> RDS >> Mysql

Database Design:inventario e sistema di vendita?

La soluzione che stai cercando si baserà su un modello di stile contabile e un paio di distinte base (BOM). I principali tipi di entità includeranno:

  • SKU Questa è la lista delle cose che vendi. Le sue proprietà includeranno cose come la descrizione del prodotto e il prezzo al dettaglio corrente. Puoi ottenere fantasia e suddividere il prezzo in una tabella figlio che fornisce i prezzi nel tempo. Supponiamo che per ora lascerai quella ruga. Alcuni SKU possono essere "combo" del tipo di cui stai parlando.

  • COMPONENTE Questo è l'elenco delle cose che compongono una SKU, come tovaglioli, tazze, panini, polpette, sciroppo di coca cola ecc. - per usare il tuo esempio. Proprio come SKU ha descrizioni e prezzi, i COMPONENTI hanno descrizioni e costi unitari. (Che può anche essere storicizzato in una tabella figlio.) Questa tabella è dove in genere memorizzeresti anche il tuo ROP.

  • COMPOSIZIONE Questa è una distinta base che interseca SKU e COMPONENTE e indica quante unità di ciascun COMPONENTE vanno in un'unità di una SKU. Hai bisogno di uno di questi anche per intersecare due SKU (per le combo). È possibile utilizzare una o due tabelle per questo. Due tabelle faranno felici i puristi, una tabella sarà utile dal punto di vista del programmatore.

  • VENDITA Questa è una tabella delle transazioni che fornisce un'intestazione per la registrazione di una vendita di uno o più SKU. Questa tabella conterrebbe elementi come la data della transazione, l'ID cassiere e altri elementi di intestazione.

  • SALE_ITEM Questa è la tabella dei dettagli della transazione che includerebbe quale SKU è stato venduto (e quanti) e per quanto. L'importo è una denormalizzazione del prezzo SKU al momento della vendita, ma potrebbe anche includere eventuali sostituzioni speciali del prezzo. Il prezzo effettivamente addebitato per lo SKU è una buona cosa da denormalizzare perché qualcuno potrebbe modificare il prezzo di listino in SKU e quindi perderesti traccia di quanto effettivamente è stato addebitato per l'articolo in quel momento.

  • INVENTORY_HDR Questa è una tabella transazionale che è concettualmente simile a SALE, ma è l'intestazione per una transazione di inventario, come la ricezione di nuovo inventario, l'utilizzo dell'inventario (come per la vendita) e per le rettifiche dell'inventario. Anche in questo caso, si tratterebbe di dati/descrizioni, ma può includere un collegamento diretto a un SALE_ITEM per i movimenti di inventario che sono vendite, se lo desideri. Non devi farlo in questo modo, ma ad alcune persone piace stabilire la connessione tra ricavi e costi transazione per transazione.

  • INVENTORY_DTL Questo è il dettaglio per una transazione di magazzino. Indica quale COMPONENT sta entrando o uscendo, la quantità entrata o uscita e la transazione INVENTORY_HDR a cui si è applicato questo movimento. Questo sarebbe anche il luogo in cui mantieni il costo effettivo pagato per l'elemento componente.

  • POSIZIONE Puoi (se lo desideri) anche tracciare la posizione fisica dell'inventario che ricevi e usi/vendi. In un ristorante questo potrebbe non essere importante, ma se hai una catena o se il tuo ristorante ha un magazzino fuori sede per gli ingredienti dei componenti, allora potrebbe interessarti.

Considera il seguente ERD:

Per fare la contabilità delle entrate devi sommare il denaro registrato nella tabella SALE_ITEM.

I livelli delle scorte vengono calcolati in base alla somma degli ingressi e delle uscite INVENTORY_DTL per ciascun COMPONENT. (Non memorizzare i livelli di scorte attuali in una tabella:questo è destinato a causare problemi di riconciliazione.)

Per fare la contabilità dei costi dovresti sommare il denaro registrato nella tabella INVENTORY_DTL. Tieni presente che di solito non saprai esattamente quale tovagliolo o panino che hai venduto, quindi non sarà possibile collegare le ricevute di componenti specifici con le vendite di SKU specifiche. Al contrario, è necessario disporre di una convenzione per determinare quali componenti sono stati utilizzati per un determinato SKU. Potresti avere regole contabili che specificano quale convenzione devi utilizzare. La maggior parte delle persone usa FIFO. Alcuni settori utilizzano LIFO e ho anche visto la contabilità dei costi medi ponderati.