Lagerverwaltung - Datenmodell - Funktionen

    Das könnte jetzt in Vorrat oder IT passen, glaube aber erstmal ist der IT Bereich besser.
    Wenn man so die Foren durchschaut scheint es Bedarf an elektronischer Lagerführung zu geben, die meisten Projekte scheinen aber relativ schnell einzuschlafen. Bei OpenSource kommt man dann noch an die Daten und kann einige Zeit mit der alten Software weiterarbeiten, bei ClosedSource oder nicht mehr gepflegten Apps sind irgendwann die mühsam gepflegten Datenbestände verloren.
    Für meine eigenen Zwecke arbeite ich an einer Lösung auf LAMP Basis (Linux/Apache/mysql/PHP). Die zugrunde liegende Datenbank möchte ich aber so gestalten dass sie nicht nur auf mein kleines bis mittleres Projekt passt sondern auch größere wie kleinere Projekte abbilden kann. Das Ziel ist eine Datenbankstruktur definieren die von verschiedensten Projekten genutzt werden kann - und die Daten portabel macht. Eine API mit den grundlegenden Funktionen gehört natürlich auch dazu.


    Grundüberlegungen zur Datenbank:
    - Mandantenfähig, also mehrere getrennte Lager auf einer Datenbank. Aus Sicherheitssicht, gerade bei unseren Themen nicht das NonPlusUltra, da zumindest der Admin alles sieht, aber es bietet auch die Möglichkeit Testlager anzulegen ohne den Livebetrieb zu stören. Ist letztlich nur ein Feld mehr pro Tabelle
    - Erkennungsmerkmal für alles gelagerte soll die EAN/GTIN etc. sein. Für eigene Produkte (umgefüllt, selbst eingekocht etc.) kann eine entsprechende Nummer aus freien Bereichen generiert werden.
    - Kategorien (orientiert an den staatlichen Systemen)
    - Die Lagerhierarchie aus Lagerort->Regal->Ebene->Reihe->Unterfach sollte genug Flexibilität für alle Größenordnungen bieten. Mehrfachbuchungen auf ein Lagerfach sollen möglich sein (die wenigsten werden das so genau machen dass pro Produkt/MHD ein eigenes Fach zugewiesen wird...). Für Extremisten kann man ein Flag einbauen welches dieses Verhalten steuert.
    - alles auf UTF8 dürfte reichen
    - SET Fähigkeit, wenn man immer gleiche Pakete schnürt. Bei mir wären das zum Beispiel vakuumierte Pakete mit den Grundnahrungsmitteln für eine Woche/eine Person.


    Lizenz etc.
    - Code und Datenbankstruktur unter einer offenen Lizenz, weiß aber noch nicht ob GPL, BSD oder sonst eine günstiger ist.
    - Da gepflegte und freie EAN Datenbanken eher Mangelware sind steht sicher etwas Handarbeit an. Gesammelte Daten (EAN,Name,Nährwerttabelle, Kategorie Zuordnungen) sollen untereinander frei tauschbar sein und wenn gewünscht in gesammelter Form jedem offen stehen.


    offen für alle Anregungen - habe ähnliches bereits in einem sehr alten Thread geschrieben - wahrscheinlich zu alt.

    Zuerst einmal wünsche ich deinem Projekt ein langes und erfülltes Leben!


    Ich habe meine Vorschläge in die beiden Komponenten "Software" und "Datenbank" unterteilt, damit leicht erkennbar ist, wo ich sie verorte:


    Software:

    • "Umzugsfunktion" (wenn ein Lebensmittel von Regalplatz X nach Y umgesiedelt wird; z.B. aus Platzgründen)
    • Falls EAN als Schlüssel eingesetzt wird: EAN-Generator (für eigene Lebensmittel; um nicht selbst die richtigen Nummern aus dem frei verfügbaren Pool heraussuchen zu müssen und Dubletten zu vermeiden
    • Suchfunktion für bereits eingetragene Artikel
    • Dublettenprüfung
    • Wenn schon mandantenfähig, dann auch gleich mit (optionalem) Berechtigungskonzept.
    • RDA-Rechner (ggf. mit mehreren RDAs, weil ja auch jeder Wirtschaftsraum, tlw jedes Land, seine eigenen Empfehlungen hat)
    • Import- und Exportfunktion, ggf. alternativ maschninenlesbar und für Menschen lesbar


    Datenbank:

    • Ich würde die EAN nicht als Schlüssel verwenden, maximal als einfaches Datenfeld (und nicht mal als Muss-Feld). Hintergrund: Ich kaufe Lebensmittel X nicht immer von der selben Firma (z.B. weil heute Inzersd*rfer in Aktion ist und morgen F*lix, ...). Für mich ist aber Chili con Carne im Großen und Ganzen gleich Chili con Carne. Oder die Baked Beans von Heinz mal mit Chili, mal ohne. Die Unterschiede beim Nährwert zwischen zwei Marken bzw. Sorten sind vermutlich geringer als zwischen zwei selbst gekochten Chargen.
    • Möglichkeit, Mikro- und Makronährstoffe zu erfassen. (Protein- Fett- Wasser- Kohlenhydrat- und Zuckergehalt, Mineralstoffe, Vitamine, Spurenelemente). Und natürlich kcal/kJ.
    • Neben Gramm als Gewichtseinheit auch Stück, Portion (speziell für Vitamine interessant) und Liter vorsehen.


    LG, viel Glück und einen langen Atem,



    Maresi

    Arbeite, als wenn du ewig leben würdest. Liebe, als wenn du heute sterben müßtest.

    Zu den EAN Datenbanken
    Die fddb Datenbank hat doch sogar eine API für externe Zugriffe und ist free.
    https://fddb.info/api/v18/documentation/


    [USER="2997"]Maresi[/USER] Leider ist es eben gerade nicht so, dass insbesondere bei Fertiggerichten, der Inhalt zwischen den verschiedenen Herstellern austauschbar ist.
    Die Preisunterschiede resultieren durchaus aus dem variierenden Anteil an Wasser oder "billigen Kalorien" wie Industrie-Zucker oder Getreide.
    Gerade für diejenigen, die ihre Vorratshaltung auf Fertigprodukte und "Dosen" aufbauen, wäre ein Bezug auf eine fertige Datenbank Gold wert.


    Ich nutze die FDDB Datenbank über den Extender zur Ernährungsplanung. Das funktioniert super.

    [USER="2997"]Maresi[/USER] denke für den Input, die meisten Punkte sind berücksichtigt, aber tatsächlich ein Punkt ist eine richtige Nuss. Nämlich die Behandlung gleichartiger Produkte von verschiedenen Herstellern. Bzgl Nährwerten: die typische Tabelle ist bereis abgebildet, Vitamine aber noch nicht berücksichtigt, wird aber eingeplant.
    zum Einwand von [USER="11351"]Abendrot[/USER] zur Austauschbarkeit verschiedener Hersteller: Habe gerade die günstigen Tomatenheringe verschiedener Hersteller verglichen, schaut auf den ersten Blick identisch aus, die Detailangeben veriieren dann doch recht stark. Jetzt wahrscheinlich nicht "missionsentscheidend" aber doch so dass bei der Bedarfsberechnung einige Dosen Unterschied wären.
    Zur FDDB Datenbank. Der Datenbestand ist richtig gut, aber einer der ersten Punkte in den Nutzungsbedingungen der API ist dass weder ein vollauszug noch lokale Kopien zulässig sind. Leider funktioniert das nicht mit meiner Planung, die relevanten Daten auch offline nutzen zu können. Rein technisch könnte man sich sicher alles ziehen, die moral verbietet aber die Nutzung.
    Rein theoretisch könnte man so einen Wikileaks Ansatz nutzen: die "irgendwie" erlangten wertvollen Infos nur verschlüsselt verteilen und im SHTF auf allen noch existierenden Kanälen den Schlüssel verteilen - moralisch vertretbar :)
    Eine Datenbank die auch den kompletten Download ermöglicht habe ich noch nicht gefunden.
    Aber abgesehen davon, gescannte einzelne Artikel auch lokal zu übernehmen wäre denkbar - wäre also in einer realen Anwendung sicherlich eine gute Komfortfunktion.

    Ich finde, das ganze System MUSS offline lauffähig bleiben. Von daher wäre es schon gut, wenn zu Friedenszeiten "gesammelte" Informationen, seis von fddb oder anderen Quellen, lokal verspeichert werden.


    Ich habe vor ein paar Jahren hier im Forum mal eine "Vorratsdatenbank" vorgestellt. Allerdings keine echte DB Applikation sondern eine Excel Datei. Vom Funktionsumfang wäre die für mich so in etwa das Minimum-Requirement an ein neues System.


    1. Artikeldatenbank (Artikel-ID, Namen, Preise, Bezugsquellen, Nährwert und Nährstoffverteilung, Artikelkategorie, Mindestlagerstand)
    2. Lagerstandsführung mit Einlagerdatum, Lagerort, MHD, Artikel-ID
    3. Automatische Erstellung von Einkaufslisten, basierend auf den Mindestlagerständen und/oder MHD
    4. Automatischer Bericht über abgelaufene und bald ablaufende Artikel
    5. Personendatenbank mit Alter, Geschlecht, Tätigkeitsniveau (Für Bedarfsberechnung)
    6. Bedarfsberechnung und Reichweitenberechnung der vorhandenen Lebensmittel
    7. Nährstoffübersicht der eingelagerten LEbensmittel basierend auf empfohlener Verteilung.


    Könnte ich programmieren, hätte ich es wohl mit einer Datenbank gelöst. Kann ich aber leider nicht. Dafür macht mir in Excel keiner was vor. :winking_face:


    LG. Nudnik

    Aber zum Betrieb der Datenbank ist doch gar keine Vollkopie der FDDB Datenbank nötig.
    In "Friedenszeiten" werden die Informationen aus der FDDB bei der Einlagerung des Artikel abgerufen und dann verarbeitet und die erlangten Informationen lokal gespeichert. Das ist in keiner Weise eine Verstoss gegen die API Richtlinie.
    Offline ist diese Komfortsituation eben nicht gegeben und man muss händisch eingeben.

    Da in der Überschrift Datenmodell steht habe ich mal angefangen eines zu basteln :)


    Produkt
    -------
    Produkt_ID INTEGER
    Produkt_NAM VARCHAR(50)
    Produkt_TXT VARCHAR(255)


    Bestandteil
    -----------
    Bestandteil_ID INTEGER
    Bestandteil_NAM VARCHAR(50)
    Bestandteil_TXT VARCHAR(255)


    Einheit
    -------
    Einheit_ID
    Einheit_NAM VARCHAR(50)
    Einheit_TXT VARCHAR(255)


    BestandteilMenge
    ----------------
    Produkt_ID INTEGER
    Bestandteil_ID INTEGER
    Menge_NUM DECIMAL(8,2)
    Einheit_ID INTEGER



    Beispiel
    ========


    Produkt
    1 - Gulasch - Das tolle Dosengulasch mit leichter Chilli Note


    Bestandteil
    1 - Brennwert
    2 - Eiweiß
    3 - Kohlenhydrate
    4 - Zucker
    5 - Fett
    6 - gesättigte Fettsäuren
    7 - Ballaststoffe
    8 - Natrium
    9 - Vitamin C
    10 - Salz


    Einheit
    1 - Gramm
    2 - Prozent
    3 - kcal


    BestandteilMenge
    1 - 1 - 110 - 3
    1 - 5 - 5,5 - 1
    1 - 6 - 1,6 - 1
    1 - 3 - 4,7 - 1
    1 - 4 - 0,9 - 1
    1 - 2 - 10 - 1
    1 - 10 - 1,1 - 1


    Was natürlich noch fehlt:
    * Verpackung/Gebinde (Dose, Flasche, Glas, Papier, ...)
    * Hersteller - könnte eventuell Teil des Produktes sein
    * Einkauf (Geschäft, Datum, Preis, Anzahl, Rabatt, ...)
    * Lagerort - Frei definierte Hierarchie ... Wohnung - Zimmer - Regal - Etage - Kiste - ...
    * Kategorie (Dosenfutter, Beilage, ...)
    * Zustand (Dosenfutter, MRE, roh, gekocht, ...)
    * Rezepte


    Offen
    MHD ... Wenn ich 5 Dosen des gleichen Produktes im gleichen Shop kaufe kann ich aber trotzdem 5 MHD haben


    Mir fallen sicher noch 100 Sachen ein ... aber bevor ich weiterdenke: Geht das in die richtig Richtung?

    Das MHD ist eh keine Produkteigenschaft, gehört also nicht in die Produkttabelle. Das ist eher eine individuelle Eigenschaft jedes einzelnen gekauften Artikels.
    Ss gibt also das Produkt Dosengulasch mit ID xy und den entsprechenden Eigenschaften lt. Produkttabelle und die gekaufte Dose hat die Eigenschaften Produkt_ID + EK_Datum, MHD, Gebindeart, Lagerort etc.....

    Da ich mich beruflich mit Materialwirtschaft und Stammdaten beschäftige, hier ein paar Anregungen:


    identische Artikel, die von verschiedenen Herstellen kommen, sollten nur eine Identnummer haben. Weicht irgendwas ab, so dass das Produkt nicht 1:1 austauschbar ist, eine neue Nummer vergeben (Austauschbarkeit kann jetzt wieder sehr subjektiv sein: mir wäre es (erbs-)wurscht, ob die Ravioli von Firma X oder Y sind. Jemand, der die Nährwerte oder so was berücksichtigen möchte, sieht das vielleicht anders)


    Die Verknüpfung eines Artikels mit verschiedenen Herstellern / Hersteller-Artikelnummern kann man mit einem separaten Datensatz realisieren, der (mindestens) diese Daten enthalten sollte:

    • Artikelnummer (die eigene)
    • Hersteller
    • Herstellerartikelnummer

    Damit kann ein "eigener" Artikel (dem würde ich eine eigene, generierte, Nummer verpassen) auf verschiedene Produkte unterschiedlicher Hersteller verweisen.


    Alles in allem, daran denken:
    Der Verwaltungsaufwand ist enorm hoch!
    Ihr seid ja wahrscheinlich Stammdatenverwalter, Softwareentwickler, IT-Abteilung, Einkäufer, Wareneingangssachbearbeiter, Lagerist und Buchhalter etc. in einer Person!
    Meiner Meinung nach, muss das Lager schon eine ordentliche Größe aufweisen, damit sich der Aufwand lohnt! (Wer von Euch betreibt eine Lagerhalle?)
    Schließlich bewegt sich da mindestens täglich was und das muss im System nachgehalten werden, sonst herrscht da ruck zuck Chaos!


    Trotzdem ist das ein schönes Entwicklungsprojekt.


    Gruß, Schwarzstart

    -<[ N u n q u a m - N o n - P a r a t u s ]>-