[gelöst] Flow Fields mit unterschiedlichen Filtern

Hallo zusammen,

nachdem ich nun fast am Verzweifeln bin und nicht mehr weiter komme wollte ich euch mal um Rat bitten.

Folgende Anforderung:
Auf der Artikeltabelle gibt es ja standardmäßig ein FlowField mit der Summer Menge in Auftrag. Das Flowfield bildet mir brav die Summe der Mengen in den Verkaufszeilen. Soweit so gut.

Nun habe ich ein weiteres Flowfield angelegt, dass im Prinzip das selbe macht. Einziger Unterschied ist, dass ein Filter auf Bestimmte Kundennummern angelegt wurde.
Das Flowfield soll mir also nur die Menge zurückgeben, die in Aufträgen der speziellen Kunden vorhanden sind.

Das Standard Flowfield soll dann natürlich umgekehrt funktionieren, also die Summe bilden aus allen Kunden ausser diesen Speziellen.

Damit das mal einfacher ist (Debitornummer):
Spezielle Kunden Filter: 0..99
Alle anderen Kunden Filter: 100..99999999

Leider funktioniert immer nur eines der Beiden Flowfields. Wenn man dann den Filter im RTC in der FactBox prüft stimmt dieser zwar laut Eingabe, aber Dynamics NAV liefert einfach die falschen Werte.

Was mache ich falsch?

Grüße und Danke
Dennis

Zuletzt geändert von x-designs am 22. Januar 2013 11:25, insgesamt 1-mal geändert.

Sind bei euch die Debitorennummern wirklich unterschiedlich lang? Dann hast du mit einer von...bis-Filterung auf Codefeldern Probleme.
Wenn du solch einen Filter z.B. auf die Debitorenübersicht anwendest, werden dann die richtigen Debitoren angezeigt oder sind auch Ausreißer dabei?

Leider funktioniert immer nur eines der Beiden Flowfields.

Was gemau meinst du damit? Was "macht" dann das andere?

Hallo Nathalie,

aktuell zeigen beide Felder das selbe an, obwohl verschiedene Filterkriterien vorhanden sind.

Die Filter funktionieren nicht, oder Navision hat irgendwo intern eine Variable die für beide Felder gelten... Irgendwie seltsam.

Wenn man sich die grafiken anschaut sieht man gleich, dass das Ergebnis nicht mit den Filterkriterien übereinstimmt.

Grüße
Dennis

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Filter 1: Geanu was ich befürchtet habe. In der ASCII-Sortierung ist 61 tatsächlich innerhalb 100..999999
Filter 2: Hätten da schon mehr Datensätze gezeigt werden sollen? Gibt es tatsächlich Zeilen für z.B. Rech. an Debitor 73? Wenn nicht, können die erst recht nicht im Filter 100...999999 auftauchen.

Übrigens, ein FlowField zeigt auf Rech. an Debitor, das andere auf Verkauf an Debitor - ist schlecht zum Vergleichen

Ich behaupte, NAV zeigt das Richtige an ...

Hi Nathalie,

ich hatte gerade fragen wollen wie es nun richtig geht, dann ist mir dank Dir die Lösung gekommen:

Filter 1: <>71&<>73&<>76&<>61&<>63&<>66
Filter 2: 71|73|76|61|63|66

haha und schon geht's, bzw. es scheint zu gehen. Werde das am Montag noch besser testen bevor ich das live nehme.

Die ASCII-Sortierung bringt mich übrigends noch irgendwann um. Ich muss mir fast täglich das Gemecker von den Kollegen anhören. Da hatte die gute alte Nativ DB einfach besser funktioniert.

Vielen Dank mal und bis bald.

PS: ich schieße den Threat dann nach erforlgreichem Testen.

Danke + Gruß

Da hatte die gute alte Nativ DB einfach besser funktioniert.

Anders, nicht besser. Ich denke mit Grauen an Zeiten zurück, als Benutzer kaum gleichzeitig im gleichen Bereich arbeiten konnten, weil Tabellen komplett gesperrt wurden.
Und würdet ihr eure (Debitoren-)Nummern zum Beispiel mit Hilfe von führenden Nullen auf die gleiche Länge bringen, wäre die ASCII-Sortierung auch kein Thema mehr.

Wollt ich nur loswerden

Und würdet ihr eure (Debitoren-)Nummern zum Beispiel mit Hilfe von führenden Nullen auf die gleiche Länge bringen, wäre die ASCII-Sortierung auch kein Thema mehr.

Das sagt jeder Navision Berater wenn man dieses Thema anspricht. Nur Leider schaut das in der Praxis tot anders aus.
Beispiel: Führende Nuller schauen blöd aus in Print Katalogen, dem Web usw. Das ist aus Berater sicht vielleicht eine Option, aber nicht aus Anwendersicht. Und der Kunde will immer alles einfach haben. Ich kann mir schon das gemecker am Telefon vorstellen bei dem die sagen warum sind da so viele 0er...

Aber das ist wie bei allem im Leben. Kein Vorteil ohne Nachteil.

Ich dank dir mal ganz herzlich für die Hilfe.

Grüße
Dennis

Und würdet ihr eure (Debitoren-)Nummern zum Beispiel mit Hilfe von führenden Nullen auf die gleiche Länge bringen, wäre die ASCII-Sortierung auch kein Thema mehr.

Das sagt jeder Navision Berater wenn man dieses Thema anspricht. Nur Leider schaut das in der Praxis tot anders aus.
Beispiel: Führende Nuller schauen blöd aus in Print Katalogen, dem Web usw. Das ist aus Berater sicht vielleicht eine Option, aber nicht aus Anwendersicht. Und der Kunde will immer alles einfach haben. Ich kann mir schon das gemecker am Telefon vorstellen bei dem die sagen warum sind da so viele 0er...

Aber das ist wie bei allem im Leben. Kein Vorteil ohne Nachteil.

Ich dank dir mal ganz herzlich für die Hilfe.

Grüße
Dennis

Hier offenbart sich ein gewisses fehlendes Wissen.
Der Berater schlägt vor, dass auf der Ebene der Datenstruktur euere Artikelnummern (primary key) gleich lang sind.
Du dagegen argumentierst auf der visuellen Ebene, die eine Schicht darüber liegt.

Wenn ein Artikel in der ItemTable die Nummer 00004711 hat, ist es ein einfaches Unterfangen für einen guten Entwickler bei Repräsentation dieser Artikelnummer auf Katalogen oder im Web die führenden Nullen abzufragen und zu unterbinden.
Das schaffe sogar ich mit ein bißchen Lektüre von www.navision24.de obwohl ich kein NAV-Entwickler bin.