Gestione degli spazi pubblicitari e elaborazione degli ordini di vendita sono due distinti problemi separati.
In un tipico scenario di vendita al dettaglio, un'unità vende frequentemente a prezzi diversi a seconda di una moltitudine di fattori; Il prezzo al quale un'unità viene venduta a un cliente può essere estremamente complesso perché i rivenditori utilizzano tutti i tipi di modi creativi per essere competitivi sul prezzo senza effettivamente cambiare il prezzo unitario di base per chi acquista una singola unità. Ad esempio
- Offerte promozionali e coupon (ad es. 3-per-2, BOGOF, sconto del 10%, ecc.)
- Offerte di pacchetti grandi (come nell'esempio che hai mostrato)
- Offerte multi-prodotto (ad esempio il 10% di sconto quando acquisti due pinte di latte e una pagnotta di pane)
- Data di vendita o riduzioni di magazzino danneggiate
Considera il modo in cui potresti vedere qualcosa di simile su una ricevuta al tuo supermercato locale
+-----------------------------------+
| SellitCheap Stores Ltd. |
+-----------------------------------+
| Prod. Qty. Price |
+ - - - - - - - - - - - - - - - - - +
| |
| Milk 568ml 4 £ 2.40 |
| |
| Bread 400g 1 £ 0.90 |
| |
| Choc Bar 35g 2 £ 1.18 |
| |
| Orange Juice 1L 1 £ 1.20 |
| ========= |
| Sub Total: £ 5.68 |
| Milk BOGOF: - £ 1.20 |
| ========= |
| Total: £ 4.48 |
+ - - - - - - - - - - - - - - - - - +
| Thank you for shopping with us! |
+-----------------------------------+
In molti scenari di vendita al dettaglio a cui mi viene in mente, una vendita in genere elenca il prezzo base, quindi elenca i risparmi / promozioni / detrazioni su linee di vendita separate. (Naturalmente, non tutti i sistemi funzionano in questo modo, ma molti grandi rivenditori lo fanno sicuramente)
Il vantaggio di ciò è che consente la massima flessibilità per diversi tipi di offerte, ovvero una semplice linea di vendita che utilizza sempre il prezzo unitario di base.
Da un punto di vista del sistema, qualunque cosa determini la quantità nel tuo inventario non ha motivo di preoccuparsi del prezzo di vendita (o del costo di acquisto unitario).
Nello scenario sopra, se hai venduto un intero pacchetto di 24 unità di latte, una linea di vendita mostrerebbe una vendita di 24 unità di latte, ma una detrazione di costo pari al costo di 4 unità di latte.
In alcuni sistemi ERP, la quantità nell'inventario non viene memorizzata come valore fisso, ma memorizzata in un libro mastro, dove gli acquisti e le vendite sono elencati come aggiustamenti + ve e -ve sul totale inventario. per es.
Warehouse Inventory Receipt
Warehouse Inventory Receipt Id: 5
Receipt Date: 01-Aug-2017 19:51:21
Line Id Product Qty Per. Packs Total Adj
1 Milk 568ml 24 10 +240
2 Bread Loaf 10 4 +40
3 Wine 75cl 6 2 +12
Quindi, se hai effettuato 3 vendite di latte, incluso 1 confezione, 4 unità, e 1 confezione + 12 unità, il calcolo dell'inventario sarà:
Product: Milk 568ml
Barcode: 120938019380911
Id ReceiptType Qty ReceiptId ReceiptLineId
1 Buy 240 1 1
2 Sell 24 3 1
3 Sell 4 4 2
4 Sell 36 7 4
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Current Inventory: 176
In breve,
- Considerare la memorizzazione delle transazioni per i livelli di scorte del proprio inventario come (linee di vendita, linee di acquisto).
- Una linea di vendita può memorizzare il prezzo unitario per quella specifica vendita.
- Una linea di vendita dovrebbe appartenere a una ricevuta di vendita
- Una ricevuta di vendita può contenere anche righe di sconto contenenti promozioni per una o più righe di vendita su tale ricevuta
- Potresti avere un'entità separata per le tue promozioni che si collega a prodotti specifici.
In cima alla mia testa, alcuni hanno suggerito le entità DB:
Product
Promotion
Sales Receipt
Sales Receipt Line
Sales Discount Line
Warehouse Inventory Receipt
Warehouse Inventory Receipt Line
Product Inventory Ledger Entry Line
In un sistema molto più semplice, Warehouse Inventory Receipt Line , Sales Receipt Line e Product Inventory Ledger Entry sarebbero tutti la stessa entità, poiché in genere esisterebbe una relazione uno a uno tra una riga di ricevimento e una voce di inventario. Dipende piuttosto da quanto complesse sono le tue esigenze.
Questo è un problema non banale perché la soluzione ovvia / semplice di mantenere un'entità Product semplice con un campo Inventory può facilmente provocare la duplicazione dei dati non appena si finisce per memorizzare le righe di ricevimento delle vendite e l'inventario del magazzino Linee.
La logica per archiviare le modifiche di inventario come voci di mastro anziché mantenere un campo di stato sulla tua tabella Product chiamata Inventory è avere un sistema che memorizza le tue transazioni (vendite e acquisti) in modo da poter gestire il prezzo di vendita / promozioni (e costo unitario di acquisto per le merci in) utilizzando tabelle / entità separate.
D'altra parte, se disponi di un campo "Spazio pubblicitario", oltre a una riga di ricevuta che dice che hai venduto un'unità di latte, quindi la memorizzazione di tale modifica in un campo Inventory su un'altra tabella è duplicazione di dati e dovrai fare attenzione a garantire che tali modifiche rimangano sincronizzate.
I grandi rivenditori quasi certamente useranno modelli di dati che sono molto più complessi delle idee che ho proposto qui.
Modifica / Chiarimento
Quando vendi un cartone, stai vendendo 24 per £2.00 ma il costo di 24 singole unità sarebbe normalmente £2.40 ( 24 x £0.10 )
Su questa base (come nel tuo esempio), un modo per riconciliare sia il calcolo dell'inventario (24 unità) sia il costo totale (£ 2,00). Considera:
- Una linea di vendita di
24 * £0.10 = £2.40 (questo si occupa del calcolo dell'inventario)
- Una riga di sconto di
£2.00 - £2.40 = £ -0.40 (riordina il prezzo ridotto)
Ciò garantisce che il tuo inventario corrisponda a (24 unità) e un ordine / ricevuta di vendita sia stato fatturato per l'importo corretto ( £2.40 - £0.40 = £2.00 ).
In altre parole, usa sempre il prezzo di vendita per unità singola, quindi utilizza uno sconto per regolare il prezzo in basso, come uno sconto per più acquisti.