Eine Datei öffnen. Dreißig Dinge prüfen. Fehler markieren. Ergebnis dokumentieren.
Nächste Datei.
Wenn dieser Ablauf regelmäßig stattfindet, wird irgendwann die Frage gestellt: Kann man dafür nicht ein kleines Prüfprogramm bauen? Ja, häufig kann man das. Aber nicht jede Prüfung braucht sofort VBA.
Einfache Pflichtfelder, Wertebereiche oder Dubletten lassen sich oft mit Formeln, Datenvalidierung, Power Query oder bedingter Formatierung abbilden. Ein individuelles VBA-Tool wird interessant, wenn mehrere Bedingungen zusammenspielen.
Zum Beispiel: Eine Datei muss zunächst auf Aufbau und Version geprüft werden. Danach gelten je nach Datensatztyp unterschiedliche Regeln. Einige Fehler stoppen die Verarbeitung. Andere werden nur protokolliert. Am Ende soll ein Prüfbericht entstehen, vielleicht ergänzt um eine korrigierte Ausgabedatei.
Dann ist nicht mehr nur eine Formel gefragt. Dann geht es um einen kompletten Prüfablauf. VBA kann dabei sehr praktisch sein, weil es direkt in der bekannten Office-Umgebung arbeitet. Nutzer müssen keine neue Plattform lernen. Dateien können ausgewählt, geprüft, markiert, umgewandelt und dokumentiert werden.
Ein gutes Prüfwerkzeug sollte aber mehr können als rote Zellen erzeugen.
Es sollte klar ausgeben:
- Welche Datei wurde geprüft?
- Welche Regel wurde verletzt?
- In welcher Zeile oder welchem Datensatz liegt das Problem?
- Ist es ein Fehler, eine Warnung oder nur ein Hinweis?
- Kann automatisch korrigiert werden?
- Welche Version der Prüfregeln wurde verwendet?
Gerade der letzte Punkt wird häufig vergessen. Prüfregeln ändern sich. Neue Felder kommen hinzu. Grenzwerte werden angepasst. Alte Ausnahmen entfallen. Wenn das Tool nicht wartbar aufgebaut ist, wird aus der Prüfsoftware schnell selbst ein Risiko.
Deshalb lohnt sich VBA besonders, wenn:
- die Prüfungen regelmäßig stattfinden,
- Regeln klar beschreibbar sind,
- Office-Dateien die zentrale Arbeitsgrundlage bleiben,
- der Nutzerkreis überschaubar ist,
- Ergebnisse dokumentiert werden müssen,
- manuelle Kontrolle heute viel Zeit bindet.
Weniger geeignet ist es, wenn sehr viele Nutzer gleichzeitig arbeiten, große Datenmengen dauerhaft gespeichert werden oder umfangreiche Rechte- und Workflowfunktionen nötig sind. Dann kann eine andere Architektur sinnvoller sein.
Für eine erste Einschätzung reichen eine typische Prüfdatei, eine Liste der wichtigsten Regeln und ein Beispiel für den gewünschten Prüfbericht. Daraus lässt sich meist schnell erkennen, ob VBA ausreicht oder ein anderes Werkzeug besser passt.
Projekt kurz schildern