Inhaltsverzeichnis
Das Wichtigste vorab
Ist das Änderungsprotokoll von Business Central GxP-konform?
Das lässt sich nicht pauschal zusagen. Das Änderungsprotokoll kann ein Baustein sein, wenn relevante Tabellen und Felder, Schreibwege, Benutzerbezug, Aufbewahrung und Review passend eingerichtet und nachgewiesen sind. Prüfen Sie zusätzlich Lücken, administrative Eingriffe und Upgrade-Verhalten. Produktfunktion und vollständige Erfüllung Ihrer GxP-Anforderungen sind unterschiedliche Aussagen.
Die Frage am Geschäftsprozess festmachen
Dieser Beitrag betrachtet Dynamics 365 Business Central mit einer qualitätsrelevanten Anwendung. Gemeint ist nicht der Nachweis aller finanzwirtschaftlichen Änderungen. Beginnen Sie mit den Aufzeichnungen, deren Änderung Produktqualität, Rückverfolgbarkeit oder eine fachliche Entscheidung beeinflussen kann: etwa ein Qualitätsparameter, ein Chargenbezug oder ein Freigabestatus in einer Erweiterung.
Notieren Sie Edition, Version, Online- oder On-Premises-Betrieb, Erweiterungen und Mandanten. Eine Erweiterung kann eigene Tabellen oder Schreibwege mitbringen. Ein Protokollnachweis für eine Standardtabelle beweist deshalb nicht automatisch die Abdeckung des kundenspezifischen Qualitätsprozesses.
Annex 11 behandelt risikobasierte Audit-Trails und deren verständlichen Review. Die passende Umsetzung ergibt sich aus der tatsächlichen Anwendung. Die folgende Matrix ist eine eigene Arbeitshilfe. Sie stellt keine generelle Zertifizierung von Business Central dar.
Was die Standardfunktion leistet und wo Sie genauer hinsehen
Microsoft beschreibt ein Änderungsprotokoll für ausgewählte Tabellen, Felder und Änderungsarten. Die Konfiguration ist daher Teil des Nachweises. Ein eingeschalteter globaler Schalter zeigt noch nicht, ob der relevante Qualitätsparameter enthalten ist. Die Herstellerdokumentation nennt außerdem Grenzen, etwa Felder mit AutoIncrement-Eigenschaft.
Änderungsprotokoll, Feldüberwachung und Aktivitätsprotokoll sind nicht dasselbe. Ein Importfehler im Aktivitätsprotokoll beantwortet eine andere Frage als die Historie einer kritischen Stammdatenänderung. Ordnen Sie jeder benötigten Aussage eine konkrete Nachweisquelle zu. Vermeiden Sie die Sammelbezeichnung „Audit-Trail“, wenn mehrere Funktionen mit unterschiedlichen Grenzen gemeint sind.
Microsoft weist auf die Sitzungsabhängigkeit der Anzeige und das Abschalten während eines Versionsupgrades hin. Diese Angaben sind für das Testdesign relevant. Ein unmittelbar leerer Protokollbildschirm beweist nicht zwingend fehlende Erfassung; umgekehrt darf ein dokumentiertes Upgrade-Fenster keine ungeklärte Veränderung kritischer Daten verdecken.
Quellen: [2]
Eine Abdeckungsmatrix statt einer Funktionsliste aufbauen
Erstellen Sie zunächst eine Liste kritischer Geschäftsereignisse. Beschreiben Sie das Ereignis in der Sprache des Fachbereichs und ergänzen Sie Tabelle, Feld und tatsächlich verwendeten Schreibweg. Auch eine API oder ein Import kann relevant sein. Ob dabei der erforderliche Eintrag entsteht, wird im konkreten System geprüft und nicht aus einem Oberflächentest abgeleitet.
Erfassen Sie den benötigten Kontext: betroffener Datensatz, Benutzer oder technische Identität, Zeitpunkt, alter und neuer Wert sowie gegebenenfalls Änderungsgrund. Wo ein Grund erforderlich ist, prüfen Sie dessen kontrollierte Zuordnung. Ein Freitext in einer getrennten E-Mail ist ohne eindeutigen Bezug keine automatisch ausreichende Verbindung.
Betrachten Sie auch Löschung, Wiederanlage und Änderungen an der Protokollkonfiguration. Die Frage lautet jeweils: Kann ein berechtigter Prüfer erkennen, was fachlich passiert ist? Eine technische Datensatznummer ohne aufbewahrten Geschäftsbezug kann dafür zu wenig sein.
| Ereignis | Zu prüfende Abdeckung | Erwarteter Zusammenhang |
|---|---|---|
| Grenzwert ändern | Konkrete Tabelle und Feld; Oberfläche und Import | Vorher/nachher, Identität, Zeitpunkt, Artikelbezug |
| Chargenstatus ändern | Standard oder Erweiterung; alle verwendeten Wege | Charge und maßgebliche Statusfolge |
| Kritischen Datensatz löschen | Löschereignis und aufbewahrter Kontext | Betroffene Aufzeichnung bleibt identifizierbar |
| Protokollierung umstellen | Aktivierung und Konfigurationsänderung | Befugnis und nachvollziehbarer Anlass |
| Historie aufrufen | Rolle, Filter, Mandant und Aufbewahrung | Vollständige relevante Ansicht für den Review |
Prüfbeispiel: ein Grenzwert wird enger gesetzt
Das Beispiel ist konstruiert. Artikel A-17 hat einen freigaberelevanten Grenzwert von 10,0 mg. Ein berechtigter Stammdatenverantwortlicher ändert ihn auf 9,5 mg. Eine zweite Rolle darf diesen Wert lesen, aber nicht ändern. Eine technische Schnittstelle kann dieselbe Tabelle im vereinbarten Prozess aktualisieren.
Prüfen Sie zunächst die erlaubte Änderung über die Oberfläche. Nach dem laut Dokumentation erforderlichen Sitzungswechsel wird der Historieneintrag gesucht. Erwartet werden der richtige Artikel, alter und neuer Wert, zugeordnete Identität und Zeitpunkt. Prüfen Sie anschließend, ob der fachlich geforderte Änderungsgrund verlässlich verbunden ist. Fehlt er, wird die Lücke benannt und eine geeignete Lösung bewertet.
Wiederholen Sie den relevanten Fall über den tatsächlich verwendeten Schnittstellenweg. Der Soll-Nachweis ist nicht „irgendein Eintrag vorhanden“, sondern derselbe fachliche Zusammenhang mit der technischen Identität und dem auslösenden Vorgang. Anschließend folgt ein abgewiesener Änderungsversuch der reinen Leserolle. Eine fehlende unerlaubte Änderung und ein protokollierter erlaubter Eingriff sind getrennte Prüfaussagen.
| Fall | Aktion | Akzeptanzkriterium |
|---|---|---|
| Erlaubte Änderung | 10,0 mg auf 9,5 mg durch benannte Rolle | Datensatz und relevante Änderung rekonstruierbar |
| Schnittstellenänderung | Gleiche Feldänderung über vereinbarten Import | Schreibweg und Identität nachvollziehbar |
| Unerlaubte Änderung | Leserolle versucht Änderung | Änderung entsprechend Berechtigungskonzept verhindert |
| Rückänderung | 9,5 mg zurück auf 10,0 mg | Beide Ereignisse bleiben unterscheidbar |
| Review | Prüfer sucht A-17 über Zeitraumfilter | Relevante Ereignisse lesbar und zuordenbar |
Upgrade und administrative Rechte als eigene Prüfthemen
Planen Sie für ein Versionsupgrade, wie kritische Daten während der Umstellung kontrolliert werden. Dazu gehören ein dokumentierter Ausgangsstand, bewertete Migrations- oder Erweiterungsschritte und ein fachlicher Abgleich nach der Aktualisierung. Dass die Standardprotokollierung anschließend wieder startet, beweist nicht, welche Änderungen während der Unterbrechung stattgefunden haben.
Legen Sie vor dem Upgrade fest, welche ergänzenden Nachweise erforderlich sind. Das können objektbezogene Abgleiche, kontrollierte Upgrade-Protokolle oder gezielte Funktionstests sein. Der Umfang richtet sich nach dem Eingriff. Eine reine Oberflächenänderung und eine Datenumwandlung mit neuen Statusregeln benötigen unterschiedliche Prüfungen.
Beurteilen Sie, wer Protokollierung konfigurieren, Einträge löschen oder Aufbewahrungsrichtlinien ändern kann. Ein Administrator benötigt möglicherweise weitreichende Befugnisse. Dann sind kontrollierte Vergabe, begründete Verwendung und geeignete unabhängige Überwachung zu betrachten. Die fachliche Kontrolle sollte nicht allein von derselben Person abhängen, deren Eingriffe sie beurteilen soll.
Aufbewahrung und Review betrieblich verankern
Leiten Sie die benötigte Aufbewahrung aus den betreffenden Aufzeichnungen und anwendbaren Anforderungen ab. Eine technische Standardfrist ist kein fachlicher Beschluss. Prüfen Sie die aktive Richtlinie mit ihren Filtern und den Zugriff auf ältere Daten. Auch nach einer Archivierung muss der erforderliche Kontext verständlich bleiben.
Der Review braucht eine konkrete Frage: Welche Änderungen beeinflussen eine Entscheidung, welche Abweichungen sind zu klären und wer bearbeitet sie? Eine monatlich abgelegte Gesamtdatei ohne Prüfung beantwortet diese Fragen nicht. Zeitpunkt und Tiefe des Reviews werden nach Prozess und Risiko festgelegt; eine universelle Frequenz wäre hier nicht begründbar.
Dokumentieren Sie repräsentativ, wie ein Reviewer relevante Änderungen findet und bewertet. Dazu gehören sinnvolle Filter, die richtige Mandantenauswahl und der Zugang zur Ausgangsaufzeichnung. Ein Prüfer muss beispielsweise erkennen können, ob der Grenzwert vor oder nach der betrachteten Qualitätsentscheidung geändert wurde.
So fällt die Eignungsentscheidung nachvollziehbar aus
Das Ergebnis kann drei Formen haben: Die vorhandene Konfiguration deckt die Anforderungen im festgelegten Umfang ab; sie benötigt gezielte Ergänzungen; oder für bestimmte Vorgänge ist eine andere technische beziehungsweise prozessuale Lösung nötig. Begründen Sie diese Entscheidung ereignisbezogen. Ein pauschales „Standard reicht“ ist ebenso wenig hilfreich wie ein pauschales „ERP kann das nicht“.
Fassen Sie offene Lücken, ihre Auswirkungen und Maßnahmen zusammen. Ist eine relevante Änderung nicht nachvollziehbar, prüfen Sie auch die Bedeutung für bereits erzeugte Aufzeichnungen. Eine künftige Konfigurationskorrektur ersetzt diese Rückschau nicht. Bei unvertretbaren Risiken muss die Nutzung entsprechend begrenzt oder unterbrochen werden.
Übergeben Sie die freigegebene Konfiguration, Testfälle, Review-Regel und Zuständigkeiten an den Betrieb. Ergänzen Sie Auslöser für eine erneute Bewertung: Erweiterungen, neue Felder, weitere Mandanten, neue Schnittstellen oder geänderte Aufbewahrung. So bleibt die Aussage auch nach dem Einführungsprojekt überprüfbar.
Häufige Fragen zu Business Central: Audit-Trail
Ist Feldüberwachung dasselbe wie Änderungsprotokoll?
Nein. Microsoft beschreibt getrennte Funktionen mit eigener Einrichtung. Die Feldüberwachung kann beispielsweise Benachrichtigungen zu überwachten Feldern bereitstellen. Prüfen Sie, welche Funktion im konkreten Prozess verwendet wird und welche Historie tatsächlich erhalten bleibt. Mehrere eingeschaltete Funktionen ergeben nicht automatisch eine vollständige GxP-Abdeckung.
Quellen: [2]
Warum sehe ich direkt nach einer Änderung keinen Eintrag?
Microsoft nennt einen erforderlichen Neustart der Benutzersitzung für die Anzeige der Änderungen. Berücksichtigen Sie das in der Testdurchführung. Prüfen Sie danach den richtigen Mandanten, die konfigurierte Tabelle, das Feld und die Filter. Bleibt der Eintrag aus, dokumentieren Sie den Befund und klären die tatsächliche Abdeckung.
Quellen: [2]
Werden API-Änderungen automatisch ausreichend protokolliert?
Treffen Sie diese Aussage erst nach Prüfung des verwendeten Schreibwegs, der Erweiterung und des benötigten Kontextes. Ein erfolgreicher Oberflächentest reicht nicht. Die technische Identität sollte einem kontrollierten Vorgang zugeordnet werden können; der fachliche Auslöser kann zusätzliche Nachweise erfordern.
Quellen: [1]
Was passiert mit dem Änderungsprotokoll beim Upgrade?
Die Herstellerdokumentation beschreibt eine Deaktivierung während des Versionsupgrades und eine anschließende Wiederaufnahme. Bewerten Sie daher Eingriffe im Upgrade-Fenster gesondert und planen Sie passende Abgleiche. Der automatische Neustart des Logs bestätigt nicht rückwirkend die Bedeutung aller vorgenommenen Datenänderungen.
Quellen: [2]
Muss jede Tabelle vollständig protokolliert werden?
Leiten Sie den Umfang aus kritischen Aufzeichnungen und Geschäftsereignissen ab. Eine ungezielte Vollprotokollierung kann den Review erschweren und technische Auswirkungen haben. Das Weglassen relevanter Felder ist aber ebenfalls nicht begründbar. Halten Sie Auswahl und Grenzen in einer Abdeckungsmatrix fest.
Kann man alte Protokolle zur Speicherentlastung löschen?
Nur nach einer begründeten Aufbewahrungsentscheidung und einem kontrollierten Verfahren. Berücksichtigen Sie die zugehörigen Aufzeichnungen, noch offene Untersuchungen und erforderliche Nachvollziehbarkeit. Testen Sie Richtlinien und Berechtigungen so, dass relevante Historie nicht versehentlich früher entfällt.
Quellen & fachlicher Stand
Stand: 14. Oktober 2026. Regulatorische Einordnung und Herstellerfunktionen sind getrennt belegt. Beispiele, Testmatrizen und Vorlagen sind eigene Arbeitshilfen; sie werden für den tatsächlichen Einsatzzweck angepasst.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
- Microsoft: Änderungen prüfen in Business Central
- PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Wie wir Sie dabei unterstützen
Daniel Herrmann Consulting verbindet die fachliche Bewertung mit der Arbeit am konkreten System. Im Erstgespräch klären wir Ihren Einsatzzweck, vorhandene Nachweise und den nächsten sinnvollen Schritt.
- IT-GxP-Audit →
Den tatsächlichen Handlungsbedarf bewerten und Maßnahmen begründet priorisieren.