Yaveon 365 validieren: Von der Prüfung zur zulässigen Chargenverwendung

1. Yaveon 365 und ProBatch: Den tatsächlichen Appverbund festhalten

Yaveon bezeichnet Yaveon 365 als Appfamilie auf Microsoft Dynamics 365 Business Central. Sie bündelt die früheren Angebote ProBatch und ProE-SCM. Daraus folgt keine Funktionsgleichheit jeder alten ProBatch-Installation mit einer heutigen Kombination. Für die Validierung benötigen Sie den konkreten Business-Central-Stand, installierte Apps und Versionen, kundeneigene Erweiterungen, Betriebsform und verwendete Schnittstellen.

Die öffentliche Hilfe verwendet sowohl ProBatch- als auch Yaveon-365-Pfade. Viele Seiten nennen keine genaue Buildnummer. Dokumentieren Sie deshalb, welche Anleitung zu Ihrer Umgebung gehört. Quality Assurance setzt laut Hersteller Lot Management voraus; weitere Fertigungs-, Lager- und Scannerfunktionen haben eigene Appabhängigkeiten. Ein vorhandenes ERP-Grundsystem belegt diese Zusatzfunktionen nicht.

Dieser Leitfaden betrachtet den Einsatz in der Herstellung von Humanarzneimitteln unter EU-GMP. Die Kommission führt Annex 11 in der Revision von Januar 2011. Ob eine konkrete ERP-Funktion GMP-relevant ist, ergibt sich aus ihrem tatsächlichen Einfluss auf Produktqualität, Patientensicherheit und Datenintegrität. Lebensmittel-, Kosmetik-, Medizinprodukte- und US-Anforderungen benötigen eine eigene Zuordnung.

Quellen: [1] [2] [9] [10]

2. Vier Zustände, vier verschiedene Aussagen

Beginnen Sie mit der betrieblichen Frage: Welche Person darf welches Material auf welcher Grundlage verwenden? Daraus folgen Anforderungen an Daten, Entscheidungen und Sperren. Eine allgemeine Aussage wie „Chargen sind rückverfolgbar“ reicht für den kritischen Übergang von Prüfung zu Produktion oder Versand nicht.

Der Hersteller bietet ein Compliance Kit mit Vorlagen an. Seine konkrete Vertrags- und Versionsabdeckung muss mit dem eigenen Prozess abgeglichen werden. Geeignete Lieferantenbelege können Prüfungen stützen; offene Konfigurationen, eigene Erweiterungen und Schnittstellen bleiben sichtbar. Annex 11 verlangt einen begründeten, risikobasierten Nachweis des vorgesehenen Einsatzes.

Die folgende Arbeitshilfe verhindert, dass ein grüner Status das falsche Objekt bestätigt. Ergänzen Sie pro Zeile die tatsächlich wirksame Regel, Entscheidungsbefugnis und verknüpfte Evidenz.

Quellen: [1] [3] [5] [7] [10]

3. Prüfplanwahl, Ergebniserfassung und Abschluss gezielt prüfen

Die Yaveon-Hilfe beschreibt eine Auswahlhierarchie für Prüfpläne: zuerst die Geschäftsbeziehung, danach den Artikel und anschließend eine nicht eingeschränkte Zuordnung. Bei gleichrangigen Treffern wird die höchste Prüfplannummer genannt; bei der prozessorientierten Anlage ist zudem der zertifizierte Plan mit seiner Version relevant. Prüfen Sie konkurrierende Zuordnungen anhand vorab festgelegter Sollpläne, statt nur den ausgewählten Namen zu dokumentieren.

Ein Prüfauftrag im Status Released ist zur Bearbeitung freigegeben. Inspection completed bedeutet, dass die Istwerte erfasst wurden. Erst Finished bezeichnet den ausgeführten Abschluss; der Auftrag ist dann laut Hilfe nicht mehr editierbar. Welche Automatik erste und letzte Werte auslösen, hängt von der Einrichtung ab. Testen Sie deshalb auch fehlende Werte und einen unberechtigten Abschlussversuch.

Bei einer erneuten Prüfung derselben Probe beschreibt die Hilfe zusätzliche Ergebniszeilen, bei denen beide Istwerte in die Berechnung eingehen. Eine neue Probe und ein neuer Re-Inspection Order sind davon zu unterscheiden. Legen Sie fachlich fest, wann welche Variante zulässig ist. Die technische Möglichkeit rechtfertigt weder das Überschreiben eines unerwünschten Ergebnisses noch dessen unbegründeten Ausschluss.

Quellen: [3] [10] [11]

4. Statusänderung und zulässige Verwendung verbinden

Yaveon dokumentiert sowohl eine Verwendungsentscheidung aus dem abgeschlossenen Prüfauftrag als auch automatische Änderungen des Artikelverfolgungsstatus. Die Automatik berücksichtigt unter anderem auslösendes Ereignis, Artikel beziehungsweise Qualitätsgruppe, bisherigen Status und Ergebnis. Beispielregeln setzen bei Anlage IN_QC und nach Abschluss abhängig vom Ergebnis RELEASED oder BLOCKED.

Diese Namen sind kein eigenständiger Freigabenachweis. Ihr Prozess muss festlegen, welche Aktion der jeweilige Status erlaubt: Entnahme, Umlagerung, Fertigungsverbrauch oder Versand. Prüfen Sie die tatsächlich verwendeten Dialoge, Rollen und Schnittstellen. Auch eine wirksame Buchungssperre beweist keine physische Trennung im Lager; dafür braucht es einen passenden Betriebsablauf.

Eine Materialverwendungsentscheidung ist außerdem von der Zertifizierung einer Fertigarzneimittelcharge durch die sachkundige Person zu unterscheiden. Annex 16 beschreibt diese Zertifizierung und die anschließende Überführung in verkaufsfähigen Bestand im geregelten Freigabeprozess. Ein ERP-Status ersetzt diese Verantwortung nicht. Stellen Sie bei relevanten Abläufen fest, welche Entscheidung in welchem System dokumentiert wird.

Quellen: [3] [4] [10] [12]

5. Prüfbeispiel: 160 kg vorhanden, aber nur 100 kg verwendbar

Das folgende Beispiel ist ein eigener illustrativer Prüfentwurf, kein Kundenfall und kein ausgeführter Produkttest. Im isolierten Testbestand liegen vom gleichen Artikel 100 kg in Charge QA-A und 60 kg in QA-B. Beide starten mit IN_QC. Das vorab genehmigte Soll erlaubt Versand ausschließlich mit RELEASED und über den festgelegten QA-Entscheidungsweg. Ein Auftrag verlangt 120 kg.

Die eigenen Statusnamen und Regeln dienen nur diesem Beispiel. Teilversand ist nicht automatisch erlaubt, sondern würde einen separat autorisierten Ablauf benötigen. Als unabhängige Referenz werden vor dem Test die Chargen, Mengen, Prüfplanversionen und erwarteten Entscheidungen festgehalten. Die Testreihe führt keine tatsächlichen Lagerbuchungen außerhalb des Testbestands aus.

Quellen: [3] [4] [10]

6. Wirksame Fertigungsvorschriften statt nur eines Default-Kennzeichens prüfen

Eine Yaveon-Fertigungsvorschrift verbindet Stückliste und Arbeitsplan. Die Hilfe nennt Version, Startdatum, Losgrößenbereich und Lagerort als Auswahlmerkmale. Bei überlappenden Losgrößenbereichen wird die höchste Versionsnummer genannt. Damit kann eine einfache Änderung am Gültigkeitsbereich Auswirkungen auf Aufträge haben, deren Artikelstamm unverändert bleibt.

Der Status Certified erlaubt die Nutzung der Vorschrift; die Zertifizierung kann durch eine elektronische Signatur abgesichert werden. Hier bezeichnet Certified einen Softwarezustand, keine behördliche Zertifizierung. Legen Sie Prüffälle knapp vor und ab dem Wirksamkeitsdatum sowie an Losgrößengrenzen an. Vergleichen Sie anschließend die tatsächlich in den Auftrag übernommenen Komponenten und Arbeitsschritte mit dem unabhängigen Soll.

Besonders relevant ist der Herstellerhinweis zu Default: Zugeordnete Stückliste und Arbeitsplan werden dadurch für bestimmte Business-Central-Standardfunktionen gesetzt. Die Auswahl der Vorschrift für einen Fertigungsauftrag wird damit jedoch nicht allein bestimmt. Prüfen Sie auch Vererbung von Status und Verfallsdatum, soweit diese Funktionen den eigenen Prozess beeinflussen.

Quellen: [5] [10] [11]

7. Signaturregeln und Anforderungsdatenstand zusammen bewerten

Elektronische Signaturregeln beziehen sich auf Aktionen und Bedingungen. Welche Aktionen verfügbar sind, hängt laut Hilfe von installierten und lizenzierten Apps ab. Die Regel legt Signierende beziehungsweise Gruppen und die Bedeutung fest. Ihre bloße Existenz genügt nicht: Prüfen Sie Aktivierung, Bedingung, Berechtigung und den tatsächlich auslösenden Prozessschritt.

Zwei hinterlegte Personen bedeuten nicht automatisch zwei erforderliche Signaturen. Die Hilfe unterscheidet über Signatures no.: Derselbe Wert bietet alternative Signierende; unterschiedliche Werte verlangen mehrere Signaturen. Ein wirksames Vieraugenprinzip braucht zusätzlich eine Regelung für zulässige Personen und Rollen. Testen Sie sowohl eine fehlende zweite Signatur als auch den Versuch einer unzulässigen Person.

Das Herstellerbeispiel zu Fertigungsauftragskomponenten zeigt eine weitere Grenze: Show document data stellt den Inhalt zum Anforderungszeitpunkt dar; das Quelldokument kann inzwischen geändert worden sein. Definieren Sie, wie die spätere Entscheidung an den richtigen Stand gebunden bleibt. Ein eigener Negativtest ändert die Quelle kontrolliert nach der Anforderung und prüft, ob der vorgesehene Entscheidungsweg dies korrekt behandelt. Eine automatische Invalidierung jeder Änderung wird damit nicht behauptet.

Quellen: [6] [7] [10]

8. Scannerkorrekturen bis in die Artikelverfolgung verfolgen

Quality Scanning benötigt für die genannten Produktionsdialoge zusätzlich Manufacturing Scanning, für den Wareneingang Warehouse Scanning. Die Hilfe beschreibt außerdem eine Benutzerqualifikation für die Istwerterfassung des zugewiesenen Merkmals. Erfassen Sie diese Abhängigkeiten im Scope; eine allgemeine Scanneranbindung ist kein Nachweis dieses konkreten Verhaltens.

Beim Erstellen eines Prüfauftrags werden registrierte Chargen- beziehungsweise Seriennummern und Mengen bereits in die Artikelverfolgung von Business Central übertragen, bevor der Wareneingang gebucht wird. Laut Hersteller passen spätere Änderungen oder Löschungen der Scannerregistrierung diese gespeicherten Daten nicht automatisch an. Damit entsteht ein gezielter Prüffall für die Korrekturstrecke.

Vergleichen Sie in einem kontrollierten Test Scannerregistrierung, Artikelverfolgung und Prüfauftrag vor und nach einer Mengen- oder Chargenkorrektur. Die Korrekturanweisung muss Voraussetzungen, Berechtigungen und erhaltene Nachweise festlegen. Ungeprüfte Löschschritte im produktiven Bestand sind daraus nicht abzuleiten. Maßgeblich ist, ob die betroffenen Objekte anschließend nachvollziehbar zur genehmigten Sollzuordnung passen.

Quellen: [8] [10] [11]

9. Änderungen, historische Nachweise und Betrieb gemeinsam planen

Eine neue Prüfplanversion, geänderte Statusregel oder zusätzliche Signaturbedingung kann den Prozess ebenso verändern wie ein Appupdate. Bewerten Sie die Auswirkungen auf bereits laufende Aufträge, vorhandene Ergebnisse und verbundene Datenwege. Entscheiden Sie nachvollziehbar, welche Belege weiter gelten und welche gezielten Prüfungen nötig sind. Auch unveränderte Funktionen können betroffen sein.

Für historische Entscheidungen müssen der damals verwendete Vorgabenstand und die relevanten Ergebnisse verständlich bleiben. Bestimmen Sie deshalb, wo Prüfauftrag, Wiederholungsbefunde, Statuswechsel, Signaturanforderung und zugehöriger Datenstand aufbewahrt werden. Eine aktuelle Stammdatenseite allein erklärt nicht zwingend eine alte Entscheidung. Umfang und Dauer der Aufbewahrung folgen den einschlägigen Aufzeichnungstypen und dem Prozess.

Berücksichtigen Sie außerdem Rollenwechsel, Störungen und den späteren Datenexport. Der Betriebsnachweis sollte zeigen, wie ein unterbrochener Vorgang erkannt, bewertet und kontrolliert fortgesetzt wird. Annex 11 behandelt Änderungen, regelmäßige Bewertung, Zugriff, Vorfälle und Archivierung; daraus ergibt sich kein universelles Intervall und kein pauschales Wiederholen sämtlicher Tests.

Quellen: [3] [7] [10] [11]

10. Vorbereitung und Mitwirkung im KMU

Der Aufwand hängt vor allem von unterschiedlichen Prüfwegen, Sonderregeln, eigenen Erweiterungen und Datenübergängen ab. Eine einzige Artikelgruppe mit mehreren Ausnahmewegen kann mehr Klärung benötigen als viele gleichartig verarbeitete Artikel. Stellen Sie die Varianten vor der Testplanung zusammen, einschließlich tatsächlicher Fehler- und Korrekturpfade.

QA definiert Bewertung, Entscheidungsbefugnisse und fachliche Ausnahmen. Produktion und Lager liefern reale Arbeitswege sowie unabhängige Sollvorgaben. IT beziehungsweise der Implementierungspartner legt Appstände, Konfigurationen und Schnittstellen offen. Der System Owner führt diese Informationen mit Lieferantenunterlagen, Betriebsverfahren und offenen Befunden zusammen. Daraus wird eine prüfbare Entscheidungsgrundlage statt einer bloßen Sammlung von Screenshots.

• Business-Central-Version, Yaveon-Apps, Lizenzen, Erweiterungen und Betriebsform erfassen.
• Repräsentative Artikel-, Prüfplan-, Chargen- und Fertigungsvorschriftenvarianten auswählen.
• Für jeden Status die erlaubte Handlung und verantwortliche Entscheidung festlegen.
• Planwahl, Abschluss, Wiederholungsbefund und tatsächliche Buchung unabhängig prüfen.
• Signaturbedingungen, UND-/ODER-Logik und Anforderungsdatenstand nachvollziehen.
• Scannerkorrekturen und weitere Schnittstellen bis zum Zielobjekt abgleichen.
• Historische Nachweise, Zugriff, Export und Änderungsbewertung im Betrieb regeln.
• Offene Abweichungen mit Auswirkung, Maßnahme und begründeter Abschlussentscheidung dokumentieren.

Quellen: [10] [11] [1]