Mit der Funktion p424 - Datenqualitäts Job (dqmjob) kann eine Überprüfung der Datenqualität bestimmter Datenbanktabellen eingeleitet werden.Voraussetzung zur Nutzung dieses Moduls ist die Lizenz "dqc".
Die Funktion ist Job-fähig, und kann damit in die Nacht- oder Wochenendverarbeitung eingebettet werden.
Zu Beginn der Ausführung der Datenanalyse werden alte Analyseergebnisse gelöscht.
Daher ist es nicht möglich, das p424 mehrfach mit unterschiedlichen Vorgaben laufen zu lassen. Es findet also keine Kumulierung der Ergebnisse unterschiedlicher Programmläufe statt.
Über die Vorlaufdaten können die Datenprüfungen aktiviert und deaktiviert und der Umfang der Prüfungen festgelegt werden.
Kann aktiviert werden, um Metadatentabellen aus allen Prüfungen auszuschließen.
Ist die Anschriftenprüfung nicht deaktiviert, werden die in den Tabellen f010 Kundenstamm, f010lief Lieferantenstamm, f020 Kundenanschriften und f020 Lieferantenanschriften enthaltenen Anschriften, die sich auf Adressen in Deutschland beziehen, gegen die Orte- und Straßentabellen geprüft.
Ist die Auswahllistenprüfung nicht deaktiviert, werden die mit Auswahllisten verknüpften Datenfelder aller SOG ERP Tabellen gegen ihre Auswahllisten geprüft. Bei Metadatentabellen findet die Prüfung nur statt, wenn in der Definition des Datenfeldes der Schalter "Gegen Auswahlliste prüfen" gesetzt wurde.
Ist die Parameterprüfung nicht deaktiviert, werden alle Datensätze aller DVCS-basierenden Programme geprüft. Dabei werden alle nicht korrekt initialisierten Datensätze und ggf. alle fehlenden Zwangsfelder aufgezeigt, sofern eine entsprechende Prüfung in der DVCS-Funktion enthalten ist.
Ist die GTIN-Prüfung nicht deaktiviert, werden alle definierten GTIN auf syntaktische Korrektheit geprüft.
Keine referentielle Integrität
Ist diese Prüfung nicht deaktiviert, werden alle definierten Relationen dahingehend geprüft, ob Slave-Tabellen jeweils korrekt auf einen eindeutigen Datensatz einer Master-Tabelle zeigen. Die Prüfung kann für einzelnen Relationen in der Relationsdatei über den Eintrag IgnoreRelationCheck="true" deaktiviert werden.
Ist die SQL Prüfung nicht deaktiviert, werden alle SQL-Scripte in den Verzeichnissen ${PROJ}\sql\dqc, ${PROJ}\sql.indi\dqc und ${PROJ}\sql.${HHENVDOMAIN}\dqc abgearbeitet, und die Ergebnisse in der Tabelle dqinfo oder dqerror festgehalten. Siehe "Die SQL Prüfung" unten.
Ist die Key Konsistenz Prüfung nicht deaktiviert, werden in allen Tabellen die Inhalte der Datenfelder key_1 .. key_n dahingehend überprüft, dass sie mit den Inhalten ihren definierten Einzeldatenfelder übereinstimmen.
Ist die Firmennummern Prüfung nicht deaktiviert, werden in allen Tabellen die ein Datenbankfeld "firma" haben geprüft, ob der Inhalt mit der aktuellen Firmennummer übereinstimmt. Einige wenige Tabellen haben darüber hinaus noch Datensätze in Firma 0, oder einen Endedatensatz in Firma 99.
Über die Status ausschließen-Schalter können bestimmte Status von Kunden, Lieferanten und Artikeln von der Prüfung ausgeschlossen werden.
Hier kann für jeden möglichen Personenstatus eine p464 - Personenpflegevarianten (kontovar) (Kunden) angegeben werden.
Bei der Prüfung werden alle über die Pflegevariante festgelegten Zwangsfelder in den Tabellen f010 Kundenstamm, f020 Kundenanschriften, f012 Kundenansprechpartner, f016 Kundenselektionskennzeichen geprüft.
Hier kann für jeden möglichen Personenstatus eine p464 - Personenpflegevarianten (kontovar) (Lieferanten) angegeben werden.
Bei der Prüfung werden alle über die Pflegevariante festgelegten Zwangsfelder in den Tabellen f010 Lieferantenstamm, f020 Lieferantenanschriften, f012 Lieferantenansprechpartner, f016 Lieferantenselektionskennzeichen geprüft.
Hier kann für jeden möglichen Artikelstatus eine p445 - Artikelpflegevarianten (artikelvar) angegeben werden.
Bei der Prüfung werden alle über die Pflegevariante festgelegten Zwangsfelder in den Tabellen f030 Artikelstamm, f031 Lagerdaten und f016 Artikelselektionskennzeichen geprüft.
Über die Artikelprüfvariante kann zusätzlich noch gesteuert werden, welche Artikel überhaupt in die Prüfungen einfließen. Die in der Variante Konfigurierten Bereiche für Artikelsatzarten, Artikel-ID's, Artikelstatus, Waren-, Artikel- und Untergruppen werden zur Einschränkung der zu prüfenden Datenmenge verwendet.
Bei der SQL Prüfung werden alle SQL Scripte in den Verzeichnissen
${PROJ}\sql\dqc
${PROJ}\sql.indi\dqc
${PROJ}\sql.${HHENVDOMAIN}\dqc
durchlaufen.
Diese SQL Scripte haben die Möglichkeit, erweitere Informationen zu selektieren, die entweder in der Tabelle dqinfo oder in der Tabelle dqerror dargestellt werden.
Die SQL Scripte sollten Datensätze liefern, die folgende Elemente enthalten können:
tab - Tabellenname, auf den sich der Datensatz bezieht.
satz_key_1 - Wird ein satz_key_1 geliefert, wird das Ergebnis als Prüfungsfehler in dqerror gespeichert. Ansonsten entsteht ein Informationsdatensatz in dqinfo
field - Name des Datenfelds, auf den sich der über satz_key_1 gemeldete Fehler bezieht.
text - Beschreibender Text (dqinfo)
info1 - Zusatzinformation 1
info2 - Zusatzinformation 2
info1_awl - Name der Auswahlliste, die den Wert in info1 beschreibt.
info2_awl - Name der Auswahlliste, die den Wert in info2 beschreibt.
jahr - Jahreszahl, auf die sich die Anzahl bezieht.
anzahl - Anzahl Datensätze in der Periode
errorcode - Fehlercode. Wird nur ausgewertet, wenn ein Prüfungsfehler in dqerror gespeichert wird.
analysesql - Name des Analyse SQL. Hier kann eine SQL Anweisung definiert werden, die eine spätere Fehleranalyse erlaubt. Achtung: Für eine Kombination Tabelle/Feldname/Fehlertyp, muss der Analyse SQL immer der gleiche sein. Durch Angabe von "file:..." kann eine Analyse SQL Datei angegeben werden. z. B. select ... , 'file:${PROJ}\sql\dqm\f096_Rechnungsnummerluecken.sql' analysesql, ...
Beispiel:
select 'f186' tab, f186.sa_a info1, f186.sa_b info2, count(*) anzahl, 'm_statsa.awl' info1_awl, 'm_statsa.awl' info2_awl
from f186 group by f186.sa_a, f186.sa_b;
In dem Beispiel werden Daten der Tabelle f186 ausgewertet. In "info1" und "info" werden die Statistiksatzarten sa_a und sa_b geliefert. Über die Auswahlliste "m_statsa.awl" erfolgt eine Umsetzung der info-Werte. Insgesamt werden alle Datensätze gezählt und nach Statistikvarianten getrennt ausgegeben.
Beispiel 2:
select 'f030' tab, 'vk_pe' field, key_1 satz_key_1, 11 errorcode from f030 where f030.vk_pe<=0 and f030.vk_prdiv<=0;
In dem Beispiel wird pro fehlerhaftem Datensatz der f030 ein Fehler in "dqerror" erzeugt.
Dabei wird der Fehlercode "11" (Divisor 0) geliefert, wenn die entsprechenden Bedingungen erfüllt sind.
Die Fehlercodes finden Sie in dem Datenhandbug der dqerrordef.
Über Konfigurationsdateien können die Datenqualitätsüberprüfungen konfiguriert werden.
Die Konfigurationsdateien werden in den durch die Variable FRMCFGPATH festgelegten Verzeichnissen gesucht.
Sie haben die Namen "dqm_base.xml", "dqm_proj.xml" und "dqm_vorort.xml".
Diese Dateien werden, sofern vorhanden, nacheinander verarbeitet. Sie schließen sich also nicht gegenseitig aus.
Beispiel einer Konfigurationsdatei:
<?xml version="1.0" encoding="utf-8"?>
<DataQualityConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Awls>
<AwlEntry>
<AwlName>x.awl</AwlName>
<IgnoreInAwlCheck>true</IgnoreInAwlCheck>
</AwlEntry>
<AwlEntry>
<AwlName>y.awl</AwlName>
<IgnoreInAwlCheck>true</IgnoreInAwlCheck>
</AwlEntry>
</Awls>
<Tables>
<TableEntry>
<SqlName>f089</SqlName>
<IgnoreInRelationCheck>true</IgnoreInRelationCheck>
</TableEntry>
<TableEntry>
<SqlName>f000</SqlName>
<IgnoreInRelationCheck>false</IgnoreInRelationCheck>
<Fields>
<FieldEntry>
<FieldName>konto</FieldName>
<IgnoreInRelationCheck>true</IgnoreInRelationCheck>
</FieldEntry>
</Fields>
</TableEntry>
</Tables>
</DataQualityConfig>
Erklärung der Einträge:
Über "AwlEntry" können Auswahllisten von der Auswahllistenprüfung ausgeschlossen werden.
Dies kann z.B. für Auswahllisten genutzt werden, die Vorschlagswerte enthalten, bei denen aber die Werte nicht auf die vorgeschlagenen Auswahllistenwerte begrenzt sind.
Über "TableEntry" können ganze Tabellen aus der Relationsprüfung ausgeschlossen werden.
Dies kann z.B. für statistische Tabellen verwendet werden, wenn die dort enthaltenen Referenzen wie Artikel oder Kunden, durch Reorganisationen gelöscht werden können.
Über "FieldEntry" können nur bestimmte Datenfelder bestimmter Tabellen aus der Relationsprüfung ausgeschlossen werden.