Business Central: Extensions und Branchenmodule in die Validierung einbeziehen

1. Mit dem Prozess beginnen und die Betriebsform benennen

Fragen Sie zunächst, welche Aufgabe die Erweiterung im regulierten Ablauf übernimmt. Verändert sie eine Materialentscheidung, berechnet sie eine relevante Menge oder überträgt sie benötigte Aufzeichnungen? Die Zahl ihrer Bildschirme sagt darüber wenig aus. Eine kleine Anpassung an einer entscheidenden Buchung kann wichtiger sein als ein umfangreiches rein kaufmännisches Modul.

Die technischen Hinweise dieses Artikels beziehen sich auf Business Central Online und die angegebenen Microsoft-Learn-Seiten. Für On-Premises gelten teils andere Betriebs- und Updatewege. Der regulatorische Schwerpunkt liegt auf GMP-Prozessen für Humanarzneimittel. Übertragen Sie diese Einordnung nicht ungeprüft auf andere Regelbereiche oder auf jede installierte App.

Dokumentieren Sie die relevante Prozessgrenze und die darin enthaltenen Komponenten. Leiten Sie den Nachweisumfang aus deren Auswirkungen ab. Weder der Vertriebsweg Marketplace noch die Bezeichnung kundeneigene Extension ergibt automatisch eine GAMP-Kategorie.

Quellen: [3] [10] [11]

2. Verstehen, was Microsoft tatsächlich prüft

Microsoft beschreibt als primären Zweck der technischen Marketplace-Validierung die Stabilität des Online-Dienstes und die Installierbarkeit beziehungsweise Ausführbarkeit der Apps. Dazu gehören unter anderem Paketinformationen, Abhängigkeiten, Kompilierung und Prüfungen mit AppSourceCop. Diese technischen Prüfungen beantworten keine vollständige fachliche Frage nach Ihrer Materialfreigabe oder Ihrem Aufzeichnungsprozess.

Die Herstelleranleitung zum Extension-Test beschreibt CRONUS-Demodaten als Grundlage der dortigen App-Prüfung. Microsoft weist außerdem darauf hin, dass der Herausgeber für funktionale und logische Prüfungen verantwortlich bleibt. Eine erfolgreiche technische Prüfung ist daher ein begrenzter Nachweis, dessen genaue Bedeutung Sie in Ihrer Lieferantenbewertung festhalten sollten.

Eine im Branchenmodul angebotene Funktion müssen Sie nicht ohne Anlass vollständig neu entwickeln oder jede Herstellerprüfung wiederholen. Prüfen Sie vielmehr, welche Anforderungen passende bestehende Nachweise abdecken und welche Lücken für Ihre Version, Konfiguration und Prozesskombination verbleiben.

Quellen: [1] [2] [6] [10]

3. Ein belastbares Verzeichnis der Erweiterungen aufbauen

Erfassen Sie für jede relevante App Name, Herausgeber, App-ID, Version, verwendete Umgebung, Zweck und zuständigen Partner. Ergänzen Sie die Abhängigkeiten und die Konfiguration, die Ihren Ablauf beeinflusst. Die Seite Manage Apps im Administrationscenter unterstützt den Blick auf installierte Apps und verfügbare Updates. Ein Screenshot allein ersetzt jedoch keine Zuordnung zu Ihren Anforderungen.

Microsoft unterscheidet globale Apps, umgebungsspezifische Per-Tenant Extensions und DEV-Erweiterungen. Für PTEs ist eine wichtige Besonderheit dokumentiert: Gleiche ID und Version können in verschiedenen Umgebungen unterschiedlichen Inhalt haben. Für die Übertragbarkeit eines Testergebnisses sollten Sie deshalb das tatsächliche freigegebene Paket eindeutig zuordnen, beispielsweise über eine kontrollierte Ablage und Prüfsumme.

Berücksichtigen Sie auch Bibliotheks-Apps ohne eigene Oberfläche. Wenn ein Update neue oder geänderte Abhängigkeiten benötigt, kann sich der Prüfgegenstand erweitern. Dokumentieren Sie die zusammengehörige Kombination, statt nur die sichtbar benannte Branchenlösung zu betrachten.

Quellen: [3] [4] [10]

4. Microsoft, Partner und Anwender klar zuordnen

Die folgende Matrix ist ein eigener Vorschlag zur Aufgabenklärung. Sie beschreibt keine pauschale vertragliche Leistung eines bestimmten Anbieters. Stimmen Sie für Ihren Einsatz ab, wer Unterlagen liefert, fachliche Sollwerte festlegt, Fehler untersucht und Entscheidungen trifft. Annex 11 fordert klare Verantwortlichkeiten bei eingesetzten Dritten; die konkrete Vereinbarung muss zu Ihren Leistungen und Datenwegen passen.

Besonders bei mehreren Partnern braucht der Gesamtprozess einen benannten Verantwortlichen. Andernfalls kann jede Komponente isoliert als funktionsfähig gelten, während die Übergabe zwischen ihnen ungeklärt bleibt. Benennen Sie deshalb auch den Ansprechpartner, der ein Problem über Produktgrenzen hinweg koordiniert.

Quellen: [1] [6] [10]

5. Vom Partner verwendbare Unterlagen anfordern

Fordern Sie Unterlagen für die tatsächlich eingesetzte Version an: beschriebene Funktionen, Grenzen, Konfigurationsmöglichkeiten, erforderliche Rechte, unterstützte Abhängigkeiten und bekannte Einschränkungen. Für relevante Änderungen sind außerdem Release-Hinweise und nachvollziehbare Ergebnisse der Anbieterprüfung hilfreich. Eine allgemeine Produktbroschüre reicht nicht, um die Bewertung eines konkreten Fehlerrisikos zu begründen.

Beurteilen Sie die Übertragbarkeit: Wurden vergleichbare Abläufe, Daten und Voraussetzungen geprüft? Sind Ergebnisse und Abweichungen erkennbar? Ein Nachweis aus einer anderen Konfiguration kann nützlich sein, muss aber passend eingeordnet werden. Legen Sie fehlende Informationen als konkrete offene Punkte mit Verantwortlichem fest.

Vereinbaren Sie den Lebenszyklus der Lösung: Wer hält sie kompatibel, informiert über Änderungen und unterstützt bei Störungen? Was geschieht bei Partnerwechsel oder Einstellung eines Moduls? Entscheidend ist auch der spätere Zugriff auf benötigte Aufzeichnungen, nicht nur die kurzfristige Installierbarkeit.

Quellen: [6] [10]

6. Beispiel: ein Branchenmodul zur Materialentscheidung prüfen

Angenommen, ein nicht näher benanntes Branchenmodul ergänzt Ihren Prozess um einen Prüfstatus und beeinflusst die Materialverwendung. Das ist ein eigenes fiktives Beispiel, keine zugesicherte Funktion einer bestimmten App. Als fachliche Vorgabe legen Sie fest, dass Material ohne erforderliche Entscheidung in den betroffenen Abläufen nicht verwendet werden darf.

Zeichnen Sie nun sämtliche relevanten Wege: manuelle Buchung, mobile Erfassung, Hintergrundverarbeitung und gegebenenfalls Schnittstelle. Beschreiben Sie, wo die Regel tatsächlich geprüft wird. Eine Sperre in einer einzelnen Eingabemaske ist kein Nachweis dafür, dass ein anderer Buchungsweg dieselbe Entscheidung berücksichtigt.

Führen Sie mit den vorgesehenen Rollen sowohl erlaubte als auch unerlaubte Aktionen aus. Prüfen Sie zudem, was nach einer Korrektur oder Statusänderung mit bereits angelegten Vorgängen geschieht. Die Akzeptanzkriterien müssen vor der Ausführung feststehen; ein technisch erfolgreiches Buchen kann fachlich gerade der Fehler sein.

Quellen: [10]

7. Schnittstellen und Testumgebung passend gestalten

Microsoft dokumentiert, dass ausgehende HttpClient-Aufrufe je Erweiterung freigegeben werden müssen, auch für Bibliotheks-Apps. Ein Aufruf kann bereits vor dem externen Dienst scheitern. Bewerten Sie bei einem Fehler deshalb sowohl Verbindung und Berechtigung als auch die fachliche Verarbeitung im Ziel. Ein erfolgreicher HTTP-Status ist dafür nur ein Teil des Nachweises.

Eine Umgebungskopie bildet nicht jede produktive Einstellung unverändert ab. Die Dokumentation nennt beispielsweise angehaltene Hintergrundaufgaben und zurückgesetzte Integrationseinstellungen. Prüfen Sie deshalb vor der Ausführung die benötigten Datenwege und richten Sie geeignete Testendpunkte ein. Aktivieren Sie keine realen externen Folgeaktionen nur, um einen Testfehler verschwinden zu lassen.

Für einen fachlichen Integrationstest sind repräsentative Rollen und erwartete Ergebnisse wichtiger als die sichtbare Ähnlichkeit zweier Oberflächen. Microsoft nennt bei Unterschieden zwischen Sandbox und Produktion unter anderem Benutzer, Rechte und HTTP-Einstellungen als mögliche Ursachen. Dokumentieren Sie solche Unterschiede und deren Einfluss auf die Aussagekraft Ihrer Ergebnisse.

Quellen: [8] [7] [9] [10]

8. Extension-Updates und Datenänderungen gemeinsam bewerten

Ein neues App-Paket kann zusätzliche Abhängigkeiten oder Aktualisierungen bestehender Apps erfordern. Die dokumentierte technische Kompatibilitätsprüfung für PTEs ersetzt dabei keine fachliche Prüfung Ihres Ablaufs. Klären Sie, welche Änderung an der Extension, ihrer Basisanwendung oder einer abhängigen Bibliothek Anlass für den geplanten Durchlauf ist.

Prüfen Sie bei betroffenen Datenstrukturen auch vorhandene Daten und offene Vorgänge. Ein erfolgreicher Neuvorgang nach Installation zeigt nicht, ob frühere Aufzeichnungen ihre Bedeutung behalten oder ein offener Auftrag korrekt fortgeführt wird. Wählen Sie passende repräsentative Datensätze und vergleichen Sie fachliche Sollwerte vor und nach der Änderung.

Vereinbaren Sie, wer technische Inkompatibilitätsmeldungen empfängt und bearbeitet. Microsoft weist darauf hin, dass inkompatible Erweiterungen unter bestimmten Updatebedingungen entfernt werden können. Dauerhaft auf einem alten Stand zu bleiben ist deshalb kein verlässliches Betriebskonzept. Bereiten Sie mit dem Partner einen tragfähigen Umgang mit Störungen und nötigen Ersatzabläufen vor.

Quellen: [4] [5] [6] [10]

9. Die getestete Kombination nachvollziehbar freigeben

Der Abschluss sollte die tatsächlich bewertete Kombination aus Business-Central-Stand, App-Paketen, Konfiguration und Datenwegen nennen. Verknüpfen Sie Anforderungen, verwendete Anbieterbelege, eigene Ergebnisse und Abweichungen. Dokumentieren Sie die fachliche Entscheidung über die weitere Nutzung einschließlich eventueller Einschränkungen.

Prüfen Sie bei der Übertragung in die Produktion, ob genau diese Kombination eingesetzt wird und notwendige Umgebungsunterschiede berücksichtigt sind. Ein anderes Paket mit gleicher Anzeigenummer oder eine zusätzliche Bibliothek kann die bisherige Bewertung verändern. Das verlangt eine begründete Neubewertung der Auswirkung, nicht automatisch einen vollständigen Neustart.

Legen Sie anschließend Zuständigkeiten für Störungsmeldung, Änderungen und regelmäßige Bewertung fest. Wenn eine Erweiterung relevante Aufzeichnungen beeinflusst, berücksichtigen Sie auch deren erforderlichen Änderungsnachweis und Aufbewahrung. Diese Kontrollen folgen dem konkreten Prozess; die Installation einer App erzeugt keine pauschale Pflicht zur Protokollierung jedes Feldes.

Quellen: [3] [10]

10. Mitwirkung und Aufwand vor Beginn klären

Für die Planung sollten Fachbereich, Qualitätssicherung, Systembetreuer und relevante Partner zusammenkommen. Der Fachbereich bestimmt das erwartete Ergebnis; technische Ansprechpartner erklären die Umsetzung und Datenwege. Wer beides allein dem jeweils anderen überlässt, erhält leicht einen erfolgreichen Installationstest ohne beantwortete Prozessfrage.

Den Aufwand bestimmen vor allem unbekannte Abhängigkeiten, kundeneigene Logik, Schnittstellen, Datenqualität und fehlende Nachweise. Eine übersichtliche App-Liste hilft, ist aber keine Aufwandsschätzung. Ermitteln Sie zuerst einen repräsentativen vollständigen Ablauf und die offenen Entscheidungen. Daraus lassen sich Arbeitspakete und benötigte Mitwirkung belastbarer ableiten.

• Betriebsform, Plattformstand und relevante Prozesse festhalten.
• Alle benötigten Apps mit Herkunft, Identität, Version und tatsächlichem Paket erfassen.
• Bibliotheken, Abhängigkeiten und kundeneigene Einstellungen zuordnen.
• Herstellernachweise auf konkreten Umfang und Übertragbarkeit prüfen.
• Fachliche Sollwerte, Rollen und Fehlerfälle vor dem Test festlegen.
• Testumgebung und sichere Gegensysteme geeignet vorbereiten.
• Bestehende Daten und offene Vorgänge bei Updates berücksichtigen.
• Abweichungen, Nutzungsentscheidung und Betriebsverantwortung dokumentieren.

Quellen: [10]