inventario / magazzino in più posizioni

1

Sto lavorando a un sistema di gestione del magazzino (WMS) che deve supportare il magazzino in più posizioni. Potrebbe trovarsi in un edificio diverso, potrebbe essere memorizzato in n * luoghi di un edificio (un esempio rapido potrebbe essere magazzino, overflow o slot rapido tutti contenenti una quantità dello stesso articolo).

Dove sono, hanno sempre usato una SKU assegnata a un contenitore con note di carta che puntavano all'overflow. Ovviamente sono cresciuti oltre questo e sta causando alcuni problemi seri. Nessuno qui può aiutarmi quando cerco di ottenere ciò che dovrebbe essere la migliore pratica.

Ho problemi a concettualizzare come configurare la struttura.

Sto pensando ...

  • Magazzini (virtuali o fisici) I magazzini possono appartenere ai magazzini.
  • Posizione - Qualcosa potrebbe davvero essere un pallet, una scatola o solo un'area tappata sul pavimento. Le posizioni appartengono ai magazzini.
  • Righe - possono trovarsi in posizioni
  • Gli scaffali possono essere nelle righe
  • slot (tradizionalmente chiamato un raccoglitore qui) l'unità più piccola che può essere una posizione.

Quindi una SKU potrebbe trovarsi in una o più di queste posizioni (ad eccezione del magazzino virtuale, utilizzato solo dal raggruppamento di ubicazioni fisiche ma consentendo a un ordine di vendita di elaborarle internamente come se stesse spedendo da uno spazio).

Le località (sono i loro figli) potrebbero avere la priorità. Quindi se una SKU si trova in 2 posizioni, i sistemi sanno quale slot (bin) vuotare prima di eseguire il routing al successivo.

Lo codifico in modo tale che le strutture di cui sopra possano essere gestite dal magazzino poiché non mi interessa fisicamente solo che il processo ha senso e quindi dare loro uno strumento per contrassegnare un ordinamento in modo che possano determinare il migliore rotte attraverso il magazzino con la raccolta in batch di un ordine.

Credo che volevo solo togliermelo dalla testa e farmi vedere da qualcuno prima che scrivessi una singola riga di codice.

Questa struttura ha senso? È una buona pratica? Se no, che cosa è e se quella domanda è al di fuori del regno del sito qualcuno potrebbe indicarmi?

    
posta Ominus 13.09.2013 - 16:29
fonte

1 risposta

1

L'incapsulamento sarà la chiave per assicurarti di iniziare con la struttura giusta.

Avrei un'entità primaria per il bene vendibile ( widget ), di cui lo SKU è una proprietà di tipo identità. I beni vendibili o widgets sono i tuoi oggetti di base in quanto è ciò che viene venduto. Gli SKU possono cambiare anche se sono piuttosto rari.

Ogni widget può avere zero o più locations , quindi avrei una raccolta di locations all'interno del widget.

Ogni location avrà un peso relativo che rappresenta la disponibilità o location cost per quel set di widgets . Consiglierei di rendere location cost un oggetto di prima classe e non solo un valore. Location cost è un termine relativo basato su dove si trova il chiamante. Se sono su un sito, desidero il back-of-store widgets anziché widgets in un'altra posizione fisica. Come minimo, devi nascondere l'implementazione di location cost ai chiamanti esterni in modo da poterla più facilmente adattare in futuro.

Per supportare l'integrità referenziale, vorrei rendere il metodo widget.count() iterare su tutte le posizioni e contarle. Altrimenti finisci per raddoppiare la quantità di azioni che devi fare, una volta per widget e ancora per location .

    
risposta data 15.09.2013 - 15:16
fonte

Leggi altre domande sui tag