Update 1710 des Archivsystems

Planung

Das Archivierungssystem läuft nun seit knapp vier Monaten im Regelbetrieb und wird ausgiebig genutzt. Jedoch schaffen es die Nutzer immer wieder, durch konsequentes nicht Beachten der Anleitung, fehlerhafte Eintragungen zu machen.

In diversen Patches wurde unter anderem mit Version 1707 das Aussonderungsjahr in der Maskeneingabe gesperrt. Hintergrund war ein verschmitztes "Nie", was in diesem Kontext nicht nur falsch sondern absolut lächerlich war. (Mir könnte es eigentlich egal sein, der "Kunde" (mein Chef) fand es aber nicht so lustig)
Schlau, wie die Nutzer nunmal sind, wurde das Aussonderungsjahr aber weiterhin in der Tabelle geändert, nachdem die Erfassung durchgelaufen war.

Natürlich hätte ich die Tabelle selbst für die Bearbeitung sperren können, hatte mich aber bereits früh dagegen entschieden, um eine tatsächliche Fehlerkorrektur (Tippfehler, etc.) möglich zu machen. Das Problem habe ich bisher nicht gelöst, aber dazu später mehr.

Ein weiterer großer Wunsch des Verwalters war, dass die Meldungen nicht mehr händisch in die globale Liste kopiert werden müssen.

Darüber hinaus war der Auftrag der Geschäftsleitung, das Archivsystem standortübergreifend auf das bald zu fusionierende Nachbaramt auszuweiten. Ein Archiv, eine Liste, zwei Ämter.

Für den Zeitplan hatte ich einen gewissen Spielraum. Es war geplant, das Archiv Mitte Oktober (nachdem bauliche Verändeurngen abgeschlossen sind) an den neun Standort zu transferieren. Daher bot es sich an, eben zu diesem Zeitpunkt auch das "Update" zu terminieren. Das passte dann auch ganz gut mit meinen Urlaubsplänen zusammen 😉

Programmierung

Kopieren geht über studieren

Die größte Aufgabe sollte zuerst bewältigt werden: Kopieren der Daten von einer Excel-Datei in eine andere.

Zu Testzwecken kopierte ich mir die globale Liste und fing an, mich "schlau zu lesen" wie der Import von Daten implemetiert werden könnte.

Im Grunde war die Herangehensweise recht einfach. Man definere Worksheets "Ziel" und "Quelle" und kopiere dann Zellenweise, Zeilenweise die entsprechenden .Value

ziel.Cells(zeile,spalte).Value = quelle.Cells(qzeile,qspalte).Value

Soweit so klar. Die Untescheidung qzeile/zeile musste getroffen werden, da die Variable nicht gleich sein konnte. Schließlich war die Archivliste bereits 600 Einträge lang, die Meldung jedoch maximal 25 Einträge stark.

Für Ziel und Quelle mussten getrennt voneinander die leeren Zeilen gefunden werden, Für die Zieldatei als Startpunkt des Imports (Neuen Daten ans Ende der Liste) für die Quelldatei als Endpunkt des Imports (Ich wollte keine leeren Zeilen importieren).

Ein Klick auf Ausführen. HEUREKA!

Jetzt ergab sich nur ein Problem: Der Name der Quelldatei.

Wenn Dateien aus einer Mail heraus aufgerufen werden, landen sie im Temp-Ordner. Werden mehrere Dateien mit dem gleichen Namen geöffnet, wird der Dateiname um einen Index erweitert. (Archiv(1).xlsx, Archiv(2).xlsx)

Hieraus ergab sich eine mögliche Fehlerquelle. Es wurde im Code ja die Quelldatei "hart" einprogrammiert. Öffnet man eine zweite Meldung, kann die nicht mit dem selben Code importiert werden.
An dem Problem hab ich länger geknabbert als unbedingt nötig.

Wenn du nicht mehr weiter weißt, bilde einen Arbeitskreis

Ich hab mit einem Kollegen über das Problem gesprochen. Wie ich es ihm schilderte kam und gleichzeitig die "rettende Idee": Export statt Import

Ich nahm das Modul aus der Liste und fügte es in die Meldung ein. Jetzt lautete die Formel:

dim quelle as Worksheets
dim ziel as Worksheets

set quelle = ThisWorkbook.Worksheets("Liste")
set ziel = Workbooks("Archivliste.xlsm").Worksheets("Liste")

Zack Bumm, Problem gelöst.

Fehlerursache: Eingabe (oder "Mach es so wie ich will!")

Den Nutzern wurde klipp und klar mitgeteilt: Steuernummer OHNE Trennzeichen erfassen. Eigentlich ganz einfach oder? Sollte man meinen...
Außerdem scheint es wohl immernoch Menschen ohne Namen zu geben, diese waren nämlich auch öfter nicht erfasst worden.

Die Nutzer mussten also gezwungen werden, nach Programm zu arbeiten. Ich habe den Code des "Erfassen"-Formular um eine Zeile erweitert, welche vor Erfassen des Datensatzes die Textbox 2 (Steuernummer) und Textbox 3 (Name) auf folgende Attribute hin prüft:

• Ist Textbox2 rein nummerisch?
• Ist der Inhalt von Textbox2 exakt 10 Zeichen lang?
• Ist Textbox3 NICHT leer?

Zwar ist damit nicht das Problem gelöst, dass die Nutzer selbstständig in die Tabelle schreiben, aber das kriegen Sie auch noch ausgetrieben. 🙂

Fancieness und Luxus

Dem Archivverwalter sollte ein wenig Arbeit abgenommen werden, schließlich wird er in Kürze für zwei Ämter tätig sein und doppelt soviel Akten organisieren dürfen. Daher wurde zusätzlich das Modul "Archivsuchen" eingeführt. Dieses enthält im Grunde nur eine Funktion mit einem einfachen Auftrag: "Schau nach, ob eine der geöffneten Excel-Dateien "Archivliste.xlsm" heißt."
Die Funktion gibt dann an das aufrufende Hauptmodul einen Boolean-Ausdruck zurück. Ja oder Nein.
Dies wird in der Art realisiert, dass die Funktion sich zunächst auf "FALSE" setzt, und beim Finden der Datei Ihren Wert auf "TRUE" ändert.

Nach dem Exportieren wird die Quelldatei automatisch geschlossen, dass sorgt für mehr Übersicht auf dem Desktop. Akut ist die Meldung nach dem Exportieren sowieso überflüssig.

Im Hauptmodul wird dann mit einer IF-Abfrage geprüft ob der Wert FALSE zurückkommt. In diesem Fall wird über die Funktion Workbooks.Open die Archivliste mit vollständiger Pfadangabe geöffnet.

(Hier ein PRO-TIPP: Bevor Ihr so eine Funktion in den produktiven Einsatz gebt, schön den Pfad auf die ECHTE Datei ändern. Sonst ist nämlich Party in eurem Postfach.)

Zusammenfassung

Das Hauptodul gibts hier: Hauptmodul Archiv 1710
Den Code des Erfassen-Formulars gibts hier: Erfassen Archiv 1710
und das Archivsuchen lief so: Archivsuchen 1710

Ausblicke

Ein paar Ideen hab ich noch für die Liste.

Zum Beispiel könnte die Exportfunktion die Steuernummernspalte automatisch von den Trennstrichen befreien und somit ein bisschen dem Unwillen der Nutzer entgegen wirken.

Auch wäre ein "Rückkanal" in die Quell-Datei denkbar, so dass die laufende Nummer zurückgespeichert wir um einen Ausdruck der archivierten Dateien zu ermöglichen.

Ihr seht die Planungen für "1801" stehen bereits. Sicher werden auch die Anwender selber noch Ideen beisteuern. Nicht dass sie dies über Rückfragen und dergleichen tun (Auch wenn ich Ihnen sogar einen Button dafür spendiert habe). Aber wer redet schon gern mit Admins.

Für die Versionsnummerierung halte ich mich mal an das Linuxsystem mit JJMM und behalte voererst einen dreimonatigen Turnus bei. Ob der so bestehen bleibt (oder überhaupt noch notwendig ist) wird sich zeigen, aber wir ham ja Zeit 🙂