Hallo Community,
ich bin hier langsam am Verzweifeln.
In Meiner Abfrage zu Lagerbeständen nutze ich unter Kriterium die "WIE" und "NICHT WIE" Funktion.
Soweit so gut und für meine Bedürfnisse reichte es bisher.
Würde ich aber gerne das mit einer "WENN" Funktion verknüpfen, damit mir Lagerplätze nur dann ausgeblendet werden, wenn unter Bestand ( anderes Feld ) Wert>0 ist.
Folgendes habe ich mir aufgebaut :
Wenn([tab_lagerübersicht Abfrage]![Verfügbarer Bestand]>0;Nicht Wie "*INV*" Und Nicht Wie "*54*")
Mein Ziel ist es, das wenn Bestand >0 ist mir alle Lagerplätze welche INV oder die 54 beinhalten ausgeblendet werden.
Kommt natürlich entweder eine komplett leere Datenblattansicht oder eine Fehlermeldung.
Gibt es da eine Lösung ?
Würde mich freuen wenn jemand einen Tipp hat.
Vielen Dank schon mal
Roman
( ( [Verfügbarer Bestand] > 0 Und Nicht Wie "*inv*" Und Nicht wie "*54*" ) Oder [Verfügbarer Bestand] <= 0 )Bei Bestand > 0 werden inv + 54 ausgeblendet, bei Bestand <= 0 werden alle angezeigt.
@Normalo0815, es fehlen noch die Spaltenbezüge für die Not Like Bedingung.
In der Entwurfsansicht werden die Spaltenbezüge nicht angegeben, weil sie automatisch hinzugefügt werden (in SQL)! Sie werden nur angegeben, wenn sie eine andere Spalte, als dort wo das Kriterium steht, betreffen.
Zitat von: Normalo0815 am Juni 10, 2025, 18:21:17( ( [Verfügbarer Bestand] > 0 Und Nicht Wie "*inv*" Und Nicht wie "*54*" ) Oder [Verfügbarer Bestand] <= 0 )Bei Bestand > 0 werden inv + 54 ausgeblendet, bei Bestand <= 0 werden alle angezeigt.
Top vielen Lieben Dank, rettet mir sowas von den Tag :)
Zitat von: Normalo0815 am Juni 10, 2025, 18:39:35Sie werden nur angegeben, wenn sie eine andere Spalte, als dort wo das Kriterium steht, betreffen.
Echt, das wundert mich etwas.
Aber ich gebe zu, wenn dann nehme ich die SQL Ansicht und schreibe selbst. Der Assistent ist schon grauenhaft schlecht und dann noch in Deutsch :'(
Hallo Roman,
gibt es keine anderen Kriterien, um die Lagerplätze einzugrenzen? Bei Like mit Platzhalten in der Form kann kein Index verwendet werden und das ist deshalb nicht gerade performant.
Zudem wird in einer Datenbank ein "Bestand" normalerweise nicht in einer Tabelle abgespeichert, sondern der ergibt sich eigentlich aus der Bewegungstabelle mit den Zu- und Abgängen.
Gruß Knobbi38
Hallo,
Da kann doch was überhaupt nicht stimmen. Bei einem verfügbaren Bestand würde
ich immer einen Wert mit einem passenden Datentyp Zahl erwarten, und keinen
Text *).
"*inv*" deutet für mich auf einen Inventurbestand hin. Diese Info gehört aber
m.E. in ein eigenes Feld (Bestandstyp). Und wenn man auf eine Zahl ("*54*")
filtern will macht LIKE nicht viel Sinn, denn eine Zahl ist eine Zahl *). Würde
ich also immer mit "=" filtern.
Ansonsten bin ich bei Ulrich, Bestände werden on-the-fly ermittelt. Darfst du
nur nicht vergessen nach der Inventur eine evtl. aufgetretene Differenz über
eine "Inventurbuchung" zu erfassen.
gruss ekkehard
*) Zahlen als Text zu speichern macht nur in bestimmten Fällen Sinn, - PLZ oder
EAN-Codes z.B..
Hallo,
ich weiß nicht, warum sich das Gerücht hartnäckig hält, aber in einem großen Lager ist eine Bewegungstabelle zur Berechnung des aktuellen Ist-Zustandes ein absoluter Performancekiller. Stell Dir ein Lager mit 50.000 verschiedenen Teilen vor und Du hast für jedes eine History von 5.000 Bewegungen über die Zeit, dann müßtest Du, um den aktuellen Stand zu finden, alle 5.000 Bewegungen 50.000 mal berechnen, um von jedem Teil den Bestand in einem Endlosformular ausgeben zu können.
Eine Bewegungstabelle erstellt man natürlich trotzdem, aber nur, um eine History der Bewegungen zu haben und Dinge ggf. nachvollziehen zu können bzw. im Einzelfall Abweichungen zwischen Bestand und Bewegungshistory festzustellen. In dem Fall ist es nicht tragisch, wenn es nicht so performant ist. Aber für den Every-Day-Use in einem Lagerprogramm ist es absoluter Overkill. Merkt man als Developer mit 10 Testdatensätzen natürlich oft nicht, aber der Lagerist wird sich beschweren... :)
Gruß
Christian
Zitat von: knobbi38 am Juni 10, 2025, 23:35:28Hallo Roman,
gibt es keine anderen Kriterien, um die Lagerplätze einzugrenzen? Bei Like mit Platzhalten in der Form kann kein Index verwendet werden und das ist deshalb nicht gerade performant.
Zudem wird in einer Datenbank ein "Bestand" normalerweise nicht in einer Tabelle abgespeichert, sondern der ergibt sich eigentlich aus der Bewegungstabelle mit den Zu- und Abgängen.
Gruß Knobbi38
Hallo,
ich möchte eure Antworten und Fragen natürlich nicht unbeantwortet lassen :)
Ihr habt zum Teil Recht, und Bestände sollten sich natürlich auch aus den Warenbewegungen ergeben.
Es handelt sich jedoch in diesem Fall um einen Transitbestand in welchem Lagereinheiten mit beistimmten Bestand zwischen Montage und Logistik bewegt werden, ich möchte nur für mich eine Übersicht nach keinen Wünschen, und in bunt :)
Die Daten hole ich mir aus einer Excel Tabelle welche ich schnell aus dem SAP exportiere.
Und ich arbeite lieber mit Access und selbst erstellten Formularen und Berichten ;D
Sorgt auch immer für einen kleinen AHA Effekt bei den Kollegen aber das nur am Rande erwähnt ;)
In meinem Fall soll es sich aber wirklich um nichts großes handeln, sondern einfach nur um eine Erleichterung meiner Täglichen Aufgaben bei uns im Montage Lager.
Wie in diesem Fall eine Abfrage welche mir die aus der Logistik bereitgestellten Lagereinheiten anzeigt, und mir dabei auch schon den dazugehörigen Lagerplatz bzw. Lagerplätze bei mir in der Montage anzeigt,
an welchen ich das Material schon gelagert habe.
Und ja mit unseren Scannern kann man sich die Infos auch holen, aber das ist eine andere Geschichte welche nicht hierhin gehört :)
Ich führe also meine täglichen Aufgaben durch, überlege nebenher wie kann man einen Prozess ( wie zum Beispiel Waren Umlagern ) verbessern und beschleunigen kann, und versuche mir dann in Access mit den realen Daten etwas zu erstellen und dann zu testen.
Meistens gibt es eine Verbesserung des Prozesses, ich reiche einen Verbesserungsvorschlag ein, und ich gehe dann an die Kollegen aus der IT dann ran, und bitte um eine Umsetzung für unsere Scanner, damit alle Kollegen davon profitieren.
Ich habe auch festgestellt das ich unseren Kollegen von der IT auf diese weise manche Sachen besser erklären kann,
wenn ich etwas vorführen kann ;)
Und da unsere IT Abteilung echt mal anderes und genug zu tun hat, versuche ich direkt mit einer einfachen und getesteten und erprobteren Idee an zu kommen.
Quasi biete ich schon eine fertige Lösung an, bevor mir einer kommt und sagt, das geht nicht 8)
Das war mal doch eine Textmauer nun, ich hoffe das stört niemanden :)
Also vielen Dank für eure Tipps und Hilfe und ich hoffe ich kann mich in Zukunft weiterhin an euch wenden :)
Es soll sich wirklich nur um kleinere Datenbanken bzw. Abfragen drehen, welche mir faulen Sau nur ein paar Schritte bzw. Klicks auf dem Scanner oder SAP ersparen sollen ;)
Ich mache mir ein Formular welches mir auf einen Blick alle für mich relevanten Informationen, und entsprechende Berichte liefert, nachdem ich einfach eine Excel Tabelle aus SAP exportiere.
Keine hunderte SAP Fenster offen, keine unübersichtlichen Excel Tabellen. Reine Information.
Und ich mag es auch bunt :)
Vielen Dank euch
Grüße
Roman
@christian:
Ich stelle mir nicht nur ein Lager mit 50.000 Artikel von, sondern auch mit zigtausend Lagerplätzen. Natürlich werden Einzelbestände an den Lagerplätzen geführt, alleine schon zur Gewichtskontrolle bei den einzelnen Ladeeinheiten. Die Zu- und Abbuchungen bei der Anlieferung bzw. Auslieferung, werden dabei an das übergeordnete Warenwirtschaftssystem gemeldet und dort weiter verarbeitet, z.B. zur Kontrolle von Auftragsmengen/-beständen, tatsächlich gelieferter Ware usw.
Wenn man in solchen Lagersystemen den tatsächlichen, physischen Artikel-Lagerbestand, z.B. für eine Inventur benötigt, ist das dann in der Tat eine sehr langwierige und aufwendige Prozedur. Deshalb wird so etwas vermieden wo es nur geht.
Wenn man bei Lagern von "Beständen" spricht, muß man deshalb genau die Umstände mit definieren, wofür das dann gebraucht wird. U.U. kann es dann auch "redundante" Bestandsfelder aus Performancegründen in den verschiedenen Bereichen geben.
Grüße Knobbi38
Hallo Roman,
genau dafür ist ein Forum gedacht: Hier kann man sich zwanglos Tipps und Tricks aus den verschiedenen Anwendungsbereichen austauschen. Deinen Ansatz kann ich durchaus nachvollziehen, aber bedenke auch, daß die Softwareentwickler von Logistiksystemen durchaus an andere Vorgaben halten müssen und "bunt" wird i.d.R. halt nicht bezahlt. Solche Systeme wirken deshalb von außen betrachtet eher "altbacken" im Vergleich zu den schlanken, farbigen Access-Formularen und -Reports. Und gerade weil so viele Dinge bei der Softwareentwicklung in diesen Bereichen zu berücksichtigen sind, sind Änderungen nach Kundenwunsch auch nicht immer gerade preiswert.
Gruß Knobbi38