Die TIM-Webseite

paclogo.gif

against software patents!

Viewable With Any Browser

Ereignisse verwalten

Das Modul Event-Manager ermöglicht es, von den Stammdaten eines Partners aus «Ereignisse» zu verwalten. Mit «Ereignisse» meinen wir hier alle Formen von Anträgen und Bescheinigungen. Die genaue Liste der möglichen Ereignisse wird vom Systemverwalter konfiguriert.

Übersicht

Die Bezeichnung «Ereignis» ist eigentlich irreführend. Besser wäre «Formulare». Wer will, ersetze also im Folgenden das Wort «Ereignis» durch «Formular».

Ereignisse sind formalisierte Dokumente,

  • die keine buchhalterische Auswirkung haben,
  • die an einem bestimmten Tag von einem bestimmten Mitarbeiter für einen bestimmten Partner ausgestellt wurden.
  • die sowohl für internen als auch externen Gebrauch erstellt werden können

Je nach Kategorie und Ereignis-Art muss der Benutzer weitere Angaben machen. Zum Beispiel wenn jemand einen «Antrag zur Rückerstattung eines entzogenen Führerscheines» stellt, dann muss er angeben, wann und warum ihm der Führeschein entzogen wurde.

TIM kann vor allem auch automatische Folgeereignisse erzeugen. Zum Beispiel wenn ein «Antrag auf Beihilfe» gestellt wurde, dann muss 3 Tage vor der nächsten Verwaltungsratssitzung ein entsprechender «Vorschlag zur Beihilfegewährung» ausgedruckt werden.

Ereignisse erfassen

Auf einem Partner kann man mit [F8] die Ereignisse für diesen Partner einsehen: 

Datum    User     Betreff                                  Art Dok.
────────┬────────┬────────────────────────────────────────┬───┬──────
14.12.02│LUC     │Antrag auf Beihilfe                     │BEI│ANTRAG
17.12.02│AUTO    │Vorschlag zur Beihilfegewährung         │BEI│VORSCH

Hier kann man jetzt auch mit [Insert] manuell neue Ereignisse einfügen. 

╔══════════════ Ereignis erstellen ══════════════╗
║ Datum 14.12.02                                 ║
║ Kategorie↓                                     ║
║ Ereignisart ↓                                  ║
╚════════════════════════════════════════════════╝

Drücken Sie [F1] im Feld Kategorie, um eine Ereigniskategorie auszuwählen. 

╔══════════════ Ereigniskategorie ═════════════╗
║ BEI Beihilfen                                ║
║ ETC Sonstige                                 ║
║ MIN Existenzminimum                          ║
╚══════════════════════════════════════════════╝

Wenn Sie eine Kategorie ausgewählt haben, drücken Sie [F1] im Feld Ereignisart, um die genaue Art des Ereignisses auszuwählen. 

Name   Bezeichnung
──────┬─────────────────
ABLEHN│Ablehnung
ANTRAG│Antrag
ATTE01│Bescheinigung 1
BESCHL│Beschluss
VORSCH│Vorschlag

Wenn Sie dieses Dialogfenster bestätigen, wird das Ereignis in der Datenbank angelegt und TIM zeigt den Eingabebildschirm, in dem Sie alle weiteren Angaben erfassen.

TODO : Beispiel

Merke :

  • Es gibt verschiedene Kategorien von Ereignissen, und innerhalb jeder Kategorie verschiedene Arten.
  • Innerhalb einer Kategorie sind üblicherweise alle Dokumente zusammengelegt, die sich in einer logischen Reihenfolge befinden.

Konfigurierung

Das Modul DEF_EVT (Event-Manager) definiert vor allem eine Tabelle EVI (Event Items), die die eigentlichen Ereignisse speichert.

Jedes Ereignis hat ein Datum, ist einem Partner zugewiesen, sowie einem verantwortlichen Mitarbeiter (dem Benutzer, der es erstellt hat). Außerdem die Ereigniskategorie (EVI->IdEvt) sowie die vom Benutzer gewählte Druckmaske ("Ereignisart", EVI->IdTpl). Die «Ereignisarten» sind also in Wirklichkeit Druckmasken.

Weitere datenbankspezifische Felder für Ereignisse sind in der Datei EVI.DEF definiert: 

ddAddField("AntDat","D",8,0,"","V",{|x|KeyGetSet(x,...
ddAddField("Grund","C",70,0,"","V",{|x|KeyGetSet(x,...
ddAddField("Text1","M",30,3,"","V",{|x|KeyGetSet(x,...

Die Funktion KeyGetSet(), die hier (momentan) benutzt wird, simuliert eine Art Objektdatenbank. Die Felder AntDat, Grund und Text1 sind virtuelle Felder und werden in einer XML-ähnlichen Syntax im (nur für diesen Zweck benutzten) Feld EVI->Memo gespeichert.

TODO: KeyGetSet() ist kaum getestet und möglichweise nicht zuverlässig. Aber zum Anlegen von Tests und zur Konfiguration müsste sie reichen. Nur bloß noch keine Produktionsdaten eingeben.

Vielleicht ist auch die ganze Idee, über KeyGetSet() zu arbeiten, Quatsch. Wieso nicht einfach normale Datenbankfelder anlegen? Vorteile: (1) man kann neue Felder definieren, ohne die Datenbank zu konvertieren. (2) Man kann viele verschiedene Felder anlegen, ohne dass dadurch physikalischer Platz verschwendet wird.

Kategorien und Masken

Die Ereigniskategorien sind in der Tabelle EVT (Event Types) gespeichert und werden über Stammdaten|Ereigniskategorien vom Verwalter konfiguriert. 

ID  Bezeichnung                              Art Maske
───┬────────────────────────────────────────┬───┬──────
BEI│Beihilfen                               │EVT│
ETC│Sonstige                                │EVT│
MIN│Existenzminimum                         │EVT│ANTRAG

Die Druckmaske (also die Ereignisart) kann (innerhalb einer Druckmaskenart, EVT->IdTpt) vom Benutzer gewählt werden.

Beispiel : Innerhalb der Kategorie MIN kann es die Druckmasken "Antrag", "Vorschlag", "Beschluss", "Bescheinigung"... geben.

Die Druckmaskenart (EVT->IdTpt) (also die Menge von Druckmasken, aus der der Benutzer auswählen darf) legt der Verwalter pro Ereigniskategorie fest.

Man könnte also auch mehrere Ereigniskategorien erstellen, die die gleiche Druckmaskenart haben. Wer weiß, wozu das interessant sein kann.

Je nach Kategorie variiert die Bildschirmmaske (Vollbild-Ansicht) für Ereignisse dieser Kategorie.

Für jede Ereigniskategorie müssen also eigene Bildschirmmasken definiert werden. Wenn der Benutzer ein Ereignis erstellt, muss er ja obligatorisch Kategorie (IdEvt) und Ereignisart (IdTpl) angeben. TIM lädt erst dann für die Vollbildansicht die entsprechende Bildschirmmaske.

TODO: Bildschirmmaske pro Kategorie? Oder pro Ereignisart?

Bisher existieren drei Bildschirmmasken: EVIEXANT.MSK, EVIEXATT.MSK und EVIEXVOR.MSK

TODO: Neues Feld EVT->IdMsk enthält die Bildschirmmaske.

Folgeereignisse

Die Funktion EvlApply() (Menübefehl: TODO) wird im Prinzip einmal pro Tag laufen gelassen. Sie durchläuft alle Ereignisse und erzeugt eventuelle Folge-Ereignisse, entsprechend den vom Verwalter definierten Regeln.

In der Tabelle EVL (Event Links, oder besser Folgeanweisungen) können die Regeln zur Erzeugung von automatischen Folge-Ereignissen definiert werden.

Dabei kann frei definiert werden,

  • unter welcher Bedingung das Folgeereignis ausgelöst wird.
  • Was sich in dem neuen Dokument im Gegensatz zu seinem Vorgänger ändert. Ein Folgeereignis ist zunächst lediglich eine Kopie des auslösenden Ereignisses. Aber pro EVL definiert man mit [F12], was in dem neu erstellten Ereignis automatisch verändert wird.

TODO: dieser Teil muss noch fertig implementiert werden.