Im Kontext einer Ereignisbehandlung wird die voraussichtlichen Ankunftszeit ("ETA") einer Sendung als "Datum mit Zeit" berechnet.

Da die eintreffende Ware nur bei Eingang an einem Werktag als sofort (bzw. an demselben Kalendertag) verfügbar gilt, soll das berechnete "ETA"-Datum noch mit einem bestehenden Kalender abgeglichen werden, um ein weiteres Datum ("AVAIL") für die effektive Verfügbarkeit der Ware beim Empfänger zur ermitteln.

Der Benutzer soll durch eine Hinweis anzeigen (Popup)-Ereignisaktion über die Kalendertage für "ETA" und "AVAIL" informiert werden.

Laufzeitbeispiel:

• Beim Eintreffen der Sendung am Samstag, den 1. Oktober (2022) gilt die gelieferte Ware erst per Dienstag, den 4. Oktober als verfügbar, da der für die Prüfung verwendete Kalender nicht nur das Wochenende (Samstag/Sonntag) sondern auch einen Feiertag am 3. Oktober berücksichtigt.

Konfiguration:

Für die Konfiguration rechts gilt das bereits berechnete "ETA"-Datum (als "Datum mit Zeit") als Bezugsobjekt innerhalb einer Ausführen mit-Ereignisaktion (nicht im Bild).

• Das "ETA"-Datum muss im Titel der abgebildeten Hinweis anzeigen (Popup)-Ereignisaktion im Kontext einer Textverkettung nur noch mit einer Beschriftung versehen und formatiert werden (s. Datum formatieren).
  
  

• Auch die Meldung verwendet eine Textverkettung zum Beschriften des Datumswerts, der über den Kalenderfilter-Wertauflöser berechnet und anschließend per Verkettung formatiert wird (s. Datum formatieren).
  
  

• Der Kalenderfilter-Wertauflöser greift Statisch auf einen Kalender "24-5 (MON-FRI)" zu, in dem ggf. durch "Vorwärts springen" nach Werktagen gesucht werden soll.

►ANMERKUNG◄ Das Verfügbarkeitsdatum wird hier nur als Kalendertag ohne Uhrzeitkomponenten angezeigt und auch sonst nicht verarbeitet oder gespeichert. Insofern spielt es keine Rolle, dass eine im berechneten "ETA"-Datum enthaltene Uhrzeit ggf. an das "AVAIL"-Datum übergeht. Das folgende Beispiel beschäftigt sich mit diesem Problem.

Im Kontext einer Ereignisbehandlung soll für eine konkrete Bestellung ermittelt werden, bis zu welchem Termin im laufenden Monat über den für die Bestellung bereits ausgewählten Spediteur noch Teilladungen beauftragt werden können. Je Spediteur sei deshalb für die Terminkoordination ein Kalender mit dem einheitlichen Namen "LTL" angelegt, der wiederkehrende und diskret festgelegte Terminoptionen für die Abwicklung von Teilladungen als "Werktage" abbildet.

Konfiguration:

Die Ereignisbehandlung muss im Kontext der betreffenden Bestellung zunächst den zum ausgewählten Spediteur passenden Kalender ermitteln. Dies ermöglicht eine Suche (Ereignisaktion), die innerhalb einer Ausführen als-Ereignisaktion ausgeführt wird, damit der Lesezugriff für die im Besitz der diversen Spediteure angelegten Kalender gewährleistet ist. Die Suche (Ereignisaktion) soll hier nicht ausführlich beschrieben werden. Sie soll als Tupel-Suche den ersten (und konventionsgemäß: einzigen) Kalender im Besitz eines bestimmten Spediteurs finden, dessen Name "LTL" lautet. Als Projektion wird für den Kalenderfilter nur das Feld id benötigt. Das Ergebnis der Tupel-Suche wird in die Variable LTL@FWD geschrieben.

• Auf der rechten Seite der Setze Wert-Ereignisaktion wird zunächst über den Relatives Datum mit Zeit-Wertauflöser das "Ende des Monats" (END_THIS_MONTH) ermittelt. Dieses "Datum mit Zeit" wird per Verkettung als Eingabewert an einen Kalenderfilter-Wertauflöser übergeben.
  
  

• Im Kalenderfilter-Wertauflöser wird für die "Werktag-Prüfung" auf den für den relevanten Spediteur ermittelten Kalender verweisen, indem dem Parameter Kalender das Objekt-Feld id aus dem Suchergebnis in der Variablen LTL@FWD zugewiesen wird.
  
  

• Die Option Rückwarts springen sorgt dafür, dass der Variablen LTL_ultimate (auf der linken Seite der Setze Wert-Ereignisaktion) der späteste im Kalender des Spediteurs als Werktag definierte Kalendertag zurückgegeben wird, der vor dem Ende des aktuellen Monats liegt.

►ANMERKUNG◄ Der Fall, dass der LTL_ultimate-Termin zum Zeitpunkt der Anfrage bereits in der Vergangenheit liegt, wird hier nicht gesondert behandelt.

Laufzeitbeispiel:

Ein Spediteur bietet Transporte für Teilladungen laut seinem "LTL"-Kalender grundsätzlich nur Donnerstags an. Eine Abfrage für den LTL_ultimate-Termin im August 2022 ergibt den rechts dargestellten Wert, der auf den Kalendertag "Donnerstag, 25 August 2022" verweist.

►ANMERKUNG◄ Der Millisekunden-Wert im Feld dateValue in der Darstellung rechts zeigt, dass sich die Uhrzeit (23:59:59.999) aus dem Eingangswert ("Ende des Monats") auch im Rückgabewert des Kalenderfilters spiegelt.

Ausgehend von einem - hier als "Datum mit Zeit"-Wert in der Variablen start - vorgegebenen Datum soll im Abgleich mit einem bestimmten Kalender ein Zieldatum (end) ermittelt werden, das eine bestimmte Anzahl von Werktagen (offset) nach dem start liegt.

Konfiguration:

Innerhalb einer Ereignisaktion iteriert die rechts abgebildete Für jeden Eintrag wiederholen (Schleife) über die Variable offset, die die Anzahl der Werktage ab start als Ganzzahl definiert:

• Die Setze Wert-Ereignisaktion innerhalb der Schleife soll bei jeder Iteration der Variablen end den "nächsten" Werktag zuweisen.
  
  

• Die ermöglichst (rechts im Bild) eine Verkettung der folgenden Wertauflöser:
  
  

  • Als Ausgangswert für die Verkettung soll je Iteration der bisherige Wert der Variablen end dienen.
    
    

  • In der ersten Iteration enthält end (hoffentlich!) noch keinen Wert. Dann weist der verkettete Standardwert-Wertauflöser den eigentlichen Startwert aus der Variablen start zu.
    
    

  • Der nachfolgende Relatives Datum mit Zeit-Wertauflöser addiert mit dem Typ "Benutzerdefiniert" und dem Zeitwert +1d genau einen Kalendertag zum Eingabewert.
    
    

  • Der verkettete Kalenderfilter-Wertauflöser prüft, ob der als Eingabewert anliegende Kalendertag im Statisch ausgewählten Kalender "24-5 (MON_FRI)" ein Werktag ist.

    • Trifft dies zu, wir dieser Wert zurückgegeben.

    • Anderenfalls wird durch "Vorwärts springen" der nächste Werktag im Kalender ermittelt und zurückgegeben.

Am Ende sollten zwischen start und end genau so viele Werktage (nach dem ausgewählten Kalender) Differenz liegen, wie in der Variable offset angegeben wurde.

►ANMERKUNG◄ Die hier gezeigte Konfiguration setzt voraus, dass der Wert der Variablen offset>0 ist und die Variable end zu Beginn noch keinen Wert ($null) enthält.