tricoma und n8n verbinden, ohne den Core anzufassen

Ein ERP kann fast alles — aber nie genau das eine, was in Ihrem Betrieb besonders ist. Genau dort setzt Automatisierung an: nicht im System selbst, sondern daneben. Dieses Muster verwenden wir bei tricoma-Kunden, wenn Bestellungen mehr Informationen brauchen, als der Standard mitliefert.

Das Problem

Eine Bestellung kommt über den Shop im ERP an. Alles korrekt — nur fehlt dem Team im Lager die Information, ob dieser Kunde Stammkunde ist, ob eine Lieferbeschränkung existiert, ob die Firmenadresse laut Prüfdienst plausibel ist und welcher Versanddienstleister bei dieser Kombination aus Gewicht und Land der günstigste ist. Diese Daten liegen in drei anderen Systemen.

Der falsche Reflex: das im ERP selbst nachbauen. Damit hängt Ihre Sonderlogik im Standard, und beim nächsten Update stellt sich die Frage, ob sie noch funktioniert.

Das Muster: außen anreichern, innen schreiben

1. Trigger. Der Ablauf startet ereignisbasiert, wenn eine neue Bestellung entsteht — nicht über einen Zeitplan, der alle fünf Minuten alles durchsucht.
2. Sammeln. n8n holt parallel die Zusatzdaten: Kundenhistorie, Adressprüfung, Versandtarife.
3. Entscheiden. Regeln zuerst, KI nur dort, wo Regeln nicht reichen — etwa bei Freitext im Bestellkommentar, der eine Wunschlieferzeit enthält.
4. Zurückschreiben. Das Ergebnis landet in definierten Feldern und einem Kommentar am Auftrag. Ein Feld pro Aussage, damit man später filtern kann.
5. Sichtbar machen. Auffälligkeiten erzeugen eine Aufgabe für einen Menschen statt einer Mail, die untergeht.

Der Kern: Der Ablauf liest viel und schreibt wenig, an genau definierten Stellen. So bleibt das ERP im Standard und updatefähig, und die Sonderlogik liegt an einem Ort, an dem man sie ohne Risiko ändern kann.

Idempotenz: der Punkt, an dem Anfänger scheitern

Jeder Trigger feuert irgendwann doppelt — nach einem Neustart, einem Timeout oder einem manuellen Nachlauf. Wenn Ihr Workflow dann ein zweites Mal einen Kommentar anlegt oder eine Mail schickt, fällt das beim Kunden auf. Zwei Zeilen Absicherung genügen:

// Am Anfang prüfen, ob dieser Auftrag schon verarbeitet wurde
if ($json.custom_enriched_at) {
  return [];        // still beenden, kein Fehler
}

Und am Ende dasselbe Feld setzen. Damit ist der Ablauf beliebig oft wiederholbar, ohne Nebenwirkungen — die Voraussetzung dafür, dass man ihn nach einem Fehler einfach neu starten kann.

Fehlerbehandlung, die Ihnen jemand meldet

Externe Dienste antworten manchmal nicht. Für diesen Fall gilt: Wiederholen mit Abstand, aber nur bei technischen Fehlern; bei fachlichen Fehlern (Adresse existiert nicht) einmal sauber ablegen und einen Menschen informieren. Ein einziger Error-Workflow, in allen produktiven Abläufen eingetragen, reicht für den Anfang — Hauptsache, es gibt einen.

Was ins ERP gehört und nicht in n8n

Diese Grenze ziehen wir bei jedem Projekt neu, und meistens läuft sie so:

• Ins ERP: Preisfindung, Lagerbuchungen, Belegfluss, Rechte, alles mit Buchhaltungsbezug. Auch die KI-Funktionen, die tricoma bereits mitbringt — Produkttexte etwa baut man nicht zweimal.
• In n8n: Kommunikation mit Fremdsystemen ohne fertige Schnittstelle, Anreicherung, Benachrichtigungen, mehrstufige Prüfungen, alles Experimentelle.

Die Faustregel: Wenn ein Ablauf drei Monate stabil läuft und für den Betrieb zentral ist, prüfen wir, ob er als eigenes Modul über die SDK besser im ERP sitzt. Bis dahin ist n8n der günstigere Ort, um Dinge auszuprobieren.

Aufwand in der Praxis

Ein Anreicherungs-Workflow dieser Art ist typischerweise nach ein bis zwei Tagen produktiv, vorausgesetzt die Zugänge zu den Fremdsystemen liegen vor. Der längere Teil ist fast immer nicht das Bauen, sondern das Klären: Welche Aussage soll der Workflow treffen, und wer entscheidet im Zweifelsfall? Diese Frage lässt sich nicht automatisieren.