Allgemeines

Es handelt sich hier nur um einen Vorschlag für einen mögliche lokale Status-Behandlung bei einer RS insbesondere bei der Bearbeitung der Fehlervorgänge aus der Aposteriori-Prüfung.

Der Datenbestand und Datenfluss zwischen RS und ZDB wird exemplarisch am Beispiel der Abgangsmeldungen dargestellt. Er gilt analog für die anderen Bewegungs-Meldungen. Die Fehlernummern sind nur als Beispiel zu sehen.

Ein Zustands/Ereignis-Diagramm zur Darstellung der Fehlernachverfolgung siehe Visio-Diagramm F0  in Datenfluss.vsd.

Vorgangs-Tabelle

Allgemein

Die Tabelle VORGANG nimmt eine zentrale Stelle bei der Fehlerbearbeitung und Nachverfolgung ein. Diese Tabelle existiert mit geringfügigen Unterschieden lokal bei der RS und zentral in der HIT-ZDB.

In dieser Tabelle werden lokal alle Hinweise und Fehlermeldungen eingestellt, die beim Übertragen der lokal erfassten Datensätze zur ZDB als Antwort im HIT-Protokoll zurückgemeldet wurden.

In die zentrale Vorgangstabelle werden alle Fehlermeldungen der aposteriori Prüfungen eingestellt. Die einzelnen RS holen alle Vorgangssätze für ihren Betriebsnummernbereich regelmäßig ab und stellen sie zur Nachverfolgung in ihre lokale Vorgangstabelle ein.

Bereits bestehende Vorgänge in der ZDB, die sich durch Korrektur oder Bestätigung der zugrunde liegenden Datensätze erübrigt haben, werden in der zentralen Vorgangstabelle speziell gekennzeichnet. Beim nächsten Download der Vorgänge kann somit eine RS erkennen wenn eine weitere Verfolgung eines Vorgangs nicht mehr nötig ist.

Plausi-Typen

Bei den Plausi-Typen (TYP: 1=Syntax, 2=semantisch ...) wurde der Typ 5=aposteriori noch genauer spezifiziert in 6=Kollision, 7=unvollständig, 8=überzählig.

Beipiel für Kollision

Das Geburtsdatum von zwei Kälbern mit der selben Mutter-LOM liegt 30 Tage auseinander. Zwischenkalbezeit ist nicht plausibel. Die beide Sätze GEBURT stehen in Kollision.

Beipiel für Unvollständig

Bei Unvollständigkeit gibt es zwei Auspägungen.

Unvollständig mit bekanntem Partner

Ein Betrieb meldet einen Zugang oder ein Schlachthof meldet eine Schlachtung. Nach Ablauf der maximalen Meldefrist liegt keine Abgangsmeldung vor. Der Vorbesitzer ist aber i.d.R. in der Datenbank über Geburts- , Import- oder Zugangsmeldung bekannt.

Unvollständig mit unbekanntem Partner

Ein Betrieb meldet einen Abgang. Nach Ablauf der maximalen Meldefrist liegt weder Zugang- noch Schlachtmeldung vor. Der Nachbesitzer ist zunächst nicht ermittelbar.

Beipiel für Überzählig

Zu einer Abgangsmeldung liegen mehr als eine Zugang- oder Schlachtmeldung mit identischem Meldedatum vor

Tabellen-Aufbau

zentrale Vorgangstabelle

lokale Vorgangstabelle

Wiederkehrende Arbeitsschritte

	Datenerfassung und Scannen an der RS, Datensätze gelangen in die lokalen Tabellen der RS (STAT=-1 "Satz noch nicht übertragen").
	Dateneingang per IVR, Internet usw. an der ZDB, Datensätze gelangen in die zentrale Tabelle der ZDB.
	Datentransfer zwischen RS und ZDB Upload Datensätze neue Sätze (STAT=-1) sendet alle Sätz mit _STATUS = -1 und speichert Ergebnis für Schwere 1 , 2 , 3 in Tabelle lokalen VORGANG unter einer lokalen Vorgangsnummer. Sätze mit Schwere 3 werden nicht in der ZDB gespeichert, die anderen Sätze schon neue Stornos (STAT=204) neue Bestätigungen (STAT=205) Download Datensätze RS holt alle neuen Datensätze GEBURT, ABGANG, ZUGANG ,,, mit "*n:RS/D:GEBURT/*:BNR15;BETWEEN;27609...0;AND;2760...9" .... Insert neue Sätze mit STAT=0 Update vorhandene Sätze, STAT=999 Download Vorgänge RS holt alle neuen Fehler-Vorgänge für die RS "*n:RS/D:VORGANG/*:BNR15;BETWEEN;276090000;AND;2760999" Insert neue Sätze, update bestehende Vorgänge ??... Update vorhandene Sätze, i.d.R. SYS_BIS d.h. STORNO
	Setze STAT der lokalen Datensätze in Abhängigkeit von Transfer-Ergebnis Sätze mit maximaler Schwere 0 enthalten STAT=0 Sätze mit maximaler Schwere 1 enthalten STAT=1 Sätze mit maximaler Schwere 2 enthalten STAT=1 (behandle wie Hinweis)
	Setze STAT der lokalen Datensätze in Abhängigkeit von VORGANG neue Fehlervorgänge aus der Zentrale setzen den Status auf STAT=200 Storno von Fehlervorgängen setzen den Status auf STAT=999 (?? können zu einem Datensatz gleichzeitig mehrere Vorgänge laufen ?? )
	Fehlerbearbeitung Fehler-Vorgänge werden an der RS teils automatisch, teils manuell bearbeitet und durchlaufen mehrere Zustände für lokale Fehler-Vorgänge mit STAT=100-199 von der Zentrale ausgelöste Vorgänge mit STAT=200-299 (noch zu überarbeiten) ??? Noch unbearbeitete Sätze _STATUS = -1 werden als Serienbrief an den Landwirt gesendet, Status wird gesetzt _STATUS=0. Wenn Schwere 1 oder 2 , d.h. nur Mitteilungen an den Landwirt, so kann ggf. gewartet werden bis eine Fehlerbrief mit höherer Schwere anfällt Alle Sätze _STATUS = 0 (in Anhörung)

Entstehen und Auflösen von Fehlervorgängen

	Fehlervorgänge entstehen in der ZDB Durch Bestätigung eines Fehlers der Schwere 3 durch einen interaktiven Benutzer durch Senden eines Fehlers der Schwere 3 mit /S (Force) beim Batchtransfer durch regelmäßig ablaufende Batchprogramme zur Fehler- und Vollständigkeitsprüfung
	Fehlervorgänge lösen sich auf alle bestehenden Fehler-Vorgänge werden überprüft und wenn die Daten der zugrunde liegenden Sätze geändert, d.h. gelöscht und neu eingefügt sind wird der Vorgang überprüft und ggf. storniert. Alle beteiligten Datensätze inzwischen mit FORCE bestätigt wurden ??

Status für Fehler-Vorgänge (noch zu überarbeiten) ????

Exemplarischer Datenfluss im Zeitablauf

Meldungen bis 04.01.1999

Lokale Tabelle ABGANG

Lokale Tabelle GEBURT

Zentrale Tabelle ABGANG

Zentrale Tabelle RETRIEVE

lokale Tabelle VORGANG

Zentrale Tabelle VORGANG

Übertragen in der Nacht vom 04.01.1999

1.Satz ohne Fehler

*1:XS:ABGANG/LOM;BNR15;ABGA_DAT;MELD_WG:27600..1;27609..1;01.01.99;1
=1:0/0::        

Der Status des Satzes wird auf 0 gesetzt, die Daten sind in der ZDB gespeichert.

2.Satz mit Hinweisen

*2:XS::276000900000002;276091234560001;02.01.1999;1
%2/1:1/1010:ABGANG/BNR15:Hinweis...
=2/2:1/1087:ABGANG/*:Hinweis...        

Der Status des Satzes wird auf 1 gesetzt, die Daten sind in der ZDB gespeichert.

Die Hinweise werden in der lokalen Tabelle VORGANG gespeichert, um sie bei Gelegenheit an den Datenmelder weiterzuleiten.

3.Satz mit Nachfrage und Bestätigung

*3:XS::276000900000003;276091234560001;03.01.1999;1
%3/1:1/1099:ABGANG/BNR15:Hinweis...
=3/2:2/2087:ABGANG/*:Sind Sie sicher...        

*4:XS/S
=4:0/0::        

Die Antwortschwere ist zunächst 2 und damit nicht angenommen. Durch erneutes (verkürtzes) Senden mit /S (Sicher/Force) wird die Antwortschwere 0.

Lokal wird der Status des Satzes wird auf 1 gesetzt, die Daten sind in der ZDB gespeichert.

Die Nachfragen werden wie die Hinweise in der lokalen Tabelle VORGANG gespeichert, um sie bei Gelegenheit an den Datenmelder weiterzuleiten.

4.Satz mit "nicht akzeptierbarem Fehler", Datenablehnung

*7:XS::276000900000004;276091234560001;03.01.1999;1
=7:4/3077:ABGANG/*:Fehler, Datensatz wird nicht angenommen...        

Der Status des Satzes wird auf 3 gesetzt, die Daten sind nicht in der ZDB gespeichert.

Die Fehlermeldung wird in der lokalen Tabelle VORGANG unter einer lokalen Vorgangsnummer gespeichert werden, um sie in einem eigenen Workflow zu bearbeiten.

Zustands-Ereignis Diagramme für Nachverfolgung an den RS

Lokal begründete Vorgänge

Zentral begründete Vorgänge

Zurück zum Anfang