Pugno, devo implorarti di non costruire questo sistema da zero. È un progetto molto più complesso di quanto sembri. Si prega di considerare l'utilizzo di una piattaforma eCommerce open source, del sistema di gestione degli ordini e del catalogo dei prodotti. Dai un'occhiata al Apache Open for Business Project . Ce ne sono molti altri, molti vogliono che paghino loro le spese di consulenza.
Molti pacchetti software di gestione degli ordini spesso lo modellano utilizzando i concetti di domanda e offerta. Hai alcune entità di alto livello, come Prodotto (per esempio, magliette con scollo a V di FancyBrand Uomo), Articolo (ad esempio, maglietta FancyBrand Uomo in taglia Medium e colore bianco), Fornitore (la società che vende l'articolo al rivenditore) , Fornitore (la società che produce effettivamente l'articolo, che non è necessariamente lo stesso del Fornitore). Un rivenditore potrebbe acquistare il prodotto Foo, che viene prodotto da Venditore Fooz, dalla barra fornitori oggi e dal fornitore Baz domani. O Foo potrebbe essere fornito da Bar e Baz contemporaneamente (suggerimento: non utilizzare 1 colonna per la relazione Fornitore-Prodotto).
Quando la Barra fornitori invia / assegna N più articoli Foo al rivenditore, il rivenditore deve aumentare la fornitura di oggetto Foo di N. È inoltre possibile allegare un "tipo" alla fornitura che si aggiunge.
Quando un cliente inizia il processo di acquisto di M Foo Items, di solito aumenta la richiesta di Foo di M. Dopo che la transazione è stata completata (la carta di credito è stata convalidata, il controllo delle frodi è stato completato, ecc.) Il rivenditore decrementa sia Supply che Demand by M.
Eviterei anche di pensare al livello di inventario del fornitore per Foo. Il rivenditore non sa nulla sull'inventario del fornitore. Il rivenditore conosce solo quanti articoli Foo sono presenti nell'inventario del rivenditore, e di quelli, quanti provengono dalla barra dei fornitori o dal fornitore Baz. Anche se il rivenditore non ha pagato il fornitore per l'articolo e anche se il fornitore non invia mai gli articoli al rivenditore (forse perché il fornitore viene spedito direttamente al cliente dopo che il rivenditore ha gestito la transazione), se il rivenditore può venderli articoli ai propri clienti, quindi tali articoli fanno parte della fornitura del rivenditore.
Ci sono 2 modi in cui un Fornitore potrebbe voler essere pagato: su ogni transazione, o periodicamente. Se il Fornitore desidera essere pagato ogni X giorni per gli articoli venduti dal Rivenditore. Quindi devi essere in grado di rispondere alla domanda: "Quanti articoli Foo dal Fornitore Baz ho venduto negli ultimi X giorni?" Se il Fornitore desidera essere pagato su ogni transazione, è comunque necessario sapere quale Articolo Foo in ogni transazione è stato inviato / assegnato dal Fornitore Baz.
Ancora: non costruire tutto da solo!
Ma se insisti, ho visto la spedizione modellare 2 modi diversi ed entrambi hanno funzionato bene. Un modo è quello di modellare tutto l'inventario consegnato come un centro di distribuzione separato. Ad esempio, se hai 45 negozi fisici e 5 magazzini, avresti 50 centri di distribuzione. È possibile trattare tutti i prodotti spediti in un centro di distribuzione separato. Ciò funziona particolarmente bene se i fornitori non inviano effettivamente il prodotto e il prodotto viene effettivamente spedito al consumatore dal fornitore.
L'altro modo in cui l'ho visto è usare un attributo type sul tuo Supply. Alcuni tipi di esempio potrebbero essere "buone condizioni", "leggermente danneggiati", "sicurezza" o, nel tuo caso, "acquistati" o "spediti". Pertanto potresti avere righe come le seguenti nella tua entità di fornitura:
id sku quantity type
-- ---------- -------- ---------
1 foo-item1 10 consigned
2 foo-item2 5 purchased
3 fooz-item1 20 consigned
Si noti che lo sku deve identificare un articolo in modo univoco e se si dispone di più fornitori per tale articolo, è necessario essere in grado di navigare dallo sku al fornitore.
E puoi anche trovare un ragionevole modello di dati open source per fatture e odori .