Zur Homepage www.HI-Tier.de WF.Aposteriori
Zurück Home Nach oben
Öffentlicher Bereich für Entwickler

 

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

bulletDatenerfassung und Scannen an der RS, Datensätze gelangen in die lokalen Tabellen der RS (STAT=-1 "Satz noch nicht übertragen").
bulletDateneingang per IVR, Internet usw. an der ZDB, Datensätze gelangen in die zentrale Tabelle der ZDB.
bulletDatentransfer zwischen RS und ZDB
  1. Upload Datensätze
    1. 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
    2. neue Stornos (STAT=204)
    3. neue Bestätigungen (STAT=205)
  2. Download Datensätze
    1. 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
    2. Update vorhandene Sätze, STAT=999
  3. Download Vorgänge
    1. 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 ??...
    2. Update vorhandene Sätze, i.d.R. SYS_BIS d.h. STORNO
bulletSetze STAT der lokalen Datensätze in Abhängigkeit von Transfer-Ergebnis
  1. Sätze mit maximaler Schwere 0 enthalten STAT=0
  2. Sätze mit maximaler Schwere 1 enthalten STAT=1
  3. Sätze mit maximaler Schwere 2 enthalten STAT=1 (behandle wie Hinweis)
bulletSetze STAT der lokalen Datensätze in Abhängigkeit von VORGANG
  1. neue Fehlervorgänge aus der Zentrale setzen den Status auf STAT=200
  2. Storno von Fehlervorgängen setzen den Status auf STAT=999
    (?? können zu einem Datensatz gleichzeitig mehrere Vorgänge laufen ?? )
bulletFehlerbearbeitung
Fehler-Vorgänge werden an der RS teils automatisch, teils manuell bearbeitet und durchlaufen mehrere Zustände
  1. für lokale Fehler-Vorgänge mit STAT=100-199
  2. von der Zentrale ausgelöste Vorgänge mit STAT=200-299

(noch zu überarbeiten) ???

  1. 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
  2. Alle Sätze _STATUS = 0 (in Anhörung)

Entstehen und Auflösen von Fehlervorgängen

bulletFehlervorgänge entstehen in der ZDB
  1. Durch Bestätigung eines Fehlers der Schwere 3 durch einen interaktiven Benutzer
  2. durch Senden eines Fehlers der Schwere 3 mit /S (Force) beim Batchtransfer
  3. durch regelmäßig ablaufende Batchprogramme zur Fehler- und Vollständigkeitsprüfung
bulletFehlervorgänge lösen sich auf
  1. 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.
  2. Alle beteiligten Datensätze inzwischen mit FORCE bestätigt wurden ??

 

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

_STATUS Zustand Nächste Aktion Nächster Zustand
-1 noch unbearbeitet Anschreiben erzeugen 0
0 in Anhörung prüfe Fristüberschreitung 0 oder 1
1 1.Mahnung prüfe Fristüberschreitung 1 oder 2
2 2.Mahnung manuelle Bearbeitung  
    Satz mit Korrektur kommt 3
3 zu korrigieren    
    Satz mit Bestätigung kommt 4
4 sende Force=stark    

Exemplarischer Datenfluss im Zeitablauf

Meldungen bis 04.01.1999

Lokale Tabelle ABGANG

_COUNTER

_STATUS

_STATDAT

Ohrmarke

Betriebsnummer lang

Abgangsdatum

Meldeweg

1

-1

15.02.1999

276000900000001

276091234560001

01.01.1999

1

2

-1

15.02.1999

276000900000002

276091234560001

02.01.1999

1

3

-1

15.02.1999

276000900000003

276091234560001

03.01.1999

1

4

-1

15.02.1999

276000900000004

276091234560001

03.01.1999

1

5

-1

15.02.1999

276000900000005

276091234560001

03.01.1999

1

Lokale Tabelle GEBURT

_COUNTER

_STATUS

Ohrmarke

Betriebsnummer

Geburtsdatum

Meldeweg

LOM Mutter

...

1

3

276000912345678

276091234567890

01.01.1999

1

276000911111111

...

2

3

276000912345679

276091234567890

02.01.1999

1

276000922222222

...

Zentrale Tabelle ABGANG

LOM

BNR15

ABGA_DAT

SYS_VON

SYS_BIS

SYS_STAT

MELD_WG

276000944440001

276091234560001

01.01.1999

03.01.99 22:00:00

31.12.2100

-1

2

276000944440002

276091234560001

02.01.1999

03.01.99 22:04:00

31.12.2100

-1

2

276000944440003

276091234560001

03.01.1999

03.01.99 22:06:00

31.12.2100

-1

2

276000944440004

276091234560001

02.01.1999

03.01.99 23:00:00

31.12.2100

-1

2

Zentrale Tabelle RETRIEVE

lokale Tabelle VORGANG

V-Nr

V-Lfn

PlausiNr

Schwere

Meldung

Ohrmarke

Betriebsnummer

Datum

Timestamp

_STATUS

10000213

0

201

3

GEBURT

276000912345678

276091234567890

15.11.1998

01.01.1990

-1

10000245

1

440

2.5

GEBURT

276000911111111

276091234567890

01.01.1999

01.01.1990

-1

10000245

2

440

2.5

GEBURT

276000922222222

276091234599999

01.01.1999

01.01.1990

-1

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

Klicken für Großdarstellung

Zentral begründete Vorgänge

Klicken für Großdarstellung

Zurück zum Anfang


© 1999-2015 Bay.StMELF, verantwortlich für die Durchführung sind die Stellen der Länder , fachliche Leitung ZDB: Frau Dr. Kaja.Kokott@hi-tier.de, Technik: Helmut.Hartmann@hi-tier.de
Seite zuletzt bearbeitet: 01. Februar 2016 18:49, Anbieterinformation siehe hier im Impressum.