[gelöst] FlowField Value Change Event?

Hallo Kollegen,

Kurze Frage: Wenn ich ein FlowField (A) habe, gibt es einen Event den ich catchen kann, wenn ein Wert sich ändert?

Falls nein habe ich vielleicht ein konzeptionelles Problem: Ich möchte den Wert eines anderen Feldes (B, kein FlowField) anpassen auf Basis des Wertes des FlowFields (A) und jeweils eines anderen statischen Feldes (C). Ist ne simple Datumskalkulation (B=A+C und noch ein bisschen wenn/dann logik).

Zurzeit habe ich auf der Tabelle für den Event "OnValidate" des Feldes A (FlowField) und des Feldes C (statisch) die Berechnung (des Feldes B) hinterlegt. Leider wird dieser Event aber nur dann getriggert, wenn der User manuell den Wert des Feldes C ändert. Ich hatte mir erhofft, dass wenn immer der Wert des FlowFields ändert auch die Berechnung durchgeführt wird.

Wo hab ich hier den Ueberlegungsfehler?

DANKE VIELMALS!!!

Zuletzt geändert von Izzy am 26. März 2013 15:55, insgesamt 3-mal geändert.

FlowFields sind in dem Sinne keine Felder. Welche Art FlowField ist es denn? Ggf. kannst du ja in der Herkunftstabelle was machen?

Kurze Frage: Wenn ich ein FlowField (A) habe, gibt es einen Event den ich catchen kann, wenn ein Wert sich ändert?

Leider nicht.

Warum sollte sich das FlowField eigentlich zur Laufzeit der Form, die es anzeigt, ändern? Ist diese Form den ganzen Tag auf einem Client für einen Datensatz geöffnet?

Der Wert des Flowfields ändert sich durch ändern der Tabellenwerte auf die dieses Flowfield verweist.

Beispiel:
In der Tabelle Item gibt es ein Flowfield Lagerbestand. Dieses zeigt auf Tabelle Item Ledger Entry. Wenn in die Tabelle Item Ledger Entry etwas eingefügt wird, dann ändert sich der Lagerbestand.

Das Einfachste wäre also, beim Einfügen oder Ändern der Tabelle auf die dieses Flowfield zeigt, musst du dein Feld B aktualisieren.

Hallo zusammen und vielen Dank für Euren Support.

Ich glaube so langsam wird mir das Problem klar.

Mein FlowField ist Type Date, es liest aus Sales Invoice Lines das letzte (aktuellste) Datum an dem ein bestimmer Artikel (es handelt sich um eine Service-Dienstleistung) verkauft wurde. Meine Tabelle soll dann für jeden unserer Kunden zeigen, wann der nächste Service fällig wäre. Das mache ich mit einem normalen Feld, welches sich auf das FlowField desselben Records bezieht und z.b. 1J dazuaddiert.

Das Problem ist nun: Dieses Feld merkt gar nicht dass sich der Wert des FlowFields nach einer Verbuchung dieses Artikels geändert hat und aktualisiert sich deshalb nicht. Ich kann das Feld nur aktualisieren wenn der User beim Record was aktualisiert, z.b. kurz 1J auf 2J (und wieder zurück) ändert. Dann wird die Berechnung neu durchgeführt.

Wenn ich das richtig verstanden habe gibts leider kein Trigger, welcher während dem Laden des Forms (der Berechnung der FlowFields) ausgelöst wird, bei dem ich für alle Records automatisch die Neuberechnung ausühren kann. Schade.

D.h. es bleibt mir wohl nichts anderes übrig als was m_schneider geschrieben hat, bereits beim Verbuchen dieses Artikels eine Neuberechnung durchführen. Irgendwie doof, aber gehts so sicher.

Auf der anderen Seite müsste es doch möglich sein beim Öffnen des Forms mein statisches Feld (also nicht das FlowField selber) über einen Trigger neuzuberechnen für alle Records. Dann öffnet das Form vielleicht nicht super schnell, aber das wäre mir egal. Gibt es eine Möglichkeit beim Laden der Tabellendaten in ein Form bei jedem geladenen Record eine manuelle Berechnung für ein Feld des Records durchzuführen?

Danke euch allen!

Also normalerweise bleibt die Form ja nicht offen. D.h., aus meiner Sicht sollte eine (Neu-)Kalkulation beim Öffnen der Form bzw. Wechseln des Datensatzes ausreichen. Wird dann im Hintergrund der Artikel erneut verwendet und verbucht, so daß sich eigentlich deine Kalkulation aktualisieren müßte, muß der User halt in den "sauren Apfel" beißen und die Form neu öffnen bzw. den Datensatz einmal wechseln.

Aber mal was anderes... Nach meinem Verständnis darf sich doch das Datum des nächsten Service nicht unbedingt ändern, wenn die Dienstleistung neu in Anspruch genommen wurde. Das hängt doch davon ab, was da gewartet wird und wieviele der Kunde davon hat.

Wenn ich das richtig verstanden habe gibts leider kein Trigger, welcher während dem Laden des Forms (der Berechnung der FlowFields) ausgelöst wird, bei dem ich für alle Records automatisch die Neuberechnung ausühren kann. Schade.

Das zwar nicht, aber es gibt einen Trigger, der beim Laden des aktuellen Datensatzes durchlaufen wird. Da kannst du dich doch einklinken.

Ja das ist korrekt. Mir würde es vollkommen genügen wenn beim Öffnen des Forms alle Reords durchlaufen und aktualisiert werden. Die FlowFields werden ja automatisch aktualisiert, nur meine vom FlowField-Wert abgeleitete Berechnung wird nicht getriggert.

Es wäre natürlich nicht besonders schön wenn immer nur der aktuelle Record (der selektierte/fokussierte Record) aktualisert wird, da ich auf meinem Form eine Liste von Records darstelle und dann bei allen anderen noch falsche Berechnungen gezeigt würden.

D.h. wenn ich beim Öffnen des Forms einen Event hätte, welcher mir erlaubt durch alle Records zu gehen, könnte ich die Berechnungnen ja aktualisiseren. Setzt natürich voraus, dass die FlowFields bereits berechnet sind wenn der Event getriggert wird.

Was wäre hier der richtige Event/Trigger?

DANKE!

ps: Nebenbei: Ist ja doof, FlowFields sind ja supercool, aber warum kann ich nicht für ein FlowField einfach selber Code hinterlegen, auf dessen Basis der Wert des FlowFields berechnet wird? FlowFields scheinen stark eingeschränkt und basieren glaub ich immer auf den Werte in anderen Tabellen. Wäre doch so nützlich ich könnte meinem FlowField einfach sagen "Dein Wert" = A+B;
pps: HattrickHorst: Bei uns ist das so, dass wenn der Service durchgeführt (verbucht) wurde soll dann eben in der Liste für diesen Kunden der nächste geplante Service erscheinen (aufgrund der Regel 1 Jahr später).

Der Trigger, der beim Anzeigen des aktuellen Records durchlaufen wird, ist der OnAfterGetCurrentRecord, in einer Übersicht wird für jeden Datensatz der OnAfterGetRecord durchlaufen. Da setzt du ein calcfields ab (falls nötig) und berechnest anhand dessen den Wert des anderen Feldes.

Ist ja doof, FlowFields sind ja supercool, aber warum kann ich nicht für ein FlowField einfach selber Code hinterlegen, auf dessen Basis der Wert des FlowFields berechnet wird? FlowFields scheinen stark eingeschränkt und basieren glaub ich immer auf den Werte in anderen Tabellen. Wäre doch so nützlich ich könnte meinem FlowField einfach sagen "Dein Wert" = A+B;

Schreib dir einfach eine Funktion in der Tabelle, die einen Wert nach deinen Wünschen berechnet und zurück gibt. Die Funktion kannst du wie ein Tabellenfeld als Source Expression eines Controls angeben. Man kann nur nicht darauf filtern oder danach sortieren.

Hi McLane,

Vielen vielen Dank, ich habe soeben etwas dazugelernt! Und sorry für die späte Antwort, ich war zu beschäftigt mit anderem. Werde dann wohl über den Trigger gehen weil ich gerne nach der Spalte sortieren möchte (sozusagen die ToDo-Liste nach Datum). Trotzdem wichtig zu wissen, dass ich auch eine CustomFunction an das Control anbinden könnte, hab ich als Anfänger nicht gewusst.

Euch allen vielen Dank!

Du willst nach einem Feld sortieren, das du während des Einlesens manipulierst? Hm, wenn das "gelöst" nicht mal voreilig war

es war voreilig... :(

:o)

Nerv... Damit kommt die Liste nicht klar... Gibt chaotische Resultate. Es bleibt mir wohl nichts anderes übrig als beim Schreiben der SalesInvoiceLine die Transaktionen abzufangen. Dann basiert der Ansatz einfach nicht mehr auf dem FlowField, was sehr schade ist. Das FlowField ist ideal um mir die letzte Transaktion dieses bestimmten Artikels zu bringen. DAnn will ich da nur eine variable Zeitperiode daraufzählen und dann nach dem Ergebnis sortiert eine Liste anzeigen. Klappt nicht :(

Also deine Anforderung finde ich nicht ganz verständlich bzw. vollständig.
Könntest Du das mal genauer erklären?
Ich glaube die Lösung ist viel einfacher als das was du da gerade ausprobierst.

Evtl. (sofern lizensiert) ist das "Service Item" das Mittel der Wahl.

Sali JanGD,

Gerne, hier die komplette Anforderung:

- In einer Tabelle (Liste) möchte ich eine Datumsspalte, die ich sortieren kann. Ziel: ToDo-Liste für den Mitarbeiter
- In die Datumsspalte soll der nächste geplante Service.
- Dieser soll sich berechnen, aus dem zuletzt ausgeführten Servicedatum sowie einer Frequenz. Diese ist pro Kunde in der Tabelle (=Record) unterschiedlich, aber meistens 1J
- Das richtige Servicemodul nutzen wir nicht. Service ist bei uns schlicht ein Artikel der verkauft wird. Nennen wir ihn SV (für Service)

Mein Ansatz bisher:

- Finde die FlowFields cool. Also hab ich ein FlowField aufgesetzt, welches mir aus der SalesInvoiceLine Tabelle für jeden Kunden (Record) das letzte Servicedatum holt.
- Dieses FlowField Datum wird auch problemlos berechnet und korrekt in meiner ToDo-Tabelle angezeigt. Leider kann ich aber nach einem FlowField nicht sortieren.
- Dazu kommt, ich möchte ja nicht nach dem letzten Datum sortieren, sondern nach dem nächsten, geplanten.
- Also wollte ich ürsprünglich über einen Trigger des FlowFields mein Zieldatum berechnen. Aber für FlowFields gibts keinen solchen Trigger, schade.
- D.h. ich hätte über OnAfterGetRecord der Tabelle on-the-fly die Zieldati berechnen können, aber auch diese neue Datumsspalte lässt sich nicht (fehlerfrei) sortieren, da eben erst zur Laufzeit berechnet.

Lösungsansätze:
- geht: Alles beim Schreiben eines neuen Records in die SalesInvoiceLine berechnen und speichern. Würde sicher gehen, ist aber nicht so elegant wie mittels FlowFields
- geht vielleicht?: Die Zieldati on-the-fly berechnen, wenn sich das Form öffnet aber noch nicht angezeigt (sortiert) wird?

Kommentar: Eigentlich völlig schade, dass man ein FlowField nicht sortieren kann. Da liebe ich mein VisualStudio :)

FlowFields sind in der Datenbank keine Felder in der Tabelle sondern werden über interne Begriffe in Indexed Views "gespeichert". (Native Indexed Views Unterstützung soweit ich weiß erst ab NAV5 SP1)
Soviel zur Technik.

Nun meine Fragen an der Anforderung:
- Soll der Wartungsintervall pro Artikel pro Kunde hinterlegt werden, oder nur einer pro Kunde von dem jüngsten, fälligen Service?
- Ist das Service-Intervall rollierend oder nur einmalig nach dem Verkauf des Gerätes?


Probier mal bitte ein "Run" auf die Tabellen 5940 und 5904. Habt ihr darauf Rechte?

Ja das mit den FlowFields scheint wohl so zu sein, sind dynamisch und nur zur Laufzeit existierende Felder. Trotzdem wäre es schon man könnte deren Wert für alle Records während einem 'Load' Event des Forms berechnen und sortieren und erst dann anzeigen. Wenn dann das Form angezeigt ist müssen diese auch nicht automatisch aktualisiert werden, es würde beim Laden des Forms genügen. Aber eben, das geht wohl nicht weil die Trigger OnAfterGetRecord nur Record bei Record während dem effektiven Anzeigen geladen werden und dann natürlich mit dem Sortierungswunsch kollidieren.

Zu Deinen Fragen:

- Ich hab nur ein Intervall pro Kunde, welches artikelunabhängig ist. Prinzipiell besteht auf der Tabelle 'Serviceverträge' (custom table) ein Feld mit der Frequenz (meistens 1J). Diese Frequenz zähle ich bei jedem Record zum aktuellen Wert des FlowFields (=letzter Service) dazu um meine Zielspalte ("Nächster fälliger Service") zu erhalten. Aber eben: wie FlowFields klappt das nicht.

- Ja habe auf beide Zugriffe, aber nur 5940 wird benutzt.

Ich bin bereits dabei die ganze Logik auf Stufe SalesInvoiceLines tabelle zu verschieben. Da prüfe ich ob eine neue Service-Transaktion durchgeführt wurde und aktualisere daraus meine Serviceverträge Tabelle, inklusive gleichzeitiger Berechnung des neues Servicedatums. Das klappt bestens. Insofern ist mein Problem gelöst.

Trotzdem finde ich es sehr schade kann man nicht mit FlowFields schaffen. Oder andersherum: Auch ein normales, unbound-field sollte zur Laufzeit beim Laden alle Daten eines Forms neu berechnet werden können und damit auch sortierbar sein. Aber das ist halt meine Welt mit SQL und .NET.

Ich danke Dir vielmals für Deine Hilfe und auch die der anderen User, aber ich denke es macht Sinn den Thread hier zu schliessen. Der Ansatz via FlowField war schlicht falsch von mir.

Danke!!

Ja das mit den FlowFields scheint wohl so zu sein, sind dynamisch und nur zur Laufzeit existierende Felder. Trotzdem wäre es schon man könnte deren Wert für alle Records während einem 'Load' Event des Forms berechnen und sortieren und erst dann anzeigen. Wenn dann das Form angezeigt ist müssen diese auch nicht automatisch aktualisiert werden, es würde beim Laden des Forms genügen. Aber eben, das geht wohl nicht weil die Trigger OnAfterGetRecord nur Record bei Record während dem effektiven Anzeigen geladen werden und dann natürlich mit dem Sortierungswunsch kollidieren.

Zu Deinen Fragen:

- Ich hab nur ein Intervall pro Kunde, welches artikelunabhängig ist. Prinzipiell besteht auf der Tabelle 'Serviceverträge' (custom table) ein Feld mit der Frequenz (meistens 1J). Diese Frequenz zähle ich bei jedem Record zum aktuellen Wert des FlowFields (=letzter Service) dazu um meine Zielspalte ("Nächster fälliger Service") zu erhalten. Aber eben: wie FlowFields klappt das nicht.

- Ja habe auf beide Zugriffe, aber nur 5940 wird benutzt.

Ich bin bereits dabei die ganze Logik auf Stufe SalesInvoiceLines tabelle zu verschieben. Da prüfe ich ob eine neue Service-Transaktion durchgeführt wurde und aktualisere daraus meine Serviceverträge Tabelle, inklusive gleichzeitiger Berechnung des neues Servicedatums. Das klappt bestens. Insofern ist mein Problem gelöst.

Trotzdem finde ich es sehr schade kann man nicht mit FlowFields schaffen. Oder andersherum: Auch ein normales, unbound-field sollte zur Laufzeit beim Laden alle Daten eines Forms neu berechnet werden können und damit auch sortierbar sein. Aber das ist halt meine Welt mit SQL und .NET.

Ich danke Dir vielmals für Deine Hilfe und auch die der anderen User, aber ich denke es macht Sinn den Thread hier zu schliessen. Der Ansatz via FlowField war schlicht falsch von mir.

Danke!!

Also wenn der Kunde etwas kauft bekommt er sein altes Service-Datum plus 1 Jahr gesetzt, egal was man ihm verkauft?
Hätte jetzt erwartet ab aktuellem Kaufdatum, weil ja sonst auch der Fall eintreten könnte: Kunde hat vor 2 Jahren gekauft, und vor einem Jahr hätte er den nächsten Service bekommen sollen Oder habt Ihr eine blaue Polizeibox/Zeitmaschine bei Euch stehen?

Wenn Ihr Service Item Groups benutzt, könnt ihr über gelieferte Aufträge euch direkt Service Items anlegen lassen, vollautomatisch.
Dort könnte ein neues Feld "Next Service" definiert werden, der den verkauften Artikel mit dem Serviceintervall addiert (Shipment Date + Intervall = Next Service)
Danach ließe sich dann sortieren. (Ist dann aber basierend auf verkauftem Artikel und nicht nur Kunde)

er kauft ja nicht etwas, sondern einen service :) und wenn er den gekauft (konsumiert) hat, dann wird eben der nächste service in einem jahr vorgeschlagen :)

habs jetzt implementiert auf der service invoice line tabelle basierend (hab nicht realisiert gehabt, dass services nicht unter der sales invoice line tabelle laufen).

klappt bestens, alles IO.

Nur schade wegen den FlowFields. leider wohl nicht in meinem kontext brauchbar.

besten dank Dir und allen nochmals!!! Hab wieder was dazugelernt.
Izzy