Jeder Auftrag auf einer Zeitachse, vom Eingang bis zur bezahlten Rechnung.
Ob Order to Cash, Procure to Pay oder Serviceeinsatz bis zur Rechnung: Jeder dieser Abläufe berührt ERP, CRM, Webshop, Lager, Transport und Buchhaltung. Wir koppeln diese Systeme mit dokumentierten APIs und Ereignissen, sodass jeder Auftrag systemübergreifend genau einen Status hat. Tritt eine Ausnahme auf, bereitet ein Agent einen Lösungsvorschlag vor, über den ein Mensch entscheidet.
Für Unternehmen aus Österreich, die in mehreren EU-Mitgliedstaaten verkaufen, einkaufen und verrechnen, jeweils mit eigenen Systemen, Frächtern und Regeln zur e-Rechnung.
Ob Kundenauftrag, Bestellung oder Serviceanfrage: Erfasst wird nur einmal, im führenden System, von dort gehen die Daten per API und Ereignis an alle anderen. Statusmeldungen ergeben je Auftrag eine durchgehende Zeitachse. Geht ein Schritt schief oder passt er nicht in die Toleranz, trägt ein Agent die Hintergründe zusammen und macht einen Vorschlag; erst nach Genehmigung durch einen Menschen führt das führende System ihn aus. Rechnungen laufen strukturiert als e-Rechnung und werden automatisch zugeordnet, während die Prozessverantwortlichen Durchlauf und Schnittstellen überwachen.
Vorher und nachher
Was sich im täglichen Betrieb ändert
Heute
Mit dem System
Heute
Heute: Bei jeder Übergabe neu abgetippt
Ein Auftrag aus dem Webshop oder vom Außendienst wird ins ERP noch einmal eingegeben, Liefer- und Rechnungsdaten werden händisch in Lager, Transport und Buchhaltung übertragen.
Mit dem System
Mit dem System: Einmal erfasst, überall verfügbar
Auftrag, Lieferung und Rechnung entstehen jeweils in dem System, dem sie gehören, und werden als Ereignis veröffentlicht. Die anderen Systeme abonnieren das Ereignis, statt es abzutippen.
Heute
Heute: Der Stand von gestern
Die Schnittstellen laufen nur über Nacht. Kundendienst, Disposition und Buchhaltung arbeiten deshalb jeweils mit einem anderen, überholten Stand ein und desselben Auftrags, und wer nach seiner Lieferung fragt, bekommt einen Rückruf.
Mit dem System
Mit dem System: Ein aktueller Status
Für jeden Auftrag und jede Anfrage gibt es eine Zeitachse, gespeist aus den Ereignissen aller beteiligten Systeme. Kundendienst, Disposition und Buchhaltung schauen auf dieselben Fakten, und auch eine Serviceassistenz kann daraus Statusfragen beantworten.
Heute
Heute: Ausnahmen im Postfach
Ob Fehlbestand, Preisdifferenz, gescheiterte Zustellung oder abgewiesene e-Rechnung: Gelöst wird per E-Mail und Excel, und wer was entschieden hat, lässt sich später nicht mehr sagen.
Mit dem System
Mit dem System: Ausnahmen kommen mit Vorschlag
Zu jeder Ausnahme stellt ein Agent die nötigen Daten zusammen und formuliert einen Lösungsvorschlag. Ein Mensch nimmt ihn am gemeinsamen Ausnahmen-Arbeitsplatz an, passt ihn an oder lehnt ihn ab, und die Entscheidung bleibt dokumentiert.
Heute
Heute: Stammdaten, die sich widersprechen
Kunden, Lieferanten, Artikel und Preise stehen in mehreren Systemen mit abweichenden Werten, ohne dass jemand für den richtigen Wert geradesteht.
Mit dem System
Mit dem System: Eine Verantwortung je Datenobjekt
Kunden, Lieferanten, Artikel und Preise haben je ein vereinbartes führendes System und eine namentlich zuständige Person. Dubletten und Widersprüche landen bei ihr, statt irgendwo weiter hinten still ausgebessert zu werden.
Heute
Heute: Jede Neuerung bringt eine Schnittstelle mehr
Jeder zusätzliche Vertriebskanal, jeder Marktplatz und jede neue Gesellschaft bringt eine weitere direkte Verbindung zwischen zwei Systemen. Obendrein hat jedes Land eigene Vorgaben zur e-Rechnung mit eigenem Format und Netz, in Österreich etwa die e-Rechnung an den Bund.
Mit dem System
Mit dem System: Neue Anbindungen nutzen dieselben Verträge
Ein neuer Kanal, eine neue Gesellschaft oder ein weiteres e-Rechnungsnetz dockt einmal an dokumentierte APIs und Ereignisse an, statt an jedes System einzeln.
Workflow
Der Ablauf im Einzelnen
Mit sauberen Daten läuft der Hauptpfad ganz ohne Handarbeit. Erst wenn ein Auftrag, eine Lieferung oder eine Rechnung aus der Reihe tanzt, holt die Ausnahmeschleife einen Menschen dazu, mit Belegen und einem fertigen Vorschlag. Die genehmigte Korrektur nimmt danach denselben Weg durch die Integrationsschicht.
Beispielhafter Ablauf
7 Schritte · 1 menschliche Prüfung
Legende
System
Agent
Person
Menschliche Prüfung
Ausnahmepfad
Vernetzte Prozesse: illustrativer Ablauf mit Ausnahmeschleife
Diagramm als Text lesen
Der Hauptpfad beginnt mit dem einmaligen Erfassen eines Geschäftsereignisses im führenden System, führt über die Verteilung an die anderen Systeme per API und Ereignis und den Aufbau einer Zeitachse je Auftrag zu Verrechnung, Abgleich und Zahlungsausgleich. Am Ende prüfen die Prozessverantwortlichen den Durchfluss und beheben die Ursachen von Ausnahmen.
Misslingt ein Schritt, kommt er zu spät oder sprengt er die Toleranz, zweigt die Ausnahme nach der Zeitachse vom Hauptpfad ab. Ein Agent trägt die Hintergründe zusammen und macht einen Vorschlag; ein Mensch nimmt ihn an, passt ihn an oder lehnt ihn ab. Was genehmigt ist, führt das führende System aus, und die Änderung kommt als neues Ereignis wieder beim Verteilen an.
Menschlicher Kontrollpunkt ist die Genehmigung: Ohne eine Person gibt es keine Buchung, keine Änderung von Preis oder Kreditlimit und keine Zusage an einen Kunden.
01
Schritt 1: Ereignis einmal erfassenSystem
Kundenaufträge aus Webshop, Marktplatz, EDI oder vom Außendienst, Bestellungen und Serviceanfragen entstehen jeweils in dem System, das für sie zuständig ist. Von dort geht ein Geschäftsereignis im CloudEvents-Format hinaus, beschrieben durch einen AsyncAPI-Vertrag. Was auf Papier oder als PDF kommt, Aufträge ebenso wie Lieferantenrechnungen, nimmt vorher den Weg über die Dokumentenverarbeitung.
02
Schritt 2: Über APIs und Ereignisse verteilenSystem
Lager, Transport, Buchhaltung und CRM erhalten das Ereignis von der Integrationsschicht, jeweils über ihre dokumentierten APIs (OpenAPI). Weil alle Empfänger idempotent arbeiten, führt eine doppelt ankommende Nachricht nie zu einer zweiten Sendung oder Rechnung; was nicht zugestellt werden kann, parkt in einer Fehlerwarteschlange und lässt sich erneut einspielen.
03
Schritt 3: Eine Zeitachse je AuftragSystem
Bestätigt, kommissioniert, versandt, zugestellt, verrechnet, bezahlt: Die Statusmeldungen aller Systeme werden anhand der Geschäftsreferenz zu einer Zeitachse zusammengeführt. Regeln für Meilensteine und Toleranzen schlagen Alarm, sobald ein Schritt scheitert, zu spät kommt oder nicht zusammenpasst, zum Beispiel bei fehlender Ware, einem Preis jenseits der Toleranz, einer missglückten Zustellung oder einer abgewiesenen e-Rechnung.
04
Schritt 4: Kontext sammeln und vorschlagenAgent
Für jede Ausnahme holt sich ein Agent aus den beteiligten Systemen, was er braucht: Auftrag, Lagerstand, Preisvereinbarung, Sendungsstatus beim Frächter und Kundenkonditionen. Daraus entsteht ein begründeter Vorschlag samt den herangezogenen Daten, etwa ein Ersatzartikel, ein berichtigter Preis, ein verschobener Liefertermin oder eine korrigierte Rechnung.
Ausnahmepfad: Schritt gescheitert oder außer Toleranz
05
Schritt 5: Innerhalb der Schwellen genehmigenPerson
Eine Mitarbeiterin oder ein Mitarbeiter aus Kundendienst, Logistik oder Buchhaltung sieht Ausnahme, Belege und Vorschlag am Ausnahmen-Arbeitsplatz und genehmigt, ändert oder verwirft. Die genehmigte Aktion läuft über die API des führenden Systems, das die Änderung als neues Ereignis veröffentlicht.
Ausnahmepfad: Schritt gescheitert oder außer Toleranz· Zurück zu Schritt 2
Menschliche Prüfung
Agenten buchen nie selbst, ändern keine Preise oder Kreditlimits und sagen Kunden nichts ohne Genehmigung zu. Schwellen je Aktionsart legen fest, wer genehmigt, und jeder Vorschlag und jede Entscheidung wird protokolliert.
Ausgangsrechnungen gehen als strukturierte e-Rechnungen (Peppol BIS Billing 3.0, EN 16931) über einen Access Point aus dem ERP hinaus; an Bundesdienststellen über Peppol oder das USP. Eingangsrechnungen ordnet das System Bestellung und Wareneingang zu, und sobald Bank oder Zahlungsdienstleister die Zahlung melden, ist die Zeitachse abgeschlossen.
07
Schritt 7: Durchfluss prüfen und Ursachen behebenPerson
Regelmäßig sehen sich Prozessverantwortliche und Integrationsteam an, aus welchen Gründen Ausnahmen entstehen, wo Schnittstellen hängen und welche Stammdaten sich widersprechen. Behoben wird an der Wurzel, also im Stammdatensatz, in der Toleranzregel oder im Mapping, damit dieselbe Ausnahme nicht ständig neu auftaucht.
Komponenten
Was wir bauen würden
01
Ereignisgesteuerte Integrationsschicht
APIs und Ereignisse nach dem Contract-first-Prinzip zwischen ERP, CRM, Webshop, Lager, Transport und Buchhaltung, beschrieben in OpenAPI und AsyncAPI mit CloudEvents, auf Ihrer bestehenden Integrationsplattform oder cloud-nativ gebaut.
Je Datenobjekt ein vereinbartes führendes System und eine Verantwortung, Abgleichsregeln für Kunden, Lieferanten und Artikel sowie Berichte zu Dubletten und Widersprüchen für die zuständigen Personen.
Ein Dienst, der Ereignisse je Auftrag oder Anfrage zu einer Zeitachse verknüpft, Meilenstein- und Toleranzregeln anwendet und den Prozessverantwortlichen Durchfluss und Ausnahmen zeigt.
Eine Arbeitsliste der Ausnahmen, in der zu jedem Fall Kontext und Vorschlag des Agenten stehen. Annehmen, anpassen oder ablehnen geschieht mit einem Klick, und die Schwellen je Aktionsart werden genau dort geprüft, wo die Aktion ausgeführt wird.
Rechnungen nach Peppol BIS Billing 3.0 und EN 16931 in UBL, über einen Access Point gesendet und empfangen, vor dem Versand validiert; abgewiesene Rechnungen landen am Ausnahmen-Arbeitsplatz.
Zustandsüberwachung und Alarme je Schnittstelle, Betriebshandbücher für den IT-Betrieb und kontrollierte Wiederholung gescheiterter Nachrichten, ausgerollt als Infrastructure as Code in Ihrem Cloud-Mandanten.
Bestellungen und Auftragsbestätigungen von Lieferanten
Serviceanfragen und Berichte aus dem Außendienst
Sendungsverfolgung und Zustellereignisse der Frächter
Peppol-e-Rechnungen und Statusmeldungen
Kontoauszüge und Zahlungsavise
Kern der Lösung
Vernetzte Prozesse
Angebundene Systeme
SAP S/4HANA Vertrieb, Einkauf und FinanzwesenPlattformSAP
Salesforce Sales, Service und Commerce CloudPlattformSalesforce
Odoo Verkauf, Lager, Einkauf und BuchhaltungPlattformOdoo
E-Commerce-Plattformen, Marktplätze und APIs der Frächter
Lagerverwaltungs- und Transportmanagementsysteme
Peppol Access Point, Banken und Zahlungsdienstleister
Produktinformationsmanagement und Datenplattform
Kontrollen
Eingebaute Kontrollen
Zugriffsgrenzen
Jede Integration und auch der Agent haben pro System eine eigene Dienstidentität mit genau den API-Operationen, die sie benötigen. Für den Kontext darf der Agent über Systemgrenzen hinweg lesen. Schreiben kann er nur über wenige genehmigte Aktionen, die über die API des führenden Systems laufen und nie direkt in eine Datenbank.
Menschliche Prüfung
Gemeinsam mit den Prozessverantwortlichen legen wir pro Aktionsart fest, was der Agent bloß vorschlägt, was ein Teammitglied freigibt und wo es eine zweite Freigabe braucht. Buchungen, Preis- und Kreditlimitänderungen sowie Zusagen an Kunden entscheidet immer ein Mensch. Kleine, umkehrbare Schritte wie das erneute Senden einer gescheiterten Nachricht können mit Zustimmung der Verantwortlichen ohne Freigabe laufen.
Nachvollziehbarkeit
Zu jeder Auftrags- oder Anfragereferenz halten wir fest: jedes Ereignis, jeden Vorschlag, jede Freigabe und Ablehnung, jede ausgeführte Aktion, dazu die Daten des Agenten, Modell- und Prompt-Version und wer freigegeben hat. Bei einer strittigen Rechnung oder einer Reklamation lässt sich jeder Schritt zurückverfolgen.
Datenschutz
Kontaktdaten von Kunden und Lieferanten erreichen nur Systeme, die sie tatsächlich benötigen. In der Zeitachse stehen Geschäftsreferenzen und Status, nicht ganze Datensätze; Protokolle werden so lange aufbewahrt, wie Sie es vorgeben, und die Verarbeitung bleibt in der vereinbarten Region.
KI-Transparenz
Vorschläge des Agenten sind am Ausnahmen-Arbeitsplatz als solche gekennzeichnet, Belege und Begründung stehen daneben. Maßgeblich bleiben die führenden Systeme: Die Zeitachse zeigt, was sie melden, und setzt sich nie über sie hinweg.
Kennzahlen
Woran wir den Erfolg messen würden
Die Messgrößen vereinbaren wir in der Analysephase mit Ihnen; den Ist-Stand nehmen wir aus den heutigen System- und Schnittstellenprotokollen, bevor sich etwas ändert.
Woran wir den Erfolg messen würden
Kennzahl
Warum sie zählt
Wie wir sie messen würden
01Durchlaufzeit je Auftrag
Warum sie zähltDas merken Kunden als Erstes, und hier sieht man, an welcher Stelle Aufträge hängen bleiben.
Wie wir sie messen würdenDauer vom Eingang des Auftrags bis zur Lieferung und bis zum Zahlungseingang, getrennt nach Kanal und Gesellschaft, aus der Zeitachse.
02Aufträge ohne Handgriff
Warum sie zähltZeigt, wie viel des Ablaufs auf sauberen Daten und vereinbarten Regeln läuft.
Wie wir sie messen würdenAnteil der Aufträge und Anfragen, die ohne manuellen Schritt oder Ausnahme bis zum Zahlungsausgleich kommen, laut Zeitachse.
03Ausnahmen nach Grund und Lösungsdauer
Warum sie zähltZeigt, welche Ursachen zuerst behoben werden sollten und ob der Ausnahmen-Arbeitsplatz nachkommt.
Wie wir sie messen würdenAnzahl der Ausnahmen pro Grundcode sowie Dauer vom Erkennen bis zur umgesetzten Lösung, laut Protokoll des Ausnahmen-Arbeitsplatzes.
04Abweisungsquote bei e-Rechnungen
Warum sie zähltJede abgewiesene Rechnung schiebt die Zahlung hinaus, und meist steckt ein Stammdaten- oder Mappingfehler dahinter.
Wie wir sie messen würdenAnteil abgewiesener gesendeter und empfangener e-Rechnungen, nach Grund, aus den Rückmeldungen des Access Points.
05Schnittstellenfehler und Wiederherstellungszeit
Warum sie zähltZeigt, ob die Integrationsschicht verlässlich ist und ob Fehler rasch bemerkt und behoben werden.
Wie wir sie messen würdenZahl der gescheiterten Nachrichten pro Schnittstelle und Dauer bis zur gelungenen Wiederholung, laut Integrationsmonitoring.
06Dubletten und Widersprüche in Stammdaten
Warum sie zähltHinter den meisten Ausnahmen stehen Daten, die in zwei Systemen verschieden aussehen.
Wie wir sie messen würdenAnzahl offener Dubletten und abweichender Werte pro Datenobjekt und System, laut Abgleichsbericht.
Ziele werden erst nach einer Ausgangsmessung festgelegt.
Einführung
Wie wir es einführen würden
Phase 01
Analyse und Prozesslandkarte
Wir nehmen einen Prozess, zum Beispiel Order to Cash in einem Vertriebskanal, und eine Ausnahmeart. Erfasst werden Systeme, Schnittstellen, Datenverantwortliche und wie Ausnahmen heute gelöst werden.
Abschlusskriterien
Prozess, Systeme und Datenverantwortliche erfasst
Erste Ausnahmeart und Genehmigungsschwellen vereinbart
Ist-Stand aus den heutigen Protokollen erhoben
Phase 02
Integration und Zeitachse
Dokumentierte APIs und Ereignisse für die Systeme im Umfang; die Zeitachse läuft neben den bestehenden Schnittstellen mit, ohne sie zu verändern.
Abschlusskriterien
Ereignisverträge veröffentlicht und versioniert
Zeitachse stimmt in Stichproben mit den führenden Systemen überein
Wiederholung und Betriebshandbücher getestet
Phase 03
Pilot am Ausnahmen-Arbeitsplatz
Für die gewählte Ausnahmeart macht der Agent Vorschläge, und jeder einzelne braucht eine menschliche Freigabe. Parallel prüfen wir, ob die Vorschläge dem entsprechen, was das Team selbst entschieden hätte.
Abschlusskriterien
Qualität der Vorschläge erfüllt die vereinbarten Kriterien
Schwellen und Genehmigende je Aktionsart festgelegt
Prüfpfad von Buchhaltung und interner Kontrolle durchgesehen
Phase 04
Ausbauen und ablösen
Nach und nach kommen weitere Ausnahmearten, Kanäle, Gesellschaften und Prozesse wie Procure to Pay dazu, alle auf denselben Verträgen. Die alten direkten Schnittstellen schalten wir eine nach der anderen ab.
Abschlusskriterien
Jeder neue Ablauf auf denselben Verträgen und derselben Überwachung
Auftragsfertigung und Ersatzteilaufträge eines Maschinenbauers vom ERP bis zu Lager und Frächtern, mit Lieferantenbestätigungen und e-Rechnungen, die mit den Bestellungen abgeglichen werden.
Anschluss- und Installationsaufträge bei einem Landesenergieversorger, vom Arbeitsauftrag über den Einsatz vor Ort bis zur Rechnung, und Materialbestellungen aus Rahmenverträgen.
Instandhaltungsaufträge, Bestellungen bei Auftragnehmern und deren Rechnungen, von der Anforderung bis zur Zahlung verfolgt, etwa bei einem Seilbahn- oder Verkehrsbetrieb.
Procure to Pay mit strukturierten e-Rechnungen von und an öffentliche Stellen, etwa die e-Rechnung an den Bund über Peppol oder das USP, abgeglichen mit Bestellung und Wareneingang vor der Zahlung.
Beispiel zur Veranschaulichung
Ein Großhändler für Haustechnik in drei Ländern
Ausgangslage
Ein Großhändler für Haustechnik verkauft über Webshop, einen Marktplatz und den Außendienst in Österreich, Deutschland und Slowenien, aus zwei Lagern. Aufträge werden ins ERP nachgetippt, Frächter melden Zustellprobleme per E-Mail, und jedes Land verrechnet auf seine Weise, von der e-Rechnung an Bundesdienststellen bis zur XRechnung für deutsche öffentliche Kunden.
System
Aufträge, Lagerstände, Sendungen und Rechnungen laufen als Ereignisse zwischen Webshop, ERP, Lagersystem und Frächtern, und jeder Auftrag hat eine Zeitachse. Rechnungen gehen als strukturierte e-Rechnungen über einen Access Point hinaus, in dem Netz und Format, die der jeweilige Empfänger verlangt.
Menschliche Kontrolle
Fehlende Ware und missglückte Zustellungen kommen auf einen gemeinsamen Ausnahmen-Arbeitsplatz; der Agent schlägt dort einen Ersatzartikel oder einen anderen Liefertermin vor. Jeden Vorschlag gibt der Kundendienst frei, Preisänderungen und Gutschriften die Buchhaltung.
Was wir messen würden
Anteil der Aufträge ohne Handgriff je Land und Kanal, Ausnahmen nach Grund und Lösungsdauer sowie Abweisungsquote der e-Rechnungen je Land.
Österreich
Ein Prozess, mehrere Länder und Pflichten
Österreichische Unternehmen, die nach Deutschland und Mittel- und Osteuropa liefern, betreiben dieselben Prozesse von Order to Cash und Procure to Pay oft auf verschiedenen ERP-Instanzen, mit verschiedenen Frächtern und Banken. Die e-Rechnung an den Bund läuft über das USP oder Peppol, deutsche öffentliche Auftraggeber verlangen die XRechnung, und mit dem EU-Paket „Mehrwertsteuer im digitalen Zeitalter“ wird die strukturierte e-Rechnung ab 1. Juli 2030 zum Standard für innergemeinschaftliche B2B-Lieferungen. Wir planen eine gemeinsame Integrationsschicht mit dem Format und Netz jedes Landes hinter denselben Ereignissen. Eine neue Pflicht bedeutet dann einen neuen Konnektor, keinen neuen Prozess.
Der Data Act regelt seit 12. September 2025 den Wechsel zwischen Datenverarbeitungsdiensten; deshalb halten wir Ereignisverträge und Datenexporte übertragbar. Agenten am Ausnahmen-Arbeitsplatz planen wir mit Blick auf die KI-Verordnung. Für Kunden, die unter das NISG 2026 fallen und die Sicherheit ihrer Lieferkette nachweisen müssen, kommen die Integrationen mit protokollierten Zugriffen und dokumentierten Komponenten.
Nein. ERP, CRM, Webshop und Lagersystem machen weiterhin jeweils ihre Arbeit. Wir bauen die Integration um diese führenden Systeme herum, klären, welches System für welche Daten zuständig ist, und legen eine Zeitachse über den ganzen Prozess. Bremst ein altes Auftrags- oder ERP-System jede Veränderung, bringt es die Modernisierung von Altsystemen zuerst hinter APIs.
02Ersetzen Sie unsere Integrations-Middleware?
Solange sie ihre Aufgabe erfüllt, nicht. Wir setzen auf die Integrationsplattform oder den Message Broker, der bei Ihnen schon läuft, und ergänzen Verträge, Monitoring und Wiederholung dort, wo sie fehlen. Gibt es keine solche Plattform, bauen wir cloud-nativ. Mehr zu unseren Integrationen.
03Dürfen Agenten selbstständig handeln?
Nur in den Grenzen, die Sie pro Aktionsart festlegen, und nur bei kleinen, umkehrbaren Schritten wie dem erneuten Senden einer gescheiterten Nachricht. Bei Buchungen, Preisen, Kreditlimits und Kundenzusagen entscheidet immer ein Mensch. Dazu unser Beitrag, wo KI-Agenten eine menschliche Freigabe brauchen.
04Wie passen die Pflichten zur e-Rechnung hinein?
In Österreich nehmen Bundesdienststellen seit 1. Jänner 2014 strukturierte e-Rechnungen über das USP oder Peppol entgegen; Lieferanten ohne Sitz in Österreich sind nur im Rahmen ihrer technischen Möglichkeiten verpflichtet, und für Lieferanten von Ländern und Gemeinden gibt es derzeit keine Pflicht. Wer an deutsche öffentliche Auftraggeber liefert, braucht zusätzlich die XRechnung. Mit dem EU-Paket „Mehrwertsteuer im digitalen Zeitalter“ wird die strukturierte e-Rechnung ab 1. Juli 2030 zum Standard für innergemeinschaftliche B2B-Lieferungen. Für uns ist die e-Rechnung ein weiteres Ereignis im Prozess: aus dem ERP erstellt, über einen Access Point versendet und am Ausnahmen-Arbeitsplatz bearbeitet, wenn sie abgewiesen wird. Mehr in unserem Leitfaden zur e-Rechnung über Peppol.
05Wie vermeiden Sie ein neues, fragiles Geflecht aus Punkt-zu-Punkt-Verbindungen?
Statt direkt miteinander zu sprechen, veröffentlichen und nutzen die Systeme dokumentierte Ereignisse und APIs über eine gemeinsame Schicht. Verträge haben Versionen, Empfänger sind idempotent, gescheiterte Nachrichten lassen sich wiederholen, und für jeden Ablauf ist jemand namentlich zuständig. Ein neuer Kanal hängt sich an vorhandene Ereignisse an, statt neue Leitungen zu jedem System zu legen.
06Wie sieht ein erster Umfang aus?
Ein Prozess, eine Ausnahmeart: etwa Order to Cash in einem Vertriebskanal, beginnend mit fehlender Ware. Daran zeigt sich, ob Ereignisse, Zeitachse und Freigabe tragen, bevor wir erweitern. Mehr dazu, wie wir Projekte umsetzen.
Sprechen wir über Ihre Auftrags- und Rechnungsflüsse
Nennen Sie uns einen Prozess und die Länder, in denen er läuft. Wir gehen Systeme, Schnittstellen und Ausnahmen gemeinsam durch und schlagen einen ersten Ausbauschritt vor, der für alle Ihre Gesellschaften taugt.