Programmstabilität verbessern

[#1]

Die Datenprüfung stürzt leider extrem gerne ab oder produziert Fehler. Eine höhere Programmatabilität wäre wünschenswert.

[#2]

Hallo!

Abstürze und Fehlermeldungen sind ärgerlich und sollten bestenfalls gar nicht auftreten - sie sollten auch nicht als zu vermeidendes Ziel für die Weiterentwicklung erwähnt werden müssen, da eine hohe Programmstabilität eine Selbstverständlichkeit sein muss.

Wir lösen Fehler unabhängig von den in den DATEV Ideas diskutierten Vorschlägen für die Weiterentwicklung des Programms.

Bitte wenden Sie sich bei einer akuten Fehlersituation mit Ihrer Beraternummer im Programmservice, z. B. durch die Anlage eines Servicekontakts. Sie können den Servicekontakt auch aus jedem DATEV-Programm oder online über http://www.datev.de/servicekontakt aufrufen.

Viele Grüße,
Jochen Scheer
DATEV eG

[#3]

Technisch bedingte Änderung von Themenfremd => Offen => Themenfremd

[#4]

@andreashausmann   Hallo Herr Hausmann,  wenn man sich - so wie ich z.B. in den letzten 12 Monaten - sehr intensiv mit dem Programm auseinandersetzt, entdeckt man regelmäßig wiederkehrende und auch reproduzierbare Probleme und Abstürze,  zumindest kann man diese in vielen Fällen von den spontanen Exception-Programmabstürzen differenzieren, die nach einem Reboot verschwunden sind und nie mehr wieder kehren.

Manche Fehler überraschen auch weniger als andere, z.B. wenn man eine mehrere GB große Datei einlesen würde, bei der man von vorneherein weiß, dass die Datenqualität nicht optimal ist und ein Mandant für Fehlerquellen wie unzulässige Steuer oder Trennzeichenverwendung nicht unbekannt ist überrascht es evtl. weniger als wenn die Daten (bei anderem Mandant z.B.) immer weitgehend konform bereitgestellt werden.

Als Anwender wird man bei dem Tool Datenprüfung wahrscheinlich auch deutlich mehr Geduld, Erfahrungswerte und analytisches Mitdenken mitbringen, als dies evtl. in einer reinen Standardanwendung zur Bearbeitung der Buchhaltung oder in einer noch einfacheren Anwendung wie einem Texteditor o.ä. der Fall ist. 😉 

Und:  meine Erfahrung mit anderen Datenanalysetools über IDEA und ACL bis hin zum "Maschinenraum" in Excel, Access, SQL, R, Python, etc.:  das passiert da abhängig von Datenqualität, Fehlervielfalt und Komplexität ganz genauso. 😉

zum aktuellen Stand im Tool Datenprüfung im Fehlerfall / Abstürze / Exceptions:

m.E. ist DATEV auf die Reproduzierbarkeit bei Fehlern angewiesen bzw. kann bei den einmaligen Fällen die Probleme nicht immer gut analysieren (sofern kein Ereignis- oder Verboselogging besteht).  Das ist mit dem derzeitigen Exceptionhandling aber evtl. etwas erschwert, deshalb überrascht es auch nicht, wie oft die DATEV bei einer Weiterbehandlung eines Programmfehlers den kompletten Vorgang als Export benötigt, um das Verhalten zu simulieren.

@Jochen_Scheer :   es ist völlig klar, dass man - insbesondere reproduzierbare Bugs, Fehler und Programmabstürze am besten direkt immer als Service-Kontakte einstellt, statt als Idea. Das mache ich regelmäßig.  😉   Herr Schaller kann davon ein Lied singen. 😄

Allerdings hat das Tool Datenprüfung vielleicht ein paar Besonderheiten im Vergleich mit anderen Programmen, z.B. vergleichsweise sehr umfangreiche Importdatenbestände (in keinem Fall vergleichbar mit dem Durchschnitt in den leistungserstellenden Programmen, insbesondere nicht in der Wirtschaftsprüfung und in Verbindung mit ERP-Daten).  Weitere Besonderheiten:  eine vergleichsweise extrem hohe Vielfalt an Abweichungen und Fehlerquellen in den Strukturen von Importdaten,  vergleichsweise unvorhersehbare und heterogene Effekte durch Datenbankabfragen, Lockconditions, Mängel in der Datenqualität und Potentiale für Exceptions durch die Möglichkeiten Abfragen zu verschachteln, zu verknüpfen und dynamisch zu filtern.  Das gibt es so in kaum einer anderen DATEV-Anwendung, zumindest nicht vergleichbar.

Daher möchte ich vorschlagen, die ursprüngliche Idea evtl. wieder zu öffnen, jedoch ein wenig zu differenzieren.  Für's erste wäre ein optional zuschaltbares Logfile beim Datenimport hilfreich, was auch der Datenanalyst sich selbst ansehen oder widerum (z.B. durch die Möglichkeit es als Tabelle zu importieren 😉 ) direkt im Programm ansehen kann.  Gerne jeweils ebenso auch für die Bereiche Filterabfragen und Tabellensichten,  sowie Beziehungsdefinitionen, Referenztabellenbearbeitung oder Aneinanderhängen von Tabellen.  

Das Logging sollte nicht permanent arbeiten, aber bei Bedarf zuschaltbar sein und im Ergebnis am besten direkt in den Vorgang als Tabelle mit einem eingängigen Präfix (z.B. IMPORTFEHLER_Bezeichnung_der_Originaltabelle oder ERR_Name...) erfolgen.  

Klar kann ein Endanwender nicht immer damit etwas anfangen.  Wenn aber so etwas wie Fehler oder Exception xyz bei Verarbeitung in Tabelle x, Zeile 12, Spalte B erscheinen würde,  oder aber Fehler beim Aneinanderhängen Tabelle a von b, Feldname nicht identisch, o.ä.   oder z.B. Abweichung der Spaltenzahl beim Import von Datei xyz.csv in Zeile 12 Spalte D eindeutig in Logfiles erscheinen würde,  kann auch der Endanwender deutlich mehr damit anfangen, als wenn es lediglich zu Exceptions oder Abstürzen kommen sollte.     Selbst eine "Allgemeiner Fehler bei Verarbeitug in Tabelle abc, Zeile 1024, Spalte G" kann helfen, genauso wie ein "nicht genug Arbeitsspeicher" o.ä.  Klar, letzteres fällt in den Bereich Service-Report als Logfile, aber auch das wäre durchaus besser machbar als es heute passiert (heute schließt sich das Programm auch gerne mal mit einer Exception, ohne dass eine Meldung ausgegeben wird;  vermutlich wurde da nicht an jeder Stelle ein Exceptionhandler implementiert).

Vielleicht gibt es sogar heute schon einen (versteckten) Verbose / Logging-Modus, der mir nur nicht (mehr) bekannt ist oder der eben noch nicht als Tabellenansicht oder Mitteilung für den Endanwender sichtbar ist.

Oftmals hilft es bei Vorliegen einer solchen Meldung, wenn man sich dann die Quelltabellen in einem Notepad++, ASCII-Viewer oder CSV-Analysetool ansehen kann.  Dann merkt man, dass es evtl. gar nicht an DATEV Datenprüfung liegt.

Und wenn doch erleichtert es ungemein, dem Support entsprechend interpretierbare Fehler oder Folgefehler gleich mit dem Servicekontakt mit aussagekräftigeren Logfiles und Fehlern mitzugeben.  😉

Ich kann natürlich auch gerne eine neue Idea einstellen, falls das zwingend ist.. 

Oder jmd. verrät uns den Trick wie man an evtl. bereits vorhandene Logfiles herankommt. 😉

Sollten Sie in den untiefen des Programmverzeichnisses versteckt sein, würde ich als Idea auch vorschlagen, diese da herauszuholen und direkt (im Fehlerfall oder bei optionalem Zuschalten durch einen Haken beim Import) direkt in den Vorgang als zustätzliche Tabelle anzuhängen. 


@andreashausmann ,  @andreashofmeister , @Eugen_0704 :  Meinungen?   Alternativen?  Ansonsten bleibt wie immer nur die oftmals sehr aufwändige Einzelfallbearbeitung eines fast jeden Absturzes über den Servicekontakt, oder aber das berühmte Achselzucken>Reboot>nochmal probieren>anders probieren>aufgeben>frustriert sein>Rotwein trinken... 😄

Nächtliche Grüße, Bernd Wettstein.

[#5]

Hallo Herr Wettstein,

vielen Dank für die lange und ausführliche Antwort 🙂

Mein Anwendungsszenario schaut ein wenig anders aus als Ihres. Mit der Datenprüfung soll eine automatisierte Prüfung der FiBus durchgeführt werden. Daher sind meine Datenmengen und deren Komplexität oft auch überschaubar, da Sie direkt aus Kanzlei-Rechnungswesen kommen.

Ich lese keine externen Daten in die Datenprüfung ein. Bei externen Daten fühle ich mich mit Power Query und Power Pivot wohler.

Da es kaum Spaß macht die Datenprüfungen für irgendwann 100 - 200 FiBus "manuell" anzustoßen, sollen diese über die Admin-Anmeldung im DATEVasp automatisiert werden.

Da keine zwei Datenprüfungen gleichzeitig durchgeführt werden können, muss ich für die automatisierte Datenprüfung einen "Datenfahrplan" erstellen.

Spätestens an dieser Stelle kann ich keine Instabilität des Programmes mehr gebrauchen, da der Prozess sonst nicht funktioniert und vollends für die Tonne ist.

Normale Datenanalyse kann ich wie gesagt mit anderen Programmen besser realisieren 🙂

[#6]

Hallo @bernd_wettstein,

Probleme beim Datenimport wirken sich nicht zwingend auf die in der Idea angesprochenen Programmstabilität im Allgemeinen aus. Wenn es beim Datenimport mit der Konvertierung von Spalteninhalten zu einem Fehler kommt, wird das bereits heute nach dem Datenimport in einem Logfile ausgegeben.

Ich stimme Ihnen zu, dass spezifischere Programm-Meldungen mit zusätzlichen Kontextinformationen gut wären. Ich gebe das an die Entwicklung weiter.

@andreashausmann: Sie schreiben, dass sie sich mit PowerQuery und PowerPivot wohler fühlen. Was genau fehlt Ihnen in Datenprüfung? Ich meine mich zu erinnern, dass Sie aktuell Datenprüfung compact einsetzen. Konnten Sie Datenprüfung classic in der Vergangenheit schon einmal testen? Damit stehen viele Möglichkeiten für die individuelle Analyse importierter Daten auf Datensatzebene zur Verfügung. Gerne richte ich Ihnen bei Interesse dafür eine kostenfreie Testphase ein.

Viele Grüße,

Jochen Scheer
DATEV eG

[#7]

@Jochen_Scheer Vielen Dank für das Angebot. Die Testversion hatte ich schon und habe ein Seminar zur Datenprüfung besucht.

mMn nach ist bei der DATEV Datenprüfung die klare Stärke die Programmintegration, viele Standard-Analysen und die Automatisierbarkeit.

Bei Excel bin ich hingegen flexibler und kann Daten zB relativ schnell mit Pivot gut lesbar darstellen.

Auch der Preisunterschied zur Datenprüfung classic/comfort und Excel ist da nicht zu verachten 🙂

Zum Thema Programmstabilität hatte ich die Erfahrung gemacht, dass es mir öfters bei der Anlage von Prüfungsautomatismen passiert ist.

Mittlerweile gab es hier schon ein paar Fixes. Ich muss nur ehrlich gestehen, dass das Projekt Prüfungsautomatisierung derzeit auf Eis bei mir liegt, weil es einfach ungeheuer viel Zeit frisst und andere Themen mittlerweile eine höhere Priorität bekommen haben 😞