Der Auftrag steht im System, die Ware steht im Lager: Kreditlimits in Automatisierungen
Die Auftragserfassung läuft automatisch, das ERP setzt den Auftrag wegen des Kreditlimits auf Sperre, und niemand im automatisierten Ablauf sieht es. Warum die Rückmeldung des Auftragsstatus wichtiger ist als eine erfolgreiche Anlage.
Dieser Beitrag wurde mit KI erstellt. Kennzeichnung gemäß Art. 50 EU AI Act. Verantwortlich für die Veröffentlichung: Sophera Consulting.
Sechs Tage bis zum Anruf
Ein Großhändler für Verbrauchsmaterial erfasst Kundenaufträge seit anderthalb Jahren automatisch. Bestellungen kommen per E-Mail, aus dem Shop und über EDI, ein Workflow legt daraus Aufträge im ERP an und verschickt eine Auftragsbestätigung. Die Fehlerquote ist niedrig, intern gilt der Ablauf als eines der gelungenen Projekte.
Im Frühjahr rief ein Kunde an und fragte nach vier Paletten, die er seit sechs Tagen erwartete. Der Auftrag stand im System, mit Nummer, mit allen Positionen. Er stand auf Kreditsperre, das Kreditlimit des Kunden war ausgeschöpft. Das ERP hatte den Auftrag beim Anlegen angenommen und beim Erzeugen des Lieferscheins angehalten. Gemeldet hat das niemand, weil in diesem Ablauf niemand mehr hinschaut.
Die Auftragsbestätigung war sechs Tage vorher rausgegangen.
Angelegt heißt nicht freigegeben
Der Workflow hat sauber gearbeitet. Er hat die Bestellung gelesen, die Positionen zugeordnet, den Auftrag angelegt und eine Auftragsnummer zurückbekommen. Als Erfolgskriterium galt genau das: Das ERP hat den Datensatz angenommen.
Das ist eine Aussage über den Schreibvorgang. Über den Vorgang im Vertrieb sagt sie nichts. Ein angelegter Auftrag kann freigegeben sein. Er kann genauso gut auf Kreditsperre stehen oder auf eine Preisfreigabe warten. Die Schnittstelle antwortet in allen Fällen gleich.
Wo die Prüfung greift, ist zwischen den Systemen unterschiedlich. Manche prüfen beim Speichern des Auftrags, andere erst beim Erzeugen des Lieferscheins, wieder andere bei der Kommissionierfreigabe. Wer beim Anlegen prüft, sieht die Sperre sofort. Prüft das System dagegen erst beim Lieferschein, sieht der Auftrag zwei Tage lang unauffällig aus.
Die Zahl ändert sich, während der Auftrag liegt
Ein Kreditlimit sieht im Stammdatensatz aus wie ein fester Betrag. Wirksam wird es gegen eine Rechnung, die sich täglich verschiebt. Dagegen laufen die offenen Posten, die erfassten und noch nicht gelieferten Aufträge, die gelieferten und noch nicht berechneten Lieferungen und je nach System auch Zahlungseingänge, die noch nicht verbucht sind.
Ein Auftrag, der am Montag innerhalb des Limits lag, liegt am Mittwoch darüber, weil zwei Rechnungen ins Zahlungsziel gelaufen sind oder weil in der Zwischenzeit drei weitere Aufträge desselben Kunden erfasst wurden. Ihre eigene Automatisierung erzeugt diesen Effekt mit, sobald sie viele kleine Aufträge schnell hintereinander anlegt.
Eine Prüfung zum Zeitpunkt der Erfassung trägt deshalb bis zur Erfassung. Was am Tag des Versands gilt, steht damit nicht fest.
Wer das Limit setzt, sitzt oft nicht im Haus
Bei kreditversicherten Lieferanten kommt das Limit vom Versicherer. Der kann es kürzen oder zurückziehen, ohne dass im eigenen Haus jemand etwas geändert hat. Am nächsten Morgen steht ein Kunde, der seit Jahren zuverlässig zahlt, mit einem deutlich kleineren Rahmen im System.
Eine Automatisierung, die das Limit einmal ausgelesen und in einer eigenen Tabelle abgelegt hat, rechnet ab diesem Tag mit einer Zahl, die es nicht mehr gibt.
Konzern, Einkaufsgemeinschaft, sechs Kundennummern
Die zweite Stelle, an der die Prüfung auseinanderfällt, ist die Zuordnung.
Ein Krankenhausträger bestellt über sechs Kundennummern, eine je Haus. Das Limit liegt beim Träger. Eine Prüfung je Kundennummer geht sechsmal durch, die Summe reißt den Rahmen. Dasselbe gilt für Filialisten und für Einkaufsgemeinschaften, bei denen die Rechnung an eine Zentralregulierung geht und die Ware an dreißig Standorte.
Welche Ebene das Limit trägt, steht im ERP. Ein Workflow, der auf der Ebene der Kundennummer arbeitet, weil dort die Bestellung ankommt, sieht diese Ebene nicht.
Vorkasse ist auch eine Sperre
Neben dem Limit steht die Zahlungsbedingung. Ein Kunde auf Vorkasse hat kein Limitproblem, sein Auftrag darf trotzdem nicht in die Kommissionierung, bevor Geld eingegangen ist. Dasselbe gilt für Kunden, die nach einer Mahnstufe auf Lieferstopp stehen.
Diese Kennzeichen sitzen in anderen Feldern als der Limitbetrag, häufig in einem anderen Reiter der Kundenstammdaten. Eine Prüfung, die nur den Betrag ansieht, lässt sie durch. Im Ergebnis geht Ware an einen Kunden raus, bei dem die Buchhaltung seit vier Wochen mahnt.
Der bequemste Fehler
Es gibt einen Weg, das Thema loszuwerden, und er wird häufiger gegangen, als in Projektdokumentationen steht.
In vielen Systemen lässt sich ein Auftrag mit gesetztem Freigabekennzeichen anlegen. Wer das im Mapping einträgt, hat keine gesperrten Aufträge mehr. Die Prüfung findet dann für keinen Kunden mehr statt, auch nicht für den, bei dem sie nötig wäre.
Dahinter steht in den meisten Fällen keine Entscheidung. Das Kennzeichen stammt aus der Testphase, in der die Sperren gestört haben, und ist danach stehen geblieben.
Was der Wiederholungslauf anrichtet
Kennt der Workflow die Sperre nicht als eigenen Zustand, behandelt er sie beim nächsten Durchlauf häufig als Fehler. Der übliche Reflex ist ein Wiederholungslauf, und der legt denselben Auftrag noch einmal an.
Danach stehen zwei gesperrte Aufträge über dieselbe Ware im System, die gemeinsam doppelt gegen das Limit laufen. Wird einer davon später freigegeben und der andere übersehen, geht die Lieferung zweimal raus.
Der Sperrgrund gehört in die Meldung
Ein Auftrag steht selten nur wegen des Limits. Er kann wegen einer überfälligen Rechnung stehen, wegen eines gesperrten Kunden oder wegen einer manuellen Sperre, die jemand aus dem Vertrieb gesetzt hat. Die Systeme führen dafür getrennte Kennzeichen, und die Zuständigkeit unterscheidet sich: Über den Rahmen entscheidet die Buchhaltung, über eine Vertriebssperre der Außendienst.
Eine Meldung, die nur sagt, dass der Auftrag gesperrt ist, landet deshalb zuerst bei der falschen Person und wird weitergereicht. Bei zwei Aufträgen fällt das nicht auf. Bei vierzig im Monat ist es der Grund, warum die Liste stehen bleibt.
Die Bestätigung ist der eigentliche Schaden
Ein gesperrter Auftrag ist ein normaler Vorgang. Die Sperre hat getan, wofür sie da ist, das Risiko wurde abgefangen, jemand muss entscheiden.
Der Schaden entsteht durch die Auftragsbestätigung, die vorher rausgeht. Sie ist kaufmännisch die Annahme der Bestellung. Der Kunde disponiert danach, in der Klinik hängen daran Termine auf Station, im Handel hängt daran die eigene Zusage an den nächsten Abnehmer. Eine Lieferung, die nach einem Anruf sechs Tage später anläuft, ist etwas anderes als eine Rückmeldung am selben Tag, dass der Rahmen ausgeschöpft ist.
Wer am Tag der Bestellung erfährt, dass eine Zahlung offen ist, kann zahlen. Wer es am sechsten Tag erfährt, hat sechs Tage verloren.
In der Auftragserfassung war dieser Fall früher Alltag. Die Sperre stand am Bildschirm, jemand ist zur Buchhaltung gegangen, und der Kunde bekam am selben Vormittag Bescheid. Das hat nie jemand aufgeschrieben, es war das, was die Sachbearbeitung macht, wenn ein Feld rot wird. Die Automatisierung hat die Auftragsanlage übernommen und das rote Feld nicht.
Was wir stattdessen bauen
Drei Ergebnisse statt zwei: angelegt und freigegeben, angelegt und gesperrt mit Grund, abgelehnt. Der mittlere Zustand braucht eine eigene Behandlung, sonst verschwindet er.
Den Status zurücklesen, statt ihn aus dem Statuscode der Schnittstelle zu schließen. Nach dem Anlegen den Auftrag erneut abrufen und das Sperrkennzeichen auswerten.
Die Bewertung dem ERP überlassen. Limit und offene Posten selbst auszulesen und die Differenz zu rechnen erzeugt eine zweite Zahl, die von der ersten abweicht, sobald sich die Definition der einbezogenen Belege unterscheidet.
Den Text der Bestätigung an den Zustand koppeln. Für gesperrte Aufträge geht eine Eingangsbestätigung raus, keine Lieferzusage.
Einen benannten Empfänger für gesperrte Aufträge, mit Frist. Ein Bericht, den jemand aufrufen kann, reicht nicht. Die Meldung muss zu einer Person gehen, die entscheiden darf.
Vor dem Versand erneut prüfen, weil sich das Bild seit der Erfassung verschoben hat.
Kein pauschales Freigabekennzeichen im Mapping. Soll ein Auftrag ohne Prüfung angelegt werden, dann für einen definierten Kundenkreis und nachlesbar.
Womit wir anfangen
Wenn wir in einen bestehenden Auftragsprozess schauen, beginnen wir mit einer Auswertung: Wie viele Aufträge aus den letzten drei Monaten wurden angelegt und haben nie einen Lieferschein bekommen?
Diese Liste erzeugt jedes ERP mit zwei Filtern. Sie ist in der Regel länger als erwartet, und neben den Kreditsperren stehen dort Preisfreigaben, fehlende Artikel und Aufträge, die jemand angelegt und dann vergessen hat.
Damit lässt sich beantworten, ob sich der Aufwand lohnt, bevor jemand einen Workflow anfasst.