Vier Stationen, bevor gebucht wird
Ein Kunde rief an einem Freitagnachmittag an. Eine Lieferantenrechnung sei nie angekommen, sagte er, und die Mahnung liege schon auf dem Tisch.
Wir haben zwei Tage gesucht. Die Nachricht war da — sie lag in einem Verzeichnis, in das seit Monaten niemand geschaut hatte, weil ein Feld nicht zum Schema passte. Kein Fehler, keine Meldung, nur Stille.
Das ist die eine Hälfte des Problems. Die andere habe ich häufiger gesehen und sie ist teurer: Die Nachricht kommt an, wird sofort verarbeitet, und der Fehler landet als Buchung in den Büchern. Niemand merkt etwas, bis die Buchhaltung ihn findet.
Eine Buchung lässt sich nicht zurücknehmen
Sie lässt sich korrigieren. Das ist nicht dasselbe. Es braucht eine zweite Buchung, eine Erklärung an die Buchhaltung und eine Spur, die im Abschluss sichtbar bleibt. Bei einer falschen Menge kommt eine Lagerkorrektur dazu, bei einem falschen Preis eine Differenz, die jemand gegenüber dem Lieferanten vertreten muss.
Der Schaden liegt also selten in der falschen Zahl. Er liegt im Aufwand, sie geradezuziehen — und in dem Vertrauen, das dabei verloren geht. Deshalb entscheidet nicht die Geschwindigkeit der Übernahme, sondern was vorher geprüft wurde. Genau dafür liegen in FlexxLink, der Integrationsplattform für Dynamics 365, vier Stationen zwischen Nachricht und Beleg.
Station 01Die Nachricht, wie sie ankam
Jede eingehende Nachricht wird zuerst unverändert festgehalten. In FlexxLink heißt dieser Halt Integrationsjob: er hält die technischen Details und die Rohnachricht, so wie sie am Endpunkt ankam. Kein Mapping, keine Interpretation, keine Buchung.
Das klingt nach einer Formalie, bis es zum ersten Mal darauf ankommt. Wenn ein Partner behauptet, er habe eine andere Menge geschickt, ist das der Nachweis, der die Diskussion beendet. Und wenn wochenlang niemand hingesehen hat, ist es der einzige Weg zurück zu der Frage, was ursprünglich im Haus angekommen ist. Wer stattdessen nur das Mapping-Ergebnis speichert, hat im Streitfall genau das, was er selbst daraus gemacht hat.
Station 02Aus Technik wird ein Geschäftsvorfall
Erst danach wird übersetzt. Aus dem Integrationsjob entsteht das Importjournal: die ausgelesenen Daten in einem Formular, das die Fachabteilung lesen kann — Positionen, Mengen, Preise, Partner. Der Status lautet dann „Importiert", und die Bücher sind noch nicht berührt.
Diese Station entscheidet darüber, wer bei einem Problem arbeiten muss. Liegt zwischen Nachricht und Beleg nichts, landet jede Rückfrage in der IT, weil nur dort jemand die Rohdaten lesen kann. Liegt dort ein Journal in Geschäftssprache, sieht der Einkauf selbst, dass eine Artikelnummer unbekannt ist. Das ist keine technische Verbesserung, das ist eine andere Verteilung von Arbeit — und sie ist der Grund, warum Integrationsprojekte nach dem Go-live entweder ruhig werden oder nicht.
Station 03Geprüft, dann freigegeben
Geprüft wird nach Regeln, die am Belegtyp hängen, nicht am Einzelfall. Technisch sind das Prüfregeln, zu Prüfprofilen zusammengefasst — je Schnittstelle, je Integrationsanwendung, je Partner. Ein Satz Regeln ist mitgeliefert, eigene kommen dazu. Jede Bestellung desselben Typs wird damit gleich behandelt, unabhängig davon, wer sie bearbeitet.
Ich habe oft die andere Variante gesehen: Die Regel steckt im Kopf von zwei oder drei Leuten. Sie wissen, welcher Partner falsche Einheiten schickt und bei welchem Kunden die Bestellnummer fehlen darf. Sie machen ihre Arbeit gut. Das Problem ist nicht ihre Arbeit, sondern dass niemand sie nachlesen kann. Steht einer davon im Urlaub, entscheidet der Zufall.
Drei Dinge gehören zu dieser Station:
Der letzte Punkt wirkt wie Bürokratie, bis der Wirtschaftsprüfer fragt, warum ein Beleg ohne Bestellbezug gebucht wurde. Dann ist es der Unterschied zwischen einer Auskunft und einer Vermutung. Wer ablehnt, wählt dabei einen Ablehnungsgrund aus einer gepflegten Liste — damit steht auch beim Nein eine Begründung im Journal und nicht nur ein Häkchen.
Station 04Nur was freigegeben ist, wird gebucht
Erst am Ende der Kette entsteht ein Beleg in Dynamics 365. Alles davor ist nachvollziehbar, korrigierbar und wiederholbar.
Das ist die praktische Folge der ganzen Anordnung: Ein Fehler wird zur Warteschlange statt zur Sackgasse. In einem Projekt hatte die Fehlerliste 140 Einträge, alle mit derselben Ursache — ein Artikel, der im System eine andere Nummer trug als beim Lieferanten. Vorher hatten zwei Leute jeden Morgen die gescheiterten Bestellungen von Hand nachgetippt. Mit der Kette wurde daraus eine Stammdatenkorrektur und ein Lauf über Nacht.
Dafür gibt es zwei Vorkehrungen, die man erst im Betrieb schätzt. Kollidieren zwei Buchungen auf demselben Datensatz, wird mit wachsendem Abstand erneut versucht; erst nach der eingestellten Zahl von Versuchen geht das Journal auf „Fehler". Und was im Fehler steht, holt ein periodischer Lauf wieder ab — er durchläuft Prüfung, Freigabe und Buchung noch einmal, nach den Regeln, die für diese Schnittstelle hinterlegt sind. Nach einer Stammdatenkorrektur muss also niemand 140 Einträge einzeln anfassen.
Der nachgetippte Beleg hat mit der Nachricht des Lieferanten nichts mehr zu tun. Zwei Belege, zwei Wahrheiten, keine Verbindung zwischen beiden.
Was das im Alltag bedeutet
Nicht die Buchhaltung sucht, sondern eine Liste zeigt. Das verkürzt die Klärung von Tagen auf Minuten — und verschiebt sie dorthin, wo die Fachkenntnis sitzt.
Prüfbar im Abschluss, ohne Rekonstruktion aus Logdateien. Bei vier Updates im Jahr ist das auch der Unterschied zwischen einem Test und einer Hoffnung.
Korrigieren und erneut verarbeiten statt stornieren und nachbuchen. Das entscheidet, ob eine Fehlerliste kürzer wird oder wächst.
Woran man erkennt, dass die Kette fehlt
Man muss dafür nicht in die Technik schauen. Es genügen vier Fragen, und die Antworten kommen meist aus der Fachabteilung, nicht aus der IT:
Auf die erste Frage folgt in Projekten fast immer eine Pause. Sie ist der eigentliche Befund: Klassische Anbindungen melden Abbrüche zuverlässig — Stillstand melden sie nicht. Und der häufigste EDI-Ausfall ist nicht der Fehler, sondern die Nachricht, die nie kam.
Warum die Kette nicht langsamer macht
Der häufigste Einwand gegen vier Stationen lautet: Das dauert. Er ist verständlich und meistens falsch, weil er Prüfung mit Handarbeit verwechselt.
Die Regeln laufen automatisch. Was die Betriebsart bestimmt, ist nur der Zeitpunkt — und zwar für jede der drei Stufen einzeln: Prüfung, Freigabe und Buchung lassen sich je Schnittstelle von Hand auslösen, sofort beim Eingang erledigen oder einem periodischen Lauf überlassen. In den ersten Wochen mit einem neuen Partner gibt man von Hand frei und lässt prüfen; im Normalbetrieb läuft alles drei automatisch; in Spitzen bekommt der Partner seine Antwort in Millisekunden und die Verarbeitung folgt im Stapel danach.
Entscheidend ist, dass der Wechsel eine Einstellung ist und kein Umbau. Wer mit Handbetrieb startet und im nächsten Quartal auf Stapel umstellt, ändert keine Schnittstelle und keinen Prozess.
Was das nicht löst
Eine Kette macht falsche Stammdaten nicht richtig. Wenn Artikelnummern und Einheiten zwischen zwei Häusern nicht zusammenpassen, fällt das jetzt früher auf — behoben ist es damit nicht. Sie ersetzt auch keine Absprache: Was mit einem Partner nie vereinbart wurde, kann keine Prüfregel wissen.
Und sie kostet Zeit. Wer jeden Beleg von Hand freigibt, staut in der Hochsaison die Schnittstelle. Deshalb ist der Zeitpunkt der Prüfung eine Betriebsentscheidung — von Hand, sofort bei Eingang oder im Stapel — und keine technische.
Integration ist kein Transport. Sie ist ein Verfahren: festhalten, übersetzen, prüfen, freigeben, buchen. Was davon fehlt, holt man sich später als Korrektur zurück.
Wenn Sie wissen wollen, wie das in Ihrem Haus aussehen würde, erzählen Sie mir von Ihrem Arbeitstag. Das Produkt selbst mit Testzugang gibt es bei soluvine.com — gebaut hat es das Entwicklerteam, mit dem ich seit 25 Jahren zusammenarbeite.
Diesen Beitrag gibt es auch auf Englisch. Read in English
Alle Beiträge