Am Freitagabend zeigt das alte ERP 1.240 offene Kundenaufträge. Das Projekt exportiert alle Belege und will sie am Wochenende ins neue System laden. Beim ersten Abgleich wird jedoch klar: Manche Aufträge sind nur noch wegen einer Restposition offen, andere wurden bereits geliefert, aber noch nicht fakturiert, und bei weiteren ändern sich Mengen bis kurz vor der Umstellung.
Offene Aufträge zu migrieren heißt deshalb nicht, alle Belege mit einem offenen Status zu kopieren. Das Projekt muss je Position bestimmen, welche Verpflichtung zum Stichtag noch im neuen ERP weiterbearbeitet werden soll. Erst daraus entstehen Auswahl, Restmengen, Werte, Abhängigkeiten und ein belastbarer Übergang zwischen Alt- und Zielsystem.
Offene Aufträge migrieren: Was gilt überhaupt als offen?
Ein Kundenauftrag besteht meist aus einem Belegkopf und mehreren Positionen. Eine Position kann vollständig offen, teilweise geliefert, vollständig geliefert, teilweise fakturiert, gesperrt oder storniert sein. Der Gesamtbeleg bleibt im Altsystem möglicherweise so lange „offen“, bis jede Teilaktivität abgeschlossen ist.
Für die Migration reicht der Belegstatus daher nicht aus. Die fachliche Auswahl muss beantworten:
- Welche Menge ist zum Stichtag noch zu liefern?
- Welche Menge wurde geliefert, aber noch nicht abgerechnet?
- Welche Position wurde fachlich erledigt, obwohl der technische Status offen blieb?
- Welche Aufträge sollen im alten System abgeschlossen und welche im neuen fortgeführt werden?
- Welche bereits erfüllte Historie wird für Auskunft oder Nachweis benötigt, aber nicht als aktiver Auftrag neu angelegt?
„Offen“ ist damit keine einzelne Spalte. Es ist eine aus Status, Mengen, Folgebelegen und Cut-over-Entscheidung abgeleitete Restverpflichtung.
Die wichtigste Regel: Nicht den alten Beleg, sondern die Restarbeit übertragen
Bei einer vollständig offenen Position können Auftragsmenge und offene Menge übereinstimmen. Bei einer teilweise gelieferten Position wäre die vollständige Auftragsmenge im Ziel jedoch falsch. Das neue ERP könnte sonst bereits erfüllte Mengen erneut disponieren oder liefern.
Ein vereinfachtes Beispiel:
- Bestellt wurden 100 Stück.
- 60 Stück wurden im Altsystem geliefert.
- 40 Stück bleiben zum Stichtag offen.
Wenn die Position im neuen ERP weitergeführt wird, braucht das Ziel in der Regel die noch zu bearbeitenden 40 Stück und einen verständlichen Bezug zum alten Vorgang. Wie das konkrete ERP Teilmengen, Preise und Vorgängerbezüge unterstützt, muss mit dem Implementierungspartner geklärt werden.
Die Migrationsregel darf deshalb nicht allgemein „Status ist offen“ lauten. Sie muss auf Positionsebene erklären, aus welchen Mengen und Folgebelegen der zu übertragende Rest entsteht.
Sieben Entscheidungen vor der ersten Testdatei
1. Welcher fachliche Stichtag gilt?
Der Stichtag trennt die Bearbeitung im alten und im neuen System. Er muss genauer sein als ein Kalenderdatum. Entscheidend ist, bis zu welchem Buchungs- oder Verarbeitungsschritt Änderungen im Altsystem noch zulässig sind und ab wann neue Vorgänge im Ziel entstehen.
Ein Auftrag kann vor dem Stichtag angelegt, danach aber noch geändert oder teilweise geliefert werden. Auswahl und Restmengen müssen deshalb aus demselben konsistenten Stand stammen.
2. Welche Auftragsarten gehören in den Umfang?
Standardaufträge, Rahmenaufträge, Retouren, Serviceaufträge oder kundenspezifische Belegarten können im Ziel unterschiedliche Objekte benötigen. Nicht jede historische Auftragsart lässt sich unverändert abbilden. Das Projekt legt fest, welche Arten aktiv fortgeführt, vereinfacht neu angelegt, im Altsystem abgeschlossen oder nur lesend bereitgehalten werden.
3. Was passiert mit teilweise erfüllten Positionen?
Hier müssen Liefer- und Rechnungsfortschritt gemeinsam betrachtet werden. Eine Position kann logistisch erledigt, finanziell aber noch offen sein. Dann ist möglicherweise kein neuer Lieferauftrag nötig, wohl aber ein offener Abrechnungs- oder Buchhaltungsprozess.
Die Entscheidung gehört deshalb nicht allein in die Vertriebsabteilung. Je nach Prozess müssen Logistik, Faktura und Finanzwesen denselben Übergang bestätigen.
4. Welche Preise und Konditionen gelten weiter?
Das Zielsystem kann einen migrierten Auftrag neu bepreisen. Das ist nicht automatisch erwünscht: Der Kunde hat möglicherweise einen verbindlichen alten Preis, Rabatt oder Frachtwert. Umgekehrt kann das Ziel-ERP historische Konditionslogik nicht identisch abbilden.
Für jede relevante Auftragsart ist zu entscheiden, ob verbleibende Werte aus dem Altsystem übernommen, im Ziel neu ermittelt oder als gesonderter Migrationswert behandelt werden. Eine technisch zulässige Lösung muss anschließend in einem bekannten Auftragsfall fachlich geprüft werden.
5. Welche Referenz bleibt zum Altbeleg erhalten?
Der neue Auftrag erhält möglicherweise eine neue Belegnummer. Kundenservice, Versand und Buchhaltung müssen trotzdem erkennen können, auf welchen alten Auftrag er zurückgeht. Deshalb braucht das Mapping einen eindeutigen Altbezug – etwa in einem vorgesehenen Referenzfeld oder einer dokumentierten Zuordnungstabelle.
Der Bezug muss auch für Positionen eindeutig bleiben. Sonst lässt sich später kaum erklären, welche Restmenge aus welcher alten Position entstanden ist.
6. Welche Änderungen sind während des Cut-over-Fensters erlaubt?
Solange das alte ERP weiterläuft, können neue Aufträge, Mengenänderungen, Lieferungen oder Stornierungen entstehen. Das Projekt benötigt deshalb entweder eine klare Buchungssperre, einen erneut ausgeführten Delta-Lauf oder einen kontrollierten Übergabeprozess für die letzten Änderungen.
Ein Delta ist die seit einem festgelegten Stand hinzugekommene oder veränderte Datenmenge. Es genügt nicht, nur neu angelegte Belege zu finden. Auch Änderungen und Löschungen beziehungsweise Stornierungen müssen berücksichtigt werden.
7. Wer bestätigt die Restverpflichtung?
Die technische Migration kann offene Mengen berechnen. Ob ein alter Auftrag tatsächlich weitergeführt werden soll, ist eine fachliche Entscheidung. Für Grenzfälle braucht es eine benannte Verantwortung und eine Klärungsliste, nicht einen stillen Ausschluss aus der Importdatei.
Diese Vorgängerdaten müssen zuerst im Ziel vorhanden sein
Ein offener Auftrag steht nicht allein. Er verweist mindestens auf Kunden, Produkte beziehungsweise Materialien, Organisationseinheiten, Einheiten und häufig weitere Werte wie Zahlungs- oder Lieferbedingungen.
Vor dem Auftragsimport ist deshalb zu prüfen:
- Der Kunde ist mit der benötigten Vertriebs- und Partnerstruktur angelegt.
- Alle noch offenen Auftragspositionen referenzieren gültige Materialien oder Leistungen.
- Vertriebsorganisationen, Werke, Lagerorte und Versandstellen sind im Ziel konfiguriert.
- Einheiten, Währungen, Steuerlogik und Zahlungsbedingungen sind zugeordnet.
- Benötigte Mitarbeiter, Ansprechpartner oder Preislisten stehen zur Verfügung.
Fehlt ein Vorgängerobjekt, ist der Auftragsfehler nicht durch eine Korrektur am Auftrag lösbar. Die Abhängigkeit muss in der Reihenfolge der Datenobjekte berücksichtigt werden. Wie diese Priorisierung aufgebaut wird, zeigt der Beitrag Welche Daten zuerst migrieren?
Eine belastbare Auswahlregel auf Positionsebene
Die Quellanalyse sollte Kopf, Positionen und relevante Folgebelege gemeinsam betrachten. Für jede Position entsteht ein nachvollziehbarer Auswahlstatus, beispielsweise:
- vollständig offen und zu übernehmen,
- teilweise erfüllt und mit bestätigter Restmenge zu übernehmen,
- logistisch erledigt, aber finanziell separat zu behandeln,
- fachlich storniert oder beendet und nicht als aktiver Auftrag zu übernehmen,
- klärungsbedürftig wegen widersprüchlichem Status oder Mengenstand.
Zu jedem Status gehört eine technische Bedingung und ein fachlicher Grund. Damit kann die Projektleitung erklären, warum aus 1.240 offenen Belegen vielleicht 870 Zielaufträge mit 2.430 Positionen entstehen – ohne die Differenz als vermeintlichen Datenverlust zu behandeln.
Wie eine wiederholbare Auftragsdatei entsteht
Die Transformation verbindet mehrere Informationsbereiche:
- Auftragskopf und Positionen werden über ihre eindeutigen Schlüssel verbunden.
- Lieferungen, Rechnungen, Stornierungen und Statusinformationen bestimmen den verbleibenden Bearbeitungsstand.
- Kunden- und Materialschlüssel werden auf bereits migrierte Zielschlüssel abgebildet.
- Auftragsarten, Organisationen, Einheiten und Konditionen werden nach freigegebenen Regeln übersetzt.
- Die alte Beleg- und Positionsreferenz bleibt im Ergebnis nachvollziehbar.
- Unklare Fälle werden in einer separaten Fehler- und Entscheidungsliste ausgegeben.
Diese Logik sollte nicht in einer einmal manuell bereinigten Excel-Datei verschwinden. Sie muss bei jedem Testlauf und beim finalen Stichtagsstand erneut ausführbar sein. Der Beitrag CSV für den ERP-Import umwandeln beschreibt diesen wiederholbaren Weg vom Rohstand zur Importdatei.
Der erste Test braucht echte Auftragsverläufe
Ein Test mit fünf vollständig offenen Standardaufträgen ist zu bequem. Er beweist nur den einfachsten Fall. Der ausgewählte Testbestand sollte die wichtigsten Übergangssituationen enthalten:
- einen vollständig offenen Auftrag mit mehreren Positionen,
- eine teilweise gelieferte Position,
- eine gelieferte, aber noch nicht vollständig fakturierte Position,
- einen Auftrag mit gesperrter oder stornierter Position,
- einen Fall mit kundenspezifischem Preis oder Rabatt,
- einen Auftrag mit kurz vor dem Stichtag geänderter Menge,
- und einen Beleg mit wichtiger Partner- oder Lieferadressabweichung.
Nach dem Import prüfen Key-User nicht nur, ob der Auftrag sichtbar ist. Sie führen den vorgesehenen Folgeprozess aus: Verfügbarkeit, Lieferung, Faktura oder die im Ziel geplante Fortführung. Nur so wird deutlich, ob Status, Mengen und Werte wirklich anschlussfähig sind.
Vier Abstimmungen belegen die Vollständigkeit
Beleg- und Positionsmengen
Quellbelege, ausgewählte Zielbelege, ausgeschlossene und ungeklärte Fälle müssen sich mengenmäßig erklären lassen. Dasselbe gilt für die Positionen.
Restmengen
Die Summe der zu migrierenden Restmengen wird je sinnvoller Gruppe mit dem Quellstand verglichen – etwa nach Auftragsart, Werk oder Material. Große Summen ersetzen dabei nicht die Prüfung einzelner kritischer Fälle.
Restwerte
Auftragswerte, Währungen und Konditionen werden in der vereinbarten Logik abgestimmt. Wenn das Ziel neu bewertet, muss die erwartete Differenz vorab beschrieben sein.
Prozessfähigkeit
Der Zielauftrag lässt sich in den vorgesehenen Folgeprozess übernehmen. Kunden, Materialien und Organisationen sind richtig referenziert; Sperren und Sonderfälle wirken wie beschlossen.
Die Verbindung dieser technischen und fachlichen Nachweise ist Teil der Datenvalidierung bei der ERP-Migration.
Typische Fehlversuche bei offenen Aufträgen
- Nur den Kopfstatus filtern: Unterschiedlich bearbeitete Positionen werden gemeinsam falsch eingestuft.
- Die ursprüngliche Menge übernehmen: Bereits erfüllte Mengen erscheinen im Ziel erneut als offen.
- Nur neu angelegte Belege als Delta betrachten: Mengenänderungen, Lieferungen und Stornierungen fehlen.
- Preise neu berechnen lassen, ohne die Wirkung zu prüfen: Der Zielauftrag weicht von der Kundenvereinbarung ab.
- Alle Historie als aktiven Auftrag anlegen: Das Zielsystem wird mit nicht fortzuführenden Vorgängen belastet.
- Ohne Altbezug migrieren: Kundenservice und Abstimmung verlieren die Verbindung zum bisherigen Vorgang.
Der Produktivlauf braucht eine geprobte Übergabegrenze
Vor dem Go-live müssen Extraktion, fachlicher Stichtag, Buchungssperre oder Delta, Ladefolge, Abstimmung und Freigabe in einem realistischen Zeitfenster geprobt werden. Dazu gehört auch die Frage, was passiert, wenn einzelne Aufträge im finalen Lauf abgewiesen werden.
Werden sie nachträglich manuell erfasst? Kann eine korrigierte Teilmenge erneut geladen werden? Bleibt das alte System für einen begrenzten Zeitraum lesbar? Die Antworten gehören in den ERP-Cut-over-Plan für die Datenmigration, nicht in eine spontane Entscheidung am Wochenende der Umstellung.
Offene Aufträge sind ein Übergabeprozess, keine statische Datei
Stammdaten lassen sich während der Testphase mehrfach aus einem bekannten Bestand aufbereiten. Offene Aufträge verändern sich dagegen durch das laufende Geschäft bis zur letzten zulässigen Buchung. Deshalb müssen fachliche Abgrenzung und technische Wiederholbarkeit besonders eng zusammenspielen.
Externe Unterstützung kann Kopf-, Positions- und Folgebeziehungen im Altsystem analysieren, Restmengen- und Auswahlregeln technisch umsetzen, die Importdatei wiederholbar erzeugen und Mengen sowie Werte für die Abnahme abstimmen. Das Unternehmen entscheidet, welche Verpflichtungen im neuen ERP fortgeführt werden und wie das operative Geschäft während der Umstellung begrenzt wird.
So werden nicht einfach 1.240 „offene“ Belege kopiert. Es wird nachweisbar genau die Arbeit übergeben, die am Stichtag noch erledigt werden muss.