Auftragserfassung automatisieren: Aus jeder Bestellung wird ein geprüfter Auftrag im ERP

Was bedeutet Auftragserfassung automatisieren?

Auftragserfassung automatisieren bedeutet, dass eine Bestellung ohne Abtippen zum Auftrag im ERP wird und nur Abweichungen bei Menschen landen. Das ERP bleibt das führende System. Die Automatisierung sitzt davor: Sie liest die Bestellung, prüft sie und übergibt sie über die Schnittstelle des ERP.

Die Strecke hat vier Teile. Der Eingang klärt Kanal und Format. Die Erkennung holt die Daten heraus. Die Prüfung vergleicht Kunde, Artikel, Preis, Menge und Termin mit Ihren Daten. Die Übergabe legt den Auftrag an und schickt die Bestätigung. Die meiste Arbeit steckt in der Prüfung, nicht in der Erkennung.

Erfassen ist nicht Entscheiden. Ob ein Auftrag mit Sonderpreis angenommen wird, entscheidet weiterhin Ihr Team. Die Automatisierung sorgt dafür, dass diese Entscheidung mit allen Fakten auf dem Tisch liegt.

Über welche Kanäle kommen Bestellungen, und wie wird jeder gelesen?

Jeder Eingangskanal braucht einen eigenen Leseweg, die Prüfung danach ist für alle gleich. EDI und XML liefern feste Felder. Mailtext, PDF und Excel müssen erst in Felder übersetzt werden.

UN/EDIFACT definiert die Bestellnachricht ORDERS als Nachricht mit Einzelheiten zu bestellten Waren oder Dienstleistungen unter Bedingungen, die Verkäufer und Käufer vereinbart haben. Sie ist branchenunabhängig. GS1 Germany beschreibt in seiner EDI-Anwendungsempfehlung zur Bestellung auf Basis von EANCOM 2002 einen Kopf-, Positions- und Summenteil. Im Positionsteil identifiziert die GTIN die Ware, daneben gibt es ein Feld für die Artikelnummer des Käufers.

openTRANS ist ein XML-Standard für Geschäftsdokumente. Entwickelt haben ihn das Fraunhofer IAO und die Universität Duisburg-Essen auf Basis des Katalogstandards BMEcat. Die Version 2.1 vom 02.10.2009 spezifiziert unter anderem ORDER, ORDERCHANGE und ORDERRESPONSE. Prozesse gibt sie ausdrücklich nicht vor: Welche Dokumente fließen, vereinbaren die Geschäftspartner.

Ein Standard ersetzt keine Vereinbarung. Bei EDI und openTRANS legen Sie mit jedem Partner fest, welche Felder er füllt, welche Codes er nutzt und ob er Änderungen als eigene Nachricht schickt.

Welche Prüfregeln braucht eine automatische Auftragserfassung?

Eine Bestellung gilt erst als erfasst, wenn Kunde, Artikel, Menge, Preis und Termin gegen Ihre Daten geprüft sind. Jede Regel hat ein festes Ergebnis: durchlassen, nach hinterlegter Regel umrechnen oder an Ihr Team geben. Die Tabelle zeigt die Regeln, die fast jede Strecke braucht.

Für die Artikelzuordnung bringen die ERP-Systeme eigene Tabellen mit. In SAP S/4HANA ist das die Kunden-Material-Info mit kundenspezifischen Bezeichnungen und Einstellungen zu einem Material. In Microsoft Dynamics 365 Business Central sind es Artikelreferenzen: Sie verknüpfen Ihren Artikel mit Beschreibung, Einheit oder Variante, die Ihr Kunde verwendet. Je vollständiger diese Tabellen gepflegt sind, desto weniger Bestellungen landen beim Team.

Dubletten brauchen eine eigene Regel. Eine Bestellung kommt per Mail und am nächsten Tag noch einmal als Erinnerung. Oder sie kommt per Mail und zusätzlich über das Portal. Das sicherste Merkmal ist die Bestellnummer des Kunden. Fehlt sie, vergleicht die Prüfung Positionen, Mengen und Datum und hält ähnliche Bestellungen an, statt zu raten.

Was kann KI bei unstrukturierten Bestellungen, und wo liegen die Grenzen?

KI übernimmt bei Mail und PDF das Lesen: Sie macht aus freiem Text Felder wie Kunde, Position, Menge und Termin. Ob diese Felder stimmen, entscheidet nicht die KI, sondern die Regelprüfung gegen Ihr ERP. Wo beides nicht eindeutig ist, entscheidet ein Mensch.

Dieses Muster beschreibt auch Microsoft für den Sales Order Agent in Business Central. Der Agent sucht Artikel zuerst über exakte Kennungen wie Artikelnummer, GTIN oder Artikelreferenz, danach über Merkmale und zuletzt unscharf. Er legt immer zuerst ein Verkaufsangebot an, weil Angebote Planung, Reservierungen und Verfügbarkeit nicht beeinflussen. Ausgehende Nachrichten geben benannte Nutzer vorher frei. Und Microsoft schreibt selbst, dass die Qualität der Artikeldaten über die Wirksamkeit entscheidet.

• Mehrdeutige Angaben wie „wie letztes Mal“ oder „das blaue Modell“ lassen sich nur mit Rückfrage sicher auflösen.
• Weitergeleitete Mails haben den falschen Absender. Microsoft beschreibt genau diesen Fall: Leitet jemand intern eine Bestellung weiter, muss ein Mensch den Kunden zuordnen.
• Schlechte Scans und handschriftliche Ergänzungen bleiben fehleranfällig und gehen immer in die Prüfung.
• Anhänge ohne Bestellung, etwa AGB oder Datenschutzhinweise, müssen erkannt und übergangen werden.
• Eine hohe Trefferwahrscheinlichkeit allein ist keine Freigabe. Durch läuft nur, was alle Regeln besteht.

Wir nennen keine Erkennungsquote. Wie viel ohne Eingriff durchläuft, hängt von Ihren Kunden, Formaten und Stammdaten ab. Wir messen es im Sprint auf Ihren echten Bestellungen.

Wie kommen Auftragsbestätigung und Abweichungsmeldung zurück?

Nach der Anlage geht die Auftragsbestätigung im Format des Eingangs an den Kunden, und jede Abweichung geht als eigene Meldung an den Innendienst. Bei EDI ist das die Nachricht ORDRSP. UN/EDIFACT definiert sie als Antwort des Verkäufers auf eine Bestellung oder eine Bestelländerung. Sie kann den Eingang bestätigen, die Annahme bestätigen oder eine Änderung vorschlagen. openTRANS sieht dafür ORDERRESPONSE vor. Bei Mail und PDF ist es die Bestätigung aus dem ERP als PDF.

Eine brauchbare Abweichungsmeldung an den Innendienst enthält diese Punkte:

• Kunde, Bestellnummer des Kunden und Eingangskanal, mit Link zum Original
• die betroffene Position und die verletzte Regel, etwa Bestellpreis unter Listenpreis
• den Vorschlag der Automatisierung, zum Beispiel den nächsten machbaren Liefertermin
• die möglichen Aktionen: übernehmen, ändern, beim Kunden nachfragen
• eine Frist, nach der der Fall an die nächste Stelle geht

Bestellung und Bestätigung sind Handelsbriefe. Nach § 257 HGB sind empfangene Handelsbriefe und Wiedergaben der abgesandten Handelsbriefe sechs Jahre aufzubewahren. Die Strecke legt Original, erkannte Daten und Bestätigung deshalb zusammen ab. Wie das zu Ihrer Archivierung passt, stimmen Sie mit Ihrer Steuerberatung ab.

Wie sieht der Ablauf je ERP aus?

Der Ablauf ist in jedem ERP gleich: prüfen, anlegen, bestätigen. Unterschiedlich sind die Schnittstellen. Die Beschreibung stützt sich auf die Schnittstellen-Dokumentation der Hersteller.

Für SAP S/4HANA ist das Ziel der Kundenauftrag. SAP dokumentiert das OData-API Sales Order (A2X) mit dem technischen Namen API_SALES_ORDER_SRV. Damit legen externe Systeme Kundenaufträge an, lesen, ändern und löschen sie. Ein zweites API, API_SALES_ORDER_SIMULATION_SRV, simuliert die Anlage. Es liefert Preisfindung, Verfügbarkeitsprüfung und Kreditlimitprüfung, ohne den Auftrag zu speichern. So läuft die Preisprüfung mit der echten SAP-Preisfindung, bevor etwas angelegt wird. Für EDI sieht SAP eingehende IDocs vom Typ ORDERS für Bestellung und Bestelländerung vor.

An Microsoft Dynamics 365 Business Central ist das Ziel der Verkaufsauftrag. Die API v2.0 bietet dafür die Ressource salesOrder zum Anlegen, Lesen, Ändern und Löschen. Das Feld externalDocumentNumber nimmt die Bestellnummer des Kunden auf und dient zugleich als Schlüssel für die Dublettenprüfung. requestedDeliveryDate trägt den Wunschtermin, die Positionen kommen über salesOrderLines. Der Status kennt Entwurf, In Prüfung und Offen.

Weitere ERP-Systeme wie SAP Business One, Sage, abas oder proALPHA folgen demselben Ablauf. Welche Schnittstelle dort genutzt wird und welche Felder Pflicht sind, klären wir im Prozessgespräch anhand Ihrer Version und Ihrer Anpassungen.

EDI, automatisierte Erfassung oder Kundenportal: Was passt zu welchem Kunden?

Die Wahl hängt am Kunden, nicht an Ihrem ERP. Wer EDI kann, bestellt über EDI. Wer per Mail bestellt, wird über die automatisierte Erfassung bedient. Ein Portal passt für Stammkunden, die regelmäßig bestellen, aber kein EDI haben. Die drei Wege schließen sich nicht aus und münden alle in dieselbe Prüfung.

Welche Fehlerbilder fängt die Strecke ab?

Die folgenden Fälle sehen im ERP korrekt aus und sind trotzdem falsch. Jede Prüfregel oben fängt mindestens einen davon ab.

• Doppelter Auftrag: Dieselbe Bestellung kommt per Mail und später als Erinnerung. Die Dublettenprüfung hält die zweite an.
• Änderung als Neubestellung: Der Kunde schickt eine korrigierte Fassung mit derselben Bestellnummer. Sie wird als Änderung erkannt.
• Alter Preis: Der Kunde bestellt aus einer veralteten Preisliste. Die Preisprüfung meldet die Differenz, das ERP bleibt führend.
• Falsche Einheit: Der Kunde meint Kartons, das ERP rechnet in Stück. Die Einheitenregel fängt das ab.
• Neue Lieferadresse im Freitext: Sie wird angezeigt, nicht still übernommen.
• Fremder Anhang: AGB oder Selbstauskünfte im Anhang werden nicht als Bestellung gelesen.
• Falsche Gesellschaft: Bei mehreren Gesellschaften prüft die Strecke, an welche Firma die Bestellung adressiert ist.

Ablauf in 6 Schritten

1. 01
   Prozessgespräch

   Wir klären Kanäle, Kundengruppen, heutige Erfassung und die Fälle, die heute Rückfragen auslösen.

2. 02
   Echte Bestellungen sammeln

   Bestellungen der letzten Wochen aus allen Kanälen dienen als Testmaterial, schwierige Fälle ausdrücklich eingeschlossen.

3. 03
   Prüfregeln festlegen

   Toleranzen für Preis und Termin, Zuständigkeiten und Fristen. Festgelegt wird, was durchläuft und was an Ihr Team geht.

4. 04
   Automatisierungs-Sprint

   Ein Kanal, zum Beispiel Mail und PDF, wird als Prototyp an die Testumgebung Ihres ERP angebunden. Gemessen wird, welcher Anteil ohne Eingriff durchläuft.

5. 05
   Parallelbetrieb

   Ihr Team erfasst wie bisher, die Automatisierung läuft daneben. Abweichungen zwischen beiden werden ausgewertet.

6. 06
   Betrieb und Ausbau

   Freigabe Schritt für Schritt, Protokoll zu jedem Auftrag, danach weitere Kanäle wie Excel oder EDI.

Häufige Fragen