[GELÖST] Komplizierter Filter

11. November 2009 09:49

Hallo Leute,

ich hätte da mal ein Problem, wo ich nicht mehr weiterkomme:

Ich habe eine Tabelle "Artikel", in dieser Tabelle befindet sich ein FlowField welches den Lagerbestand errechnet. Wenn ich mir den Lagerbestand dann ansehe, komme ich auf die Artikelposten, welche die entsprechenden Wareneingänge und Buchungen zeigen.

In den Artikelposten habe ich dann entsprechende Zeilen, wo jeweils ein Lagerortcode hinterlegt ist. Die Lager sind bei mir in "extern" und "intern" unterteilt (in der Tabelle "Location").

Gibt es eine Möglichkeit, bei den berechnteten Lagerbestand der Artikel nur die Zeilen einzubeziehen, dessen Lager "intern" ist?
Ich habe da schon mehrfach versucht das zu realisieren, ich bin aber immer darn gescheitert, dass die Information, ob das Lager "intern" oder "extern" ist, nicht in den Artikelpoten vorhanden ist.

In der Tabelle Artikel habe ich bereits einen FlowFilter "Lagerortcode" standardmäßig drin. Kann man das ganze Konzept über die Erweiterung dieses Filters abbilden?

Bitte um Hilfe :-)
Grüße
Zuletzt geändert von Rabe_Nitz am 16. November 2009 13:20, insgesamt 1-mal geändert.

Re: Komplizierter Filter

11. November 2009 09:55

Rabe_Nitz hat geschrieben:In der Tabelle Artikel habe ich bereits einen FlowFilter "Lagerortcode" standardmäßig drin. Kann man das ganze Konzept über die Erweiterung dieses Filters abbilden?


Mal angenommen, LagerX und LagerY tragen das Kennzeichen "intern", dann kannst du in den Artikel-Flowfilter "Lagerortfilter" eingeben: LagerX|LagerY.
Probier das einfach mal aus; ich meine, FlowFields hätten bei solch einem Filter schon mal Probleme habt.

Wenn das nicht funktionieren sollte, müsste programmiert werden.

Re: Komplizierter Filter

11. November 2009 10:27

Hallo Natalie,

erstmal Danke für deine Hilfe!
Das Problem ist, dass sich die Lager ständig erweitern. Es kann durchaus sein, dass morgen 2 interne un 4 externe Lager dazu kommen.
Eine dynamische Möglichkeit gibt es da nicht oder?

Grüße

Re: Komplizierter Filter

11. November 2009 10:50

Rabe_Nitz hat geschrieben:Eine dynamische Möglichkeit gibt es da nicht oder?

Schon, aber die müsste erst programmiert werden. Bis dahin kann ein Benutzer aber ja durchaus selber gucken, welche Lagerorte das Kennezeichen tragen und sich dann den Filterstring selbst zusammenbauen.

Re: Komplizierter Filter

11. November 2009 11:22

Das ist ein wenig aufwendig, bei über 300 Lager und oftmals über 100 Zeilen in den Posten. Das Problem ist auch, für Power-User ist das ja nicht so das Problem, für den Normalanwender jedoch schon. :)

Wie könnte man das aber über die Programmierung lösen? Habe dazu keine Idee wie man das machen könnte.

Grüße

Re: Komplizierter Filter

11. November 2009 11:42

Ich würde das Lagerortkennzeichen an die Artikelposten weitergeben. Die beiden Flowfields ergeben sich dann ja von selbst.

Re: Komplizierter Filter

11. November 2009 12:00

Habe ich mir auch schon gedacht.

Ich versuche es mal auf diese Art. Danke für eure Hilfe!!

Grüße

Re: Komplizierter Filter

11. November 2009 18:29

Bei einem Zusatzfeld in den Posten müssen aber alle Artikelposten ab dem ersten nachversorgt werden (erfordert Entwicklerlizenz),ein neues Flowfilterfeld (Lagertyp o.ä.) in die Artikeltabelle ( analog zum Boolfeld "Direktlieferungsfilter" ), die Calcformulas für "Lagerbestand" und "Bewegung" um das neue Feld erweitern und die Schlüssel auf den Posten ggf. erweitert werden. Einen vergleichbaren Fall wir hier schon mal mit einem Statusfilter.
Einige Flowfields, die man ggf. für Lagerkennzahlen benötigt, wie Verbrauch (MW) etc. gehen außerdem auf die Wertposten. Dann müssen die natürlich auch bedacht werden.

Re: Komplizierter Filter

12. November 2009 11:32

Das habe ich jetzt nicht alles verstanden :-)

Das bedeutet aber schon, dass ich in jedem Fall ein Feld in den Artikelposten hinzufügen muss oder?
Einer unserer Partner meint, dass ich kein Feld hinzufügen muss, es muss lediglich das FlowFilter Feld "Lagerort" um ein Filter-Kriterium erweitert werden (und zwar, nennen wir das Feld mal Status, ob es "intern" oder "extern" ist.)

Grüße

Re: Komplizierter Filter

12. November 2009 22:20

Rabe_Nitz hat geschrieben:Das bedeutet aber schon, dass ich in jedem Fall ein Feld in den Artikelposten hinzufügen muss oder?

Das Feld muss in die Posten, aber eben auch rückwirkend versorgt werden.
Rabe_Nitz hat geschrieben:Einer unserer Partner meint, dass ich kein Feld hinzufügen muss, es muss lediglich das FlowFilter Feld "Lagerort" um ein Filter-Kriterium erweitert werden (und zwar, nennen wir das Feld mal Status, ob es "intern" oder "extern" ist.)

Dann würde ohne Schlüsselerweiterung eine Fehlermeldung kommen, dass der Wert des Flowfields "Lagerbestand" nicht berechnet werden kann (netterweise mit genauer Angabe , was getan werden muss :wink: )
Der Lagerbestand in NAV ist ja nicht gespeichert, sondern nutzt die SIFT und wird immer zur Laufzeit aus allen Artikelposten errechnet (deshalb müssen die alten ja nachversorgt werden). Die Werte werden in Forms automatisch berechnet oder im Code mit CALCSUMS ermittelt, damit die SIFT aber funktionieren kann, müssen die relevanten Datensätze in der Postentabelle eindeutig abgegrenzt werden können und alle möglichen Kombinationen vorgehalten werden. Wenn also weitere Unterteilungskriterien als neue Anforderung dazukommen, müssen die Sekundärschlüssel, die die Menge als SumIndexField haben, in der Postentabelle erweitert werden.

Re: Komplizierter Filter

13. November 2009 12:38

Eine Lösung währe allerdings noch, wenn deine externen Lagerorte z.B. alle mit 'E' beginnen und deine internen mit 'I', dann kannst du im Lagerorfilter 'E*' oder 'I*' angeben. Das funktioniert dann ohne Erweiterung der Posten.

Gruß, Fiddi

Re: Komplizierter Filter

16. November 2009 13:19

Stimmt,

das ist der einfachste Weg. Dass ich nicht sofort darauf gekommen bin.. Manchmal ist es sinnvoller das Problem auch mal von weiter weg zu betrachten. :-D

Vielen Dank fiddi!!!

Re: [GELÖST] Komplizierter Filter

16. November 2009 17:07

Bei der Lösung müssen alle Felder mit Lagerortcodes eine korrekte TableRelation auf die Tabelle Lagerort haben. Das sollte man mindestens bei etwaigen Individualfeldern vorher noch mal überprüfen und ggf. ergänzen bevor der RENAME angestoßen wird.