Dynamics 365 Finance and Operations validieren: Prüfmenge, Bestandssperre und Freigabe

1. Finance und Supply Chain Management richtig eingrenzen

Finance and Operations bezeichnet hier den übergreifenden Anwendungskontext. Microsoft führt heute unter anderem Dynamics 365 Finance und Dynamics 365 Supply Chain Management als getrennte Anwendungen. Finanzbuchhaltung, Kreditoren und Budgetierung gehören zu Finance; die hier behandelten Qualitäts- und Bestandsfunktionen stammen aus Supply Chain Management. Eine Business-Central-Anleitung ist dafür keine belastbare Funktionsbeschreibung.

Erfassen Sie Anwendung und Build, aktivierte Funktionen, Gesellschaften, Standorte, Erweiterungen, Lagerkonzept und Schnittstellen. Klären Sie außerdem die tatsächliche Bereitstellung und Betriebsverantwortung. Eine allgemeine Cloud-Aussage beweist weder, welche Module lizenziert sind, noch welche Erweiterungen ein Implementierungspartner eingebaut hat. Auch ein ungenutztes Modul benötigt nicht allein wegen seiner Existenz dieselbe Prüftiefe wie eine kritische Materialentscheidung.

Der regulatorische Bezug dieses Artikels ist der Einsatz innerhalb der GMP-Herstellung von Humanarzneimitteln. Die aktuelle EudraLex-Übersicht führt dafür Annex 11 in der Revision Januar 2011. Die konkrete Qualitäts- und Datenwirkung entscheidet über den Validierungsumfang. Reine Finanzfunktionen werden nicht automatisch zur GMP-Funktion; gemeinsame Daten oder Berechtigungen können dennoch relevant sein. Andere Regelbereiche sind gesondert zu beurteilen.

Quellen: [1] [2] [8] [9]

2. Entscheidung und Beleg sauber zuordnen

Legen Sie vor der Testplanung fest, was jeder Status fachlich bedeutet. Kann ein Material geplant, reserviert, kommissioniert oder tatsächlich eingesetzt werden? Welche Entscheidung stammt aus dem Labor, welche aus der verantwortlichen Qualitätsfunktion? Die folgende Arbeitshilfe verbindet diese Fragen; sie ist kein vorgeschriebenes Dokumentformat und kein Abbild einer universellen Microsoft-Konfiguration.

Ein vollständiger Beleg braucht die betroffene Identität: Artikel, Charge, Menge, Einheit, Gesellschaft und relevante Lagerdimensionen. Ein Screenshot mit grünem Status ohne diese Zuordnung kann die entscheidende Fehlverwendung verdecken. Dokumentieren Sie außerdem die zulässigen Ausnahmen, etwa eine interne Bewegung zur Probenahme, obwohl der Einsatz in der Herstellung noch nicht erlaubt ist.

Quellen: [4] [6] [10] [11]

3. Prüfmenge und Sperrmenge auseinanderhalten

Qualitätszuordnungen können bei definierten Geschäftsereignissen Qualitätsaufträge auslösen. Prüfen Sie daher die Bedingung selbst: Gilt sie für den richtigen Artikel, Standort, Lieferprozess und Zeitpunkt? Ein erfolgreicher Test eines Wareneingangs beweist nicht automatisch die Abdeckung eines zweiten Standorts oder eines anders gebuchten Zugangs. Verwenden Sie gezielt einen passenden und einen knapp außerhalb liegenden Fall.

Microsoft unterscheidet bei der Sperrwirkung zwischen manuell und automatisch erzeugten Qualitätsaufträgen. Bei manueller Anlage bestimmt die Auftragsmenge die gesperrte Menge; eine Stichprobe ändert nicht automatisch diesen Schutzumfang. Bei automatischer Erzeugung kann Full blocking die gesamte Quellmenge schützen. Die Option Create item sampling work only erzeugt dagegen weder Qualitätsauftrag noch Bestandssperre. Genau diese Varianten gehören in die Konfigurationsbewertung.

Definieren Sie getrennte Sollwerte für Prüfmenge und geschützte Menge. Kontrollieren Sie zusätzlich den Ausnahmeweg: Darf ein Mitarbeiter statt des vorgesehenen automatischen Prozesses einen manuellen Auftrag anlegen? Falls ja, welche Kontrolle hält den restlichen Bestand zurück? Ein rein organisatorischer Hinweis ist nur dann tragfähig, wenn seine Anwendung, Verantwortung und Wirksamkeit zum konkreten Risiko passen.

Quellen: [3] [5] [9]

4. Chargendisposition an der erlaubten Aktion prüfen

Batch disposition codes können Verfügbarkeit und einzelne Folgeaktionen beeinflussen. Microsoft dokumentiert für Unavailable zunächst blockierende Vorgaben, aber auch veränderbare Ausnahmen. Deshalb ist die Bezeichnung „nicht verfügbar“ kein ausreichender Testbefund. Nettable steuert daneben, ob Bestand in der Planung berücksichtigt wird. Eine Planungsmenge beantwortet eine andere Frage als die Möglichkeit einer Entnahme.

Prüfen Sie die tatsächlich genutzten Verkaufs-, Umlagerungs- und Produktionswege. Bei WMS-Artikeln sind auch Lagerkonfiguration und Reservierungshierarchie relevant; die Herstellerdokumentation nennt dafür konkrete Voraussetzungen. Ein Test außerhalb Ihres produktiven Lagerkonzepts kann eine Sperre bestätigen, die im späteren Ablauf anders wirkt. Halten Sie die wesentlichen Test- und Produktivparameter vergleichbar und begründen Sie Abweichungen.

Bei kombinierten Sperrmechanismen können mehrere Buchungen auf denselben physischen Bestand verweisen. Addieren Sie deshalb nicht blind jede angezeigte Sperrmenge. Vergleichen Sie physische Menge, fachliche Verfügbarkeit, Reservierungen und den Ursprung jeder Sperre. Falls trotz Quarantäne eine kontrollierte interne Bewegung erlaubt sein soll, testen Sie diese ausdrücklich getrennt von einer unzulässigen Verwendung oder Auslieferung.

Quellen: [6] [5]

5. Illustratives Prüfbeispiel mit unabhängig berechneten Sollmengen

Das folgende Beispiel ist frei konstruiert und kein Kunden- oder ausgeführter Produkttest. Ein Material besitzt Charge R mit 80 verwendbaren Einheiten. Charge Q kommt mit 200 Einheiten hinzu und bleibt bis zur vorgesehenen Qualitätsentscheidung vollständig gesperrt. Zehn Einheiten werden nicht destruktiv geprüft und bleiben physisch Teil der 200. Der Bedarf beträgt 110 Einheiten. Diese Stichprobengröße ist eine Beispielannahme, keine fachliche Probenahmeempfehlung.

Vor Freigabe sind somit 280 Einheiten physisch vorhanden, aber nur 80 für den definierten Verwendungsweg verfügbar. Es fehlen 30 verwendbare Einheiten. Nach einer berechtigten positiven Entscheidung dürfen im Beispiel 80 aus R und 30 aus Q verwendet werden; Q enthält anschließend 170 Einheiten. Negative Zweige starten jeweils erneut aus dem definierten Ausgangszustand, damit fehlerhafte Buchungen keinen Folgefall verfälschen.

Quellen: [3] [5] [6]

6. Ergebnis, Analysenzertifikat und pharmazeutische Entscheidung trennen

Ein Qualitätsauftrag kann Prüfergebnisse sammeln und einen positiven Abschluss anzeigen. Microsoft dokumentiert zugleich das erneute Öffnen eines bereits validierten Auftrags. Legen Sie deshalb fest, was eine spätere Änderung mit einer bereits getroffenen Materialentscheidung macht. Bleibt Bestand verwendbar, wird die Entscheidung überprüft oder greift eine andere Kontrolle? Diese Frage muss anhand Ihres Risikos beantwortet werden.

Auch ein Analysenzertifikat ist ein bewusst zusammengestellter Bericht. Die Aufnahme einzelner Tests ist konfigurierbar. Vergleichen Sie daher einen benötigten Bericht mit den tatsächlich zugrunde liegenden Ergebnissen, Einheiten und Testversionen. Ein fehlender Test darf nicht allein deshalb unbemerkt bleiben, weil der Ausdruck formal vollständig aussieht. Erfassen Sie, wer eine Berichtsauswahl ändern darf und wie eine relevante Änderung bewertet wird.

Für Fertigarzneimittel unterscheidet Annex 16 die Prüfung, die QP-Zertifizierung und die nachfolgende Überführung in verkaufsfähigen Bestand. Eine Materialfreigabe im ERP ist nicht automatisch diese Zertifizierung. Definieren Sie bei verbundenen Systemen, welcher Nachweis die technische Statusänderung auslöst und wie eine aufgehobene oder korrigierte Entscheidung die weitere Verwendung beeinflusst.

Quellen: [4] [10] [11]

7. Schnittstellen am fachlichen Übergang testen

Für einen Qualitätsentscheid aus einem LIMS oder QMS ist nicht nur die technische Übertragung wichtig. Als eigene Prüfvorgabe sollte die Nachricht eindeutig auf Gesellschaft, Artikel, Charge und zulässigen Statuswechsel verweisen. Definieren Sie, welches System führend ist und was geschieht, wenn diese Zuordnung fehlt. Eine akzeptierte Nachricht ohne fachlich wirksame Zuordnung ist kein erfolgreicher Gesamtprozess.

Bauen Sie passende Fehlerfälle auf: dieselbe Entscheidung zweimal senden, eine unbekannte Charge ansprechen, eine ältere Entscheidung nach einer neueren liefern oder die Verarbeitung unterbrechen. Das erwartete Verhalten hängt von der gewählten Schnittstelle ab. Behaupten Sie weder pauschale Synchronität noch automatische Dublettensicherheit. Prüfen Sie den tatsächlichen Zielzustand und die Möglichkeit, einen unvollständigen Übergang zu erkennen und kontrolliert nachzubearbeiten.

Bei Migrationen zählt neben der Mengensumme die Bedeutung. Übernommene Sperrkennzeichen, Chargenidentitäten und offene Qualitätsaufträge dürfen nicht stillschweigend anders wirken. Vergleichen Sie ausgewählte kritische Datensätze mit einer unabhängigen Quelle und prüfen Sie anschließend die erlaubte Aktion. Ein reiner Summenabgleich würde im Beispiel den Unterschied zwischen 280 physischen und 80 verwendbaren Einheiten nicht erklären.

Quellen: [9] [6] [7]

8. Rechte und relevante Änderungen nachvollziehbar machen

Erstellen Sie eine kleine Entscheidungsmatrix für Wareneingang, Ergebnisbewertung, Statusumstellung, Parameterpflege und technische Administration. Die Namen Ihrer Rollen sind zweitrangig; ausschlaggebend ist, welche Kombination tatsächlich möglich ist. Berücksichtigen Sie Stellvertretung und technische Schnittstellenkonten. Ein Benutzer ohne sichtbaren Menüpunkt könnte über einen anderen vorgesehenen Schreibweg weiterhin relevant eingreifen.

Prüfen Sie eine berechtigte Änderung und denselben Versuch mit unzureichender Befugnis. Nehmen Sie außerdem die Änderung einer qualitätsrelevanten Regel auf: Eine korrekt geschützte Charge hilft wenig, wenn dieselbe Person unbemerkt ihre Sperrvoraussetzung abschalten kann. Dokumentieren Sie die tatsächlich wirksame Kontrolle, statt aus einer Rollenbezeichnung auf ihre Vollständigkeit zu schließen.

Für relevante Änderungen werden alter und neuer Sachverhalt, Verantwortlichkeit, Zeitpunkt und gegebenenfalls Begründung benötigt. Welche Aufzeichnungen Ihre konkrete Umgebung dafür bereitstellt, ist zu prüfen; dieser Leitfaden behauptet keinen universellen Dynamics-Auditumfang. Legen Sie fest, wer diese Belege bei einer Unstimmigkeit auswertet und wie sie im Zusammenhang mit Qualitätsauftrag und Materialentscheidung auffindbar bleiben.

Quellen: [9] [10]

9. Updates nach Auswirkungen statt nach Kalendergefühl bewerten

Der One-Version-Prozess verbindet Anwendungs- und Plattformänderungen; bestimmte Zusatzkomponenten folgen eigenen Aktualisierungswegen. Erfassen Sie deshalb neben dem Hauptbuild die betroffenen Erweiterungen und verbundenen Dienste. Microsoft beschreibt unterschiedliche Abläufe für Cloud und lokale Bereitstellung. Planen Sie anhand Ihres tatsächlichen Serviceprozesses; historische Versionsbeispiele sind keine aktuelle Terminfreigabe.

Wählen Sie Regression anhand einer konkreten Wirkungskette: Könnte die Änderung den Auslöser des Qualitätsauftrags, die Sperrmenge, eine Lageraktion, Berechtigung oder Schnittstellenzuordnung beeinflussen? Dann gehören entsprechende vorhandene Nachweise und gegebenenfalls erneute Tests in die Bewertung. Auch eine unveränderte Funktion kann betroffen sein. Umgekehrt begründet ein Update nicht automatisch die Wiederholung aller jemals ausgeführten Tests.

Die Microsoft-Dokumentation beschreibt Testwerkzeuge und wiederholbare Geschäftsabläufe. Ein technisch erfolgreich automatisierter Lauf muss dennoch die richtige Erwartung prüfen. Bewahren Sie deshalb Testdaten, Parameter und Ergebnisvergleich kontrolliert auf. Vorschaufunktionen, etwa ausdrücklich als Preview gekennzeichnete Qualitätszuordnungen, dürfen nicht stillschweigend als produktiv vorhandene Kontrolle in Ihre Freigabebegründung einfließen.

Quellen: [7] [3] [9]

10. Was Ihr Team vor der Validierung zusammentragen sollte

QA sollte die Bedeutung der Qualitätsentscheidungen und unzulässigen Verwendungen festlegen. Lager und Produktion zeigen die realen Buchungs- und Ausnahmewege. IT und Implementierungspartner erklären Konfiguration, Integration und Betrieb. Finance bewertet angrenzende kaufmännische Auswirkungen. Diese Beiträge müssen nicht in getrennten Projekten entstehen, sollten aber auf denselben abgegrenzten Prozess und Systemstand verweisen.

Der Aufwand steigt insbesondere bei mehreren Gesellschaften, abweichenden Lagerkonzepten, unklaren Altparametern, individuellen Erweiterungen und fehlender Testumgebung. Eine belastbare Vorbereitung beginnt mit einem kritischen Materialfluss einschließlich seiner Ausnahmen. Danach lässt sich entscheiden, welche Varianten eigene Tests benötigen und welche durch nachvollziehbare gemeinsame Evidenz abgedeckt sind.

• Anwendungen, Build, Featurestand, Hosting und Verantwortliche dokumentiert.
• Prüfmenge, Sperrmenge und zulässige Folgeaktionen getrennt definiert.
• Automatische Auslöser und manuelle Ersatzwege erfasst.
• Chargen-, Gesellschafts- und Lagerdimensionen in Testdaten eindeutig.
• Qualitätsentscheidung, Bericht und gegebenenfalls QP-Bezug zugeordnet.
• Rollen und technische Schreibwege mit negativen Fällen geprüft.
• Schnittstellenfehler und Wiederanlauf anhand des Zielzustands bewertet.
• Befunde, Restlücken, Betriebsverfahren und Updateverantwortung entschieden.

Quellen: [1] [5] [9]