ERPNext blockiert rückdatierte Chargenbuchung nach Inventur?

Eine Versionsregel statt eines beliebigen Datumsfehlers

Ein Originalbericht diskutiert diese Sperre beim Wechsel innerhalb der ERPNext-15-Reihe. Im offiziellen Repository ist die entsprechende Validierungsänderung für spätere Bestandsabgleiche dokumentiert und zusammengeführt. Q1 Q2 Stock Reconciliation stellt einen Bestand zu einem bestimmten Zeitpunkt her; Artikel, Lagerort und gegebenenfalls Chargen- beziehungsweise Serienbezug sind dafür wesentlich. Q3

Die konkrete Wirkung hängt vom installierten Code und den betroffenen Belegen ab. Eine Fehlermeldung nach einem Update ist deshalb nicht automatisch eine beschädigte Datenbank oder ein Anlass, historische Bestandsabgleiche zu löschen.

Die blockierende Beziehung nachvollziehen

1. Version und Meldung festhalten. Notiere ERPNext-, Frappe- und relevante Appversionen sowie den vollständigen geschwärzten Fehler. Prüfe, ob die Meldung eine konkrete spätere Stock Reconciliation nennt.
2. Belegzeitlinie erstellen. Ordne den geplanten Beleg und nachfolgende Bestandsabgleiche nach Buchungsdatum und Uhrzeit. Erstellungszeit und fachlicher Buchungszeitpunkt können verschieden sein. Verwende die betroffenen IDs, nicht nur Belegnamen aus einer Erinnerung.
3. Geltungsbereich vergleichen. Stimmen Artikel, Lager, Charge oder Seriennummer tatsächlich überein? Prüfe, ob der spätere Abgleich alle oder ausgewählte Chargen betrifft. Eine ähnliche Meldung für ein anderes Lager ist kein ausreichender Gegenbeweis.
4. In einer Kopie reproduzieren. Nutze einen konsistenten Teststand und einen minimalen Fall mit derselben zeitlichen Reihenfolge. Vergleiche bei einem geplanten Upgrade den bisherigen und vorgesehenen Versionsstand. So wird eine geänderte Validierung von einer abweichenden Belegkonfiguration getrennt.
5. Korrekturweg fachlich freigeben. Lege den zuständigen Bestands- und Prozessverantwortlichen vor, welche Belege betroffen sind und welche Ergebnisse erwartet werden. Jede Storno- oder Neubuchungsfolge muss deren Abhängigkeiten berücksichtigen.

Was eine technische Reparatur leisten muss

Das Ziel ist ein nachvollziehbarer, konsistenter Bestand samt korrekter Belegkette. Eine entfernte Validierung oder direkte SQL-Änderung kann zwar eine Fehlermeldung verschwinden lassen, liefert diesen Nachweis aber nicht. Prüfe den vorgesehenen Weg zuerst im Testbestand und vergleiche die betroffenen Lagerberichte vor und nach der Korrektur.

Häufige Fragen

Soll ich die spätere Inventur einfach stornieren?

Nicht ohne Prüfung abhängiger Vorgänge und fachliche Freigabe. Der sichtbare Sperrhinweis ist nur der Anfang der betroffenen Belegkette.

Was ist für die Übergabe sinnvoll?

Versionsliste, anonymisierte Beleg-IDs, Buchungszeiten, Lager-, Artikel- und Chargenbezug sowie der kleinste reproduzierbare Ablauf. Damit lässt sich prüfen, ob das dokumentierte Verhalten für deinen konkreten Stand zutrifft.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0524 mit KAN KAI WORKS besprechen.