JTL-Workflows sind kein Zeitplaner: was ereignisgesteuerte Automatisierung wirklich kann

JTL-Workflows sind ausschließlich ereignisgesteuert. Jeder Workflow braucht ein auslösendes Ereignis in JTL-Wawi; der Ausführungsplan verschiebt nur den Zeitpunkt nach diesem Ereignis. Eine echte Zeitsteuerung gibt es nicht. Wer periodisch prüfen will, nutzt den Windows-Aufgabenplaner mit JTL-Ameise, einen Selbstaufruf über ein manuelles Ereignis oder eine externe Automatisierung. Der JTL-Worker muss dabei immer laufen.

Stand: 7. September 2026. Alle Angaben stammen aus dem JTL-Guide und der Preisseite von JTL-Software und wurden an diesem Tag einzeln nachgelesen. Ein Hinweis zur Aktualität: Die Guide-Seiten tragen im Fuß „© 2025 | JTL-Software GmbH" und weisen kein sichtbares Änderungsdatum aus. Als Stand gilt deshalb unser Abrufdatum, nicht ein Aktualitätsdatum der Seite. Prüfen Sie Bezeichnungen und Grenzen vor der Umsetzung an der Version, die Sie einsetzen.

1. Der Satz, der jedes JTL-Projekt einmal kostet

„Wir brauchen einen Workflow, der jeden Morgen um acht alle Aufträge ohne Zahlungseingang heraussucht." Diesen Satz hören wir in fast jedem JTL-Projekt. Er klingt harmlos, und er beschreibt eine völlig normale Anforderung. Nur lässt er sich mit JTL-Workflows nicht erfüllen — jedenfalls nicht so, wie er gemeint ist.

Wie verbreitet der Irrtum ist, zeigt Google selbst: Unter den verwandten Suchanfragen zu „JTL Workflows" steht direkt unter dem ersten Treffer „jtl workflow zeitgesteuert". Menschen suchen also aktiv nach einer Funktion, die es in dieser Form nicht gibt. Und keine der Seiten, die für diese Suche ranken, sagt es ihnen.

Die Hersteller-Dokumentation ist an dieser Stelle unmissverständlich. Auf der Seite zu manuellen Workflow-Ereignissen schreibt JTL: „Um einen Workflow über JTL-Wawi auszulösen, benötigen Sie ein auslösendes Ereignis und ggf. eine oder mehrere Bedingungen, um eine oder mehrere Aktionen automatisiert erfolgen zu lassen." Das auslösende Ereignis ist keine Option, sondern der Anfang der Kette. Gibt es kein Ereignis, gibt es keinen Workflow-Lauf.

Der Unterschied klingt akademisch und ist es nicht. Ein Auftrag, der vor drei Wochen angelegt wurde und seitdem unbezahlt liegt, erzeugt heute Morgen kein Ereignis. Er bleibt für die Workflow-Verwaltung unsichtbar — egal, wie geschickt Sie die Bedingungen formulieren. Wer das erst nach dem Bau merkt, hat den Prozess einmal umsonst konzipiert.

2. Wie ein Workflow gebaut ist: fünf Bereiche, drei Pflichtteile

Die Workflow-Verwaltung öffnen Sie in JTL-Wawi über Admin > JTL-Workflows. Der Dialog teilt sich in fünf Fensterbereiche, die JTL im Guide von A bis E durchnummeriert. Die Reihenfolge ist keine Gestaltungsfrage, sondern die Reihenfolge, in der Sie arbeiten müssen.

Nur die Bedingungen sind optional. Ereignis und Aktion sind Pflicht — und genau darin steckt die Systemgrenze. Es gibt in dieser Maske kein Feld, in das Sie „alle zwei Stunden" schreiben könnten, ohne vorher ein Ereignis gewählt zu haben.

Die Bedingungen selbst sind mächtiger, als viele annehmen. Sie arbeiten feldbasiert mit einem Operator und einem Vergleichswert, und mehrere Bedingungen lassen sich als „alle erfüllt", „nur eine erfüllt" oder „keine erfüllt" verknüpfen. Über die Schaltfläche „Erweiterte Eigenschaften verwalten" holen Sie zusätzliche Datenbankfelder heran; dafür nennt der Guide die Vorlagensprache DotLiquid.

Bei den Aktionen lohnt eine Präzisierung, die in vielen Übersichten fehlt. Die Dokumentation nennt drei Aktionsarten mit dem Zusatz, dass sie „häufige Anwendung" finden — sie beansprucht also selbst keine Vollständigkeit. Über weitere Guide-Seiten sind zwei zusätzliche Aktionsarten belegt. Insgesamt gesichert sind damit fünf: Ausführen, E-Mail senden, Ausgabe, Werte setzen und Workflow-Ereignis auslösen. Eine abschließende Liste veröffentlicht JTL nicht, und wir behaupten hier keine.

Die interessanteste davon ist „Ausführen". Damit können Sie laut Guide „ein externes Programm oder Skript aufrufen und diesem die gewünschten dynamischen Parameter mittels DotLiquid aus JTL-Wawi übergeben". Das ist die Tür nach draußen — und sie wird in der Praxis erstaunlich selten benutzt.

3. Der Ausführungsplan: sieht aus wie ein Zeitplaner, ist keiner

Jetzt zur eigentlichen Ursache des Missverständnisses. In Bereich C sitzt ein Auswahlmenü namens Ausführungsplan. Es öffnet ein Fenster, in dem Sie „den Ausführungszeitpunkt Ihres Workflows genau bestimmen" können. Die Voreinstellung heißt „Sofort" und bewirkt laut Guide „einen unmittelbaren Start des Workflows bei Eintritt des auslösenden Ereignisses".

Und dann kommt der Satz, der so viele Konzepte in die falsche Richtung schickt. Der Guide beschreibt ein Beispiel, in dem Etiketten gebündelt gedruckt werden sollen, und formuliert das Ergebnis so: „Damit erreichen wir, dass zu diesem Zeitpunkt, nämlich täglich um 17.00 Uhr, der Workflow gestartet wird." Wer das liest, hält den Ausführungsplan für einen Zeitplaner. Er trägt ein Uhrzeitfeld, und die Doku spricht von „täglich".

Der Halbsatz danach löst es auf: „Um diese Uhrzeit werden alle zwischenzeitlich neu erstellten Artikel auf ggf. eingerichtete Bedingungen geprüft." Geprüft wird also nur, was zwischenzeitlich ein Ereignis erzeugt hat. Wurde an diesem Tag kein Artikel angelegt, passiert um 17.00 Uhr nichts. Der Ausführungsplan terminiert die Verarbeitung eines Ereignisses. Er erzeugt keines.

Das ist ein feiner, aber entscheidender Unterschied — und er hat eine praktische Konsequenz: Der Ausführungsplan ist hervorragend darin, Last zu bündeln und Hektik aus dem Tagesgeschäft zu nehmen. Er ist untauglich, um einen Bestand zu überwachen.

Die Option, die im Alltag am meisten spart

Im selben Fenster sitzt eine Checkbox namens „Nur letzten ausführen". Ist sie aktiv, führt JTL-Wawi „mehrere gleiche zeitversetzte Workflows für dasselbe Objekt nur einmal aus". Der Guide erklärt es an einem Beispiel, das jeder kennt: Ein Mitarbeiter korrigiert einen Artikel fünfmal hintereinander, und Sie bekommen fünf Benachrichtigungen. Mit 30 Minuten Verzögerung und dieser Option bekommen Sie eine.

Genau hier hängt die harte Voraussetzung. Der Guide setzt sie in einen eigenen Warnkasten: „Beachten Sie bitte unbedingt, dass für das zeitversetzte Ausführen von Workflows der Worker (Hintergrunddienst) von JTL-Wawi aktiviert sein muss." Wer den Ausführungsplan nutzt und den Worker nicht betreibt, baut einen Workflow, der nie ausgeführt wird — ohne Fehlermeldung.

4. Der JTL-Worker: ohne ihn passiert gar nichts

Der JTL-Worker ist das am meisten unterschätzte Bauteil dieser Kette. JTL beschreibt ihn als Anwendung, „die im Hintergrund läuft und die Ihnen automatisiert Arbeitsschritte in JTL-Wawi abnimmt — beispielsweise den Abgleich mit Onlineshop und Marktplätzen, um neu eingegangene Bestellungen abzuholen und Änderungen am Artikelbestand zurückzumelden".

Dokumentiert sind vier Aufgabenfelder: der Onlineshop-Abgleich, der Abgleich mit eBay, Amazon und weiteren Verkaufskanälen über JTL-eazyAuction, die Aktualisierung der Währungskurse gegen die Europäische Zentralbank sowie die Anbindung des Kassensystems LS-POS — das ausdrücklich kein JTL-Produkt ist, sondern von der Luwosoft GmbH & Co. KG stammt. Dazu kommt seine Rolle als Motor für zeitversetzte Workflows.

Es gibt kein Abgleichintervall in JTL-Wawi

Eine Frage, die uns regelmäßig gestellt wird, lautet: „Wie oft gleicht die Wawi eigentlich ab?" Die ehrliche Antwort ist: So oft, wie Sie es sagen — und zwar je Aufgabe getrennt. Sie starten jeden gewünschten Abgleich einmalig über Admin > JTL-Worker-Status, Registerkarte Aufgaben. Dort trägt jede Zeile eine eigene Spalte „Intervall" im Format Tage, Stunden, Minuten, Sekunden.

Ein systemweites Standardintervall gibt JTL nicht vor. Belegt ist einzig eine Empfehlung: „Setzen Sie das Intervall auf mindestens 5 Minuten, damit die Serverbelastung minimiert wird." Wer also im Peak über zu langsame Bestandsrückmeldungen klagt, sollte zuerst diese Spalte ansehen, bevor er über Hardware nachdenkt.

Drei Betriebsempfehlungen, die JTL selbst gibt

Erstens: einen eigenen Benutzer anlegen. JTL empfiehlt das ausdrücklich, „vor allem wenn Sie JTL-Worker als Windows-Dienst nutzen möchten", weil ein Passwortwechsel am persönlichen Konto sonst den Worker unterbricht. Empfohlen wird eine Benutzergruppe mit Administratorrechten, damit alle Abgleiche durchlaufen.

Zweitens: den Worker auf dem Datenbankserver starten. So bleibe „die Kommunikationsstrecke zur Datenbank kurz" und der Worker arbeite schneller. Drittens: ihn als Windows-Dienst einrichten, damit er beim Systemstart automatisch mitläuft. Der manuell gestartete Worker muss dagegen dauerhaft geöffnet bleiben — und der Guide warnt, das Fenster zu minimieren statt zu schließen, weil „Schließen" ihn beendet.

Ein Sonderfall am Rande, der viele Stunden kostet: Für den automatisierten Zahlungsabgleich müssen die Zugangsdaten der Bank- und Zahlungsanbieterkonten im Tresor hinterlegt sein, und der Worker-Benutzer braucht die passende Berechtigung. Fehlt eines von beidem, läuft der Worker — der Zahlungsabgleich aber nicht.

5. Ameise, Workflow, Worker oder API? Die Entscheidungsmatrix

JTL-Wawi bringt vier Automatisierungswerkzeuge mit, und sie lösen vier verschiedene Probleme. Die meisten Fehlplanungen entstehen, weil eines für ein Problem eingesetzt wird, das ein anderes lösen müsste. Die Leitfrage ist immer dieselbe: Was löst die Aktion aus?

Zwei Wechselwirkungen sind dabei belegt und wichtig genug, um sie vor der Planung zu kennen. Die erste steht als Warnung in der Ameise-Dokumentation: „Beim Import mit JTL-Ameise darf JTL-Worker nicht aktiv sein. Es kann hierbei zu Störungen und Datenverlust kommen." Ein nächtlicher Import und ein Fünf-Minuten-Abgleich vertragen sich also nicht ohne Planung.

Die zweite betrifft Workflows und Massendaten. Der Guide warnt vor „Perfomancebeeinträchtigungen bei Nutzung der JTL-Ameise" [sic] und erklärt, ein Import könne „möglicherweise eine Vielzahl von Workflows" auslösen, welche „die Performance Ihres Systems wesentlich beeinträchtigen können". Für die Kommandozeile gibt es dafür den Parameter --no_workflows mit der schlichten Beschreibung „Es werden keine Workflows ausgeführt".

Wie die Ameise im Detail funktioniert — von der gespeicherten Vorlage mit ihrer IMP- oder EXP-Kennung bis zur Batch-Datei — behandeln wir getrennt im Beitrag zum Massenimport und -export mit JTL-Ameise. Welche Erweiterungen darüber hinaus sinnvoll sind, ordnet unser Überblick zu JTL-Wawi Plugins ein.

6. Drei Wege zur echten periodischen Prüfung

Zurück zur Ausgangsfrage: Sie brauchen wirklich eine wiederkehrende Prüfung — jeden Morgen, unabhängig davon, ob etwas passiert ist. Drei Wege sind aus der Dokumentation heraus belegbar. Keiner davon ist ein Workflow.

Der erste Weg ist der offiziell dokumentierte. JTL schreibt zur Kommandozeilenfassung der Ameise: „Dadurch ist die grafische Oberfläche nicht mehr notwendig und somit werden Automatismen möglich — etwa über den Windows-Aufgabenplaner." Die Zeitsteuerung liegt damit ausdrücklich bei Windows, nicht bei JTL-Wawi. Ein wichtiger Vorbehalt steht direkt daneben: Je nach gebuchter Edition steht Ihnen die Kommandozeilenfassung „möglicherweise nicht zur Verfügung".

Der zweite Weg bleibt in der Wawi und setzt sich aus zwei dokumentierten Bausteinen zusammen: einem manuellen Workflow-Ereignis und der Aktion „Workflow-Ereignis auslösen", bei der Sie ein Bezugsobjekt und ein Ereignis wählen. Kombiniert mit einem verzögerten Ausführungsplan lässt sich daraus ein Zyklus bauen, der sich selbst wieder aufruft. Wichtig für die Einordnung: JTL dokumentiert die einzelnen Bausteine, nicht diesen Zyklus als Verfahren. Ohne eine sauber gesetzte Abbruchbedingung erzeugen Sie eine Kette, die sich nicht mehr selbst beendet. Wir setzen das nur dort ein, wo die Datenmenge klein und die Abbruchbedingung eindeutig ist.

Der dritte Weg verlässt JTL-Wawi. Ein Ablaufwerkzeug oder eine eigene Anwendung prüft in ihrem eigenen Takt und stößt an, was zu tun ist. Wie ein solcher Ablauf entsteht, zeigt unser n8n-Tutorial Schritt für Schritt. Was dabei technisch über die Leitung geht und worauf Sie bei Anmeldung, Kontingenten und doppelten Meldungen achten müssen, steht im Beitrag zu APIs und Webhooks. Und wenn Sie das Thema unabhängig von JTL betrachten möchten — Werkzeugklassen, Auswahlkriterien, Einführung —, ordnet unser Grundlagenbeitrag zur Workflow-Automatisierung das werkzeugübergreifend ein; hier auf dieser Seite geht es ausschließlich um das Werkzeug, das in der Wawi selbst steckt.

7. Manuelle Workflow-Ereignisse: der übersehene Hebel

Es gibt eine Funktion, die genau die Lücke füllt, an der die meisten Projekte zuerst scheitern — und sie wird selten genutzt. Neben den fest vorgegebenen Ereignissen können Sie eigene anlegen, die Sie selbst auslösen. Ereignisgruppen, die das erlauben, erkennen Sie im Baum am Zusatz „Manuell", etwa „Artikel — Manuell".

Der Guide nennt den entscheidenden Anwendungsfall: Sie haben einen Workflow für neu angelegte Artikel gebaut und möchten ihn nun auch auf den Bestand anwenden. Über ein manuelles Ereignis markieren Sie beliebig viele vorhandene Datensätze und lösen die Aktionen per Klick aus. Damit erreichen Sie rückwirkend, was das automatische Ereignis nur nach vorne kann.

Zwei Details gehören dazu. Erstens: „Alle Workflows, die zu einem Ereignis gehören, werden immer zusammen durchgeführt." Ein manuelles Ereignis ist also ein Sammelschalter, kein Einzelaufruf. Zweitens eine dokumentierte Lücke, die man vorher kennen sollte: „Manuelle Workflow-Ereignisse stehen Ihnen nicht für den Warenlagereingang und -ausgang sowie für Eingangsrechnungen zur Verfügung."

In unseren Projekten ist das der pragmatischste Kompromiss, wenn eine echte Zeitsteuerung fehlt: Die Prüfung wird nicht automatisch angestoßen, aber sie dauert einen Klick statt einer halben Stunde Handarbeit. Für viele Abläufe reicht das vollkommen — und es ist deutlich robuster als ein selbstaufrufender Zyklus.

8. Fünf Stolpersteine, die im Betrieb Geld kosten

Die folgenden fünf Punkte begegnen uns in Bestandssystemen immer wieder. Vier davon stehen so oder sinngemäß in der Dokumentation — sie werden nur selten gelesen, bevor gebaut wird.

• Der Worker läuft während des Imports. JTL warnt vor Störungen und Datenverlust. Legen Sie automatisierte Importe in ein Zeitfenster, in dem der Worker nachweislich steht — und prüfen Sie, ob er danach wieder anläuft.
• Der Import löst eine Workflow-Lawine aus. Wenn die Ameise im Geltungsbereich eines Workflows freigeschaltet ist, kann ein Massenimport tausende Läufe erzeugen. Der Guide empfiehlt dafür „gesonderte und zeitversetzte Workflows"; auf der Kommandozeile hilft --no_workflows.
• Der Worker wurde geschlossen statt minimiert. Beim manuell gestarteten Worker beendet die Schaltfläche „Schließen" das Programm. Danach laufen weder Abgleiche noch zeitversetzte Workflows — lautlos. Als Windows-Dienst tritt das Problem nicht auf.
• Die Edition gibt weniger her als das Konzept. Der Guide weist gleich an mehreren Stellen darauf hin, dass Anzahl und Art der erstellbaren Ereignisse editionsabhängig sein können. Klären Sie das, bevor Sie planen, nicht danach.
• Der Workflow ging ungetestet in Betrieb. Die Verwaltung bringt einen Testlauf mit: Über „Workflow testen" wählen Sie ein Testobjekt und können den Lauf erst simulieren und dann ausführen. Eine Checkbox schaltet einen Workflow zudem temporär ab, ohne ihn zu löschen. Fehler und Prozessverläufe finden Sie unter Admin > Hintergrundprozesse.

Zur Editionsfrage noch eine Anmerkung in eigener Sache: JTL veröffentlicht die genauen Grenzen je Edition in einer Feature-Übersicht auf der Preisseite. Diese Tabelle wird erst im Browser aufgebaut und war für uns am Abrufdatum nicht maschinell prüfbar. Wir geben deshalb keine Zellwerte wieder, die wir nicht selbst gegengelesen haben. Belegbar ist, dass JTL den „vollen Workflow-Umfang inkl. Custom Workflows" erst der Edition Pro zuschreibt. Sehen Sie die Übersicht bitte selbst an oder prüfen Sie Ihre gebuchte Konfiguration im Kundencenter.

9. Die JTL-Wawi API: Open Beta, kein Ersatz für die Zeitsteuerung

Bleibt das vierte Werkzeug. Die JTL-Wawi API wird oft als saubere Lösung für alles genannt, was Workflows nicht können — und das stimmt technisch. Nur ist ihr Status am Bautag ein anderer, als viele Beiträge vermuten lassen, weshalb wir ihn am 7. September 2026 noch einmal an der Quelle geprüft haben.

JTL beschreibt sie als „REST-konforme Schnittstelle, die als technische Grundlage für eine einfache und flexible Anbindung von Drittsystemen dient". Auf der Seite zur Lizenzbuchung steht jedoch unverändert: „Die JTL-Wawi API befindet sich derzeit in der Open-Beta-Phase. Bis zum offiziellen Release nutzen Sie die Schnittstelle im Rahmen des Pilotprogramms kostenfrei." Die Teilnahme am Pilotprogramm ist Voraussetzung für die Buchung; sie läuft über das Kundencenter unter Partnerbereich > Pilotprogramm.

Ebenfalls im selben Hinweis: Je nach gebuchter Edition steht die Schnittstelle „nach dem offiziellen Release möglicherweise nicht zur Verfügung". Auf der Preisseite taucht sie als Verkaufsargument erst in der höchsten Edition auf, dort formuliert als „Individuelle Prozessoptimierung mit REST-API (Beta)". Wer heute darauf setzt, sollte das im Bewusstsein tun, dass sich Verfügbarkeit und Konditionen nach dem Release ändern können.

Der zweite Punkt betrifft den Betrieb. Die API ist keine Adresse, die einfach da ist. Der Guide führt eigene Anleitungen dafür, eine „Instanz der JTL-Wawi API" im JTL-Administrator einzurichten — wahlweise für den manuellen Start, den automatischen Start oder den Start über die Kommandozeile. Sie betreiben also einen zusätzlichen Dienst und müssen ihn überwachen.

Umgekehrt kann die Schnittstelle Workflows sogar anstoßen. Die Spezifikation der API-Version 2.0 enthält Endpunkte, die manuelle Workflows für Aufträge, Rechnungen und Kunden auslösen, dazu Workflow-Ereignisse auch für Lieferscheine. Ein Zeitgeber außerhalb der Wawi ruft den Endpunkt dann zur gewünschten Uhrzeit auf, die Logik bleibt als Workflow in der Wawi. Wie das aussieht und was es voraussetzt, beschreibt unser Beitrag zur JTL-Wawi API.

Unser Rat aus der Projektpraxis: Behandeln Sie die Schnittstelle als Projekt, nicht als Häkchen. Sie ist die richtige Antwort, wenn ein Drittsystem dauerhaft mitspielen soll oder die Logik zu komplex für Bedingungsfelder wird. Für eine einzelne wiederkehrende Prüfung ist der Windows-Aufgabenplaner die schnellere und billigere Lösung. Wenn Sie abwägen möchten, welcher Weg für Ihre Prozesse trägt, sehen wir uns Ihre JTL-Wawi und ihre Abläufe gemeinsam an; für Anbindungen an Drittsysteme beschreibt unsere Seite zu n8n und API-Entwicklung, wie wir vorgehen.

10. Fazit: erst die Auslösefrage, dann das Werkzeug

JTL-Workflows sind ein starkes Werkzeug — für Reaktionen. Sobald etwas in der Wawi passiert, prüfen sie Bedingungen und handeln, zuverlässig und ohne Zusatzsoftware. Was sie nicht können, ist von selbst anfangen. Diese eine Eigenschaft entscheidet über die halbe Automatisierungsplanung.

Deshalb steht am Anfang jedes Konzepts eine einzige Frage: Was löst die Aktion aus? Ist es ein Ereignis in der Wawi, bauen Sie einen Workflow. Ist es eine Uhrzeit, brauchen Sie den Windows-Aufgabenplaner mit der Ameise, einen bewusst gebauten Selbstaufruf oder ein Werkzeug außerhalb. Ist es ein Fremdsystem, führt der Weg über die Schnittstelle. Und in allen drei Fällen läuft im Hintergrund der Worker mit, dessen Intervalle Sie kennen sollten.

Wer diese Frage vor dem ersten Klick beantwortet, spart sich den teuersten Umweg im JTL-Alltag: einen sauber gebauten Workflow, der niemals startet.

11. Häufige Fragen zu JTL-Workflows und JTL-Worker

Kann ein JTL-Workflow zeitgesteuert starten?

Nein. Jeder JTL-Workflow braucht laut Hersteller-Dokumentation ein auslösendes Ereignis. Der Ausführungsplan legt nur fest, wann nach diesem Ereignis gearbeitet wird — er startet nichts von selbst. Tritt kein Ereignis ein, passiert auch zur eingestellten Uhrzeit nichts. Für echte periodische Prüfungen brauchen Sie einen Weg außerhalb der Workflow-Verwaltung.

Wozu dient der Ausführungsplan in JTL-Workflows?

Er verschiebt den Startzeitpunkt nach hinten. Die Standardeinstellung „Sofort" startet den Workflow unmittelbar beim Eintritt des Ereignisses. Alternativ sammeln Sie Vorgänge und lassen sie gebündelt laufen, etwa jeden Abend zu einer festen Uhrzeit. Für jede verzögerte Ausführung muss der JTL-Worker laufen — sonst bleibt der Workflow liegen.

Wofür brauche ich den JTL-Worker?

Für zwei Dinge. Erstens für jeden zeitversetzten Workflow: Ohne laufenden Worker wird er nicht ausgeführt. Zweitens für die automatischen Abgleiche mit Onlineshop, Marktplätzen und Zahlungsanbietern sowie für die Aktualisierung der Währungskurse. Sofort-Workflows laufen dagegen ereignisgesteuert und benötigen den Worker nicht.

Wie oft gleicht der JTL-Worker ab?

So oft, wie Sie es je Aufgabe einstellen. JTL gibt kein festes Intervall vor: In der Registerkarte „Aufgaben" trägt jeder Abgleich seinen eigenen Wert in der Spalte „Intervall". Belegt ist nur die Empfehlung, mindestens fünf Minuten zu wählen, damit die Serverbelastung gering bleibt.

Warum darf der JTL-Worker beim Ameise-Import nicht laufen?

Weil JTL davor ausdrücklich warnt. Der Guide schreibt, beim Import mit JTL-Ameise dürfe JTL-Worker nicht aktiv sein, es könne sonst zu Störungen und Datenverlust kommen. Planen Sie automatisierte Importe deshalb so, dass Worker und Import sich zeitlich nicht überschneiden. Prüfen Sie anschließend, ob der Worker wirklich wieder anläuft.

Was sind manuelle Workflow-Ereignisse in JTL-Wawi?

Selbst angelegte Ereignisse, die Sie per Klick auslösen statt automatisch. Sie erkennen die passenden Gruppen am Zusatz „Manuell". Damit wenden Sie einen Workflow auch auf bereits vorhandene Datensätze an. Für Warenlagereingang, Warenlagerausgang und Eingangsrechnungen stehen manuelle Ereignisse laut Dokumentation nicht zur Verfügung.

Welche Aktionen kann ein JTL-Workflow ausführen?

In der Dokumentation belegt sind fünf Aktionsarten: „Ausführen", „E-Mail senden", „Ausgabe", „Werte setzen" und „Workflow-Ereignis auslösen". Die Doku nennt sie ausdrücklich beispielhaft, eine vollständige Liste veröffentlicht JTL nicht. „Ausführen" startet ein externes Programm oder Skript und übergibt ihm Werte aus JTL-Wawi.

Kann die JTL-Wawi API die fehlende Zeitsteuerung ersetzen?

Technisch ja, organisatorisch nur eingeschränkt. Die Schnittstelle befand sich am 7. September 2026 laut JTL weiterhin in der Open-Beta-Phase und setzt die Teilnahme am Pilotprogramm voraus. Sie läuft außerdem als eigene Instanz, die Sie im JTL-Administrator starten. Planen Sie sie als Projekt, nicht als Einstellung.

Hängt der Workflow-Umfang von der JTL-Edition ab?

Ja. Der Guide weist an mehreren Stellen darauf hin, dass Anzahl und Art der erstellbaren Ereignisse je nach gebuchter Edition beschränkt sein können. JTL bewirbt den vollen Workflow-Umfang erst ab der Edition Pro. Prüfen Sie die Feature-Übersicht daher vor der Konzeption, nicht danach.

12. Quellen & Hersteller-Dokumentation

Alle wurden am 7. September 2026 abgerufen und inhaltlich gegengelesen. Externe Quellen öffnen in einem neuen Tab.

• JTL-Guide — Einleitung zur Workflow-Verwaltung — Grundlage für das Muster aus Ereignis, Bedingung und Aktion, die fünf Fensterbereiche, den Ausführungsplan mit der Einstellung „Sofort" und dem Beispiel zur festen Uhrzeit, die Option „Nur letzten ausführen", die Warnung zum notwendigen Worker sowie die Aktionsarten und den Testlauf.
• JTL-Guide — Manuelle Workflow-Ereignisse — der wörtliche Beleg dafür, dass jeder Workflow ein auslösendes Ereignis benötigt; dazu die Aktionsart „Werte setzen", der Zusatz „Manuell" an Ereignisgruppen, die gemeinsame Ausführung aller Workflows eines Ereignisses und die Einschränkung für Warenlagereingang, Warenlagerausgang und Eingangsrechnungen.
• JTL-Guide — Manuelles Workflow-Ereignis per Workflow auslösen — dokumentiert die Aktionsart „Workflow-Ereignis auslösen" mit Bezugsobjekt und Ereignis, den Baustein des im Beitrag beschriebenen Selbstaufrufs.
• JTL-Guide — Automatisierung mit JTL-Worker — Definition des Workers und seine dokumentierten Aufgaben: Onlineshop-Abgleich, Abgleich mit eBay, Amazon und weiteren Verkaufskanälen, Währungskurse gegen die Europäische Zentralbank und die Anbindung des Fremdprodukts LS-POS.
• JTL-Guide — Abgleiche mit JTL-Worker 2.0 automatisieren — Quelle für die Intervallspalte je Aufgabe, die Empfehlung von mindestens fünf Minuten, den eigenen Worker-Benutzer, den Start auf dem Datenbankserver, den Betrieb als Windows-Dienst, den Hinweis zum Minimieren statt Schließen sowie die Voraussetzungen des Zahlungsabgleichs.
• JTL-Guide — Übersicht über JTL-Ameise — enthält die Warnung, dass JTL-Worker beim Import mit JTL-Ameise nicht aktiv sein darf, weil es sonst zu Störungen und Datenverlust kommen kann.
• JTL-Guide — CMD-Line-Version von JTL-Ameise — belegt die Automatisierung über den Windows-Aufgabenplaner, den Editionsvorbehalt zur Kommandozeilenfassung, die Vorlagenkennungen mit IMP und EXP sowie den Parameter, mit dem Workflows beim Import unterdrückt werden.
• JTL-Guide — Lizenz für JTL-Wawi API buchen — der am 7. September 2026 geprüfte Status: Open-Beta-Phase, kostenfreie Nutzung im Rahmen des Pilotprogramms, Teilnahme über das Kundencenter und der Vorbehalt zur Verfügbarkeit nach dem Release je nach Edition.
• JTL-Guide — JTL-Wawi API — Beschreibung als REST-konforme Schnittstelle und Nachweis der Anleitungen zum Einrichten einer eigenen Instanz im JTL-Administrator, wahlweise mit manuellem Start, automatischem Start oder Start über die Kommandozeile.
• JTL-Software — Preise und Tarife — Quelle der beiden im Beitrag genannten Editionsaussagen. Die vollständige Feature-Übersicht wird erst im Browser aufgebaut und war für uns am Abrufdatum nicht maschinell prüfbar; deshalb geben wir daraus keine Einzelwerte wieder.