FIFO - 2
Hallo Leute,
ich habe gestern hier einen Post gemacht, der ist - wie ich mich kenne - vermutlich zu lang und zu wenig konkret.
https://forum.ninox.de/t/35h9b8v/fifo-wie-macht-man-das-am-besten
Inzwischen sind meine diesbezüglichen Überlegungen vorangeschritten, deswegen hier mal eine konkrete Fragestellung. Die folgende Abbildung zeigt eine Tabelle mit Lagerbewegungen.
Ich benötige für eine automatische Erzeugung eines Abgangs die folgenden Informationen, quasi "on the fly" für eine angenommene Abfrage, bei der wir das Lager und die SKU mitliefern
Summe der ältesten Charge welche größer als 0 ist.
Im Beispiel würde das gesuchte Ergebnis lauten
Charge = 123
Summe = 73
Wie würdet Ihr das abfragen? Bekommt man das in einen schlanken Code, oder ist der Weg eher, mit mehreren Variablen Schritt für Schritt zum Ziel zu gelangen?
Mein Ziel ist nach dem FIFO Prinzip einen Abgang zu erzeugen, der die richtige Charge (älteste mit ausreichendem Bestand) anspricht.
Danke schon mal für jede Hilfestellung.
10 Antworten
-
Spontane Idee für eine mögliche Herangehensweise: Man könnte die Chargen in einer eigenen Untertabelle der Lagerbewegungen speichern und die Zu-/Abgänge wiederum den Chargen unterordnen. Dann hätte man in Formel- oder per Trigger gefüllten Datenfeldern der nächsthöheren Ebene stets aktuelle Summen, die sich im Bedarfsfall sehr einfach abfragen ließen.
Ist jetzt nicht tiefer durchdacht, aber bei einer solchen Aufgabenstellung (so ich sie denn richtig verstehe) wäre das wahrscheinlich mein erster Ansatz.
-
das klingt super und ich glaube, so macht das auch meine jetzige Warenwirtschaft, also mit den Chargen in eigenen Untertabelle. Entsprechend kam mir der Gedanke auch schon mal, aber meine grauen Zellen können den Ansatz nicht so recht in ein Bild formen.
Am besten ist sicher, das mal in der Praxis auszuprobieren.
Im Grunde geht man dann wohl einfache eine Ebene tiefer mit dem Bestand, nämlich in die Untertabelle "Chargen", richtig? -
also ich merke, das scheint mir der richtige, viel bessere Ansatz zu sein. Hier mal eine Testausgabe
Jetzt frage ich mich nur, wie kommt meine Abfrage ins Spiel? Ich bringe mit eine Anzahl X für einen Warenausgang, sagen wir mal 10 Einheiten, für den Artikel MF1001, und ich muss nun wissen, welche ist die älteste Charge, die noch Bestand hat?
Ein Skript soll hier in die Tabelle einen neuen Datensatz erzeugen und muss vorher wissen, welche Charge es nehmen muss und in manchem Fällen müssten (theoretisch) sogar mehrere Datensätze erzeugt werden, wenn die Menge für den Ausgang die Summe einer einzelnen Charge übertrifft.
Wie macht man das? Mit einer select Abfrage? Oder geht es auch direkt?
-
-
Ich finde einfach den Einstieg nicht. Ist für meine Windungen wohl zu abstrakt.
Wie greife ich die Bestände ab, von den Chargencodes, sortiert nach positivem Bestand, und Alter? Ich schaffe (Stand jetzt) nichtmal den Bestand je Charge mit einer Abfrage zurück zu geben.-
Anbei mal ein kleines Beispiel für ein mögliches Datenmodell mit drei Ebenen und einigen Abfrage-Möglichkeiten im Dashboard.
-
ich habe mich mal ein bisschen umgeguckt, und das hilft mir schon mächtig weiter.
Das Highlight für mich ist ja, dass die Struktur der DB wesentlich anders ist, als ich gedacht habe.
Bei mir ist es ja genau andersrum, die Chargen sind Untertabelle der Lagerbewegung.
Hat es tatsächlich einen Effekt, dass es in deinem Beispiel einfacher ist? Jedenfalls ist die Möglichkeit die Chargenbestände zu führen offensichtlich einfach. -
Wie heißt es so schön: Viele Wege führen nach Rom. Insofern kann ich nicht sagen, dass mein beispielhafter Ansatz generell besser wäre als ein anderer. Er war nur als Anregung gedacht, wie man die Aufgabenstellung, so, wie ich sie verstanden hatte, rein technisch angehen könnte. Völlig losgelöst von anderen Aspekten wie Workflows oder weiteren Funktionalitäten, die in der Praxis natürlich auch immer eine Rolle spielen.
Aber wie gesagt: Von der Logik her lag es für mich erst mal näher, die Artikel in Chargen zu unterteilen und die Lagerbewegungen dann auf die Charge zu beziehen. Schau's dir halt einfach in Ruhe an. Wenn du dich am Ende für ein anderes Datenmodell entscheidest, ist das natürlich vollig in Ordnung. Immerhin tätest du es dann nach reiflicher Überlegung, was ja auch schon viel wert ist.
-
ja vielen Dank. Es ist auch genauso wie du sagst: Dadurch dass man neue Perspektiven sieht, kommt man am Ende zur besseren Lösung. Und genau das, also das Finden der passenden Datenstruktur ist bereits für mich eine große Herausforderung.
Ich muss da noch weiter drüber nachdenken. Von der Logik ist ja deine Unterteilung auch genau der Realität entsprechend. Tatsächlich ist die Charge die kleinste Einheit in der Hirarchie und genau dieser folgt die Bewegung.
Lager > Artikel > Charge > Bewegung
Das ist schon schlüssig...
Ich glaube, mein Problem ist vielleicht auch, dass meine Datenstruktur schon ordentlich durchgemischt ist..
-
Ein Vorteil von Ninox ist ja, dass man nicht erst detaillierte Datenfluss- und Programmablaufpläne erstellen muss, sondern direkt loslegen kann. Es kann aber natürlich nicht schaden, vorher über seine Prozesse nachzudenken, ein mögliches Datenmodell zu skizzieren und gerade am Anfang der Entwicklung immer wieder zu überprüfen. Sonst wuchert die Anwendung schnell in alle Richtungen und macht spätere Änderungen deutlich schwieriger. Möglich sind sie aber immer, deshalb sollte man auch nicht zu lange grübeln und nach der perfekten Lösung suchen, die alle Eventualitäten berücksichtigt. Wie so oft, gilt es also auch hier wieder mal, den goldenen Mittelweg nach Rom oder wohin auch immer zu finden.
-
-
das ist aber cool
. Vielen Dank. Da muss ich mich jetzt erst mal ein bisschen umsehen. Das ist total nett.
Content aside
- vor 1 JahrZuletzt aktiv
- 10Antworten
- 79Ansichten
-
2
Folge bereits