n8n 4 weclapp: Lieferscheine automatisch erstellen

Bevor gepackt wird, braucht jede Lieferung ihren Lieferschein. In weclapp erstellst du ihn je Lieferung über „Lieferschein erstellen“ oder gesammelt im Druckinterface, und zwar erst, wenn die Ware komplett da ist. Diese Seite zeigt, wie der Agent diesen Schritt übernimmt, welche Lieferungen er nimmt, was bei Fehlern passiert und wie du ihn einrichtest.

Das Wichtigste in Kürze

• Der Agent setzt den Status, sonst nichts. Er ändert an der Lieferung nur status von NEW auf DELIVERY_NOTE_PRINTED, in der Oberfläche „Lieferschein erstellt“.
• Nur vollständig verfügbare Ware. Er fragt Lieferungen mit status-eq=NEW und availability-eq=COMPLETELY_AVAILABLE ab, die älteste zuerst; teilweise verfügbare Lieferungen lässt er liegen.
• Altbestand bleibt unberührt. Der Agent nimmt nur Lieferungen, die ab dem Stichtag cutoffDate angelegt wurden, und läuft erst, wenn du ihn gesetzt hast. Nach dem Import steht er im Probelauf und meldet nur, was er täte.
• Kein Warten auf den Sammeldurchgang. Der Agent läuft alle 10 Minuten; jede passende Lieferung hat spätestens im nächsten Lauf ihren Lieferschein.
• Die Ersparnis wächst mit der Menge. Im Rechenbeispiel unten mit 4.000 Lieferungen im Monat fallen rund 40 Stunden Handarbeit im Jahr weg, bei 50.000 rund 400 Stunden. Deine Zahlen hängen von deinem Ablauf ab.
• Fehler werden gemeldet. Eine gescheiterte Lieferung bleibt auf „Neu“, der nächste Lauf versucht es erneut, und du bekommst eine Fehlermail, dieselbe Meldung höchstens einmal in 24 Stunden.

Wie viel sparst du mit dem Agent?

Von Hand ist der Aufwand ein Durchgang: Lieferungen filtern, die vollständig verfügbaren markieren, Lieferscheine erstellen lassen, Ergebnis prüfen. Der Agent ersetzt diese Durchgänge. Ein Rechenbeispiel für einen Betrieb mit 4.000 Lieferungen im Monat, mit den Annahmen unter den Tabellen:

Kennzahl	Von Hand	Mit dem Agent	Ersparnis
Zeit je Durchgang	5 Minuten (Schätzwert)	0 Minuten	5 Minuten
Durchgänge pro Monat	40 (2 je Versandtag)	keine, der Agent läuft alle 10 Minuten	40
Zeit pro Monat	3,3 Stunden	0 Stunden	3,3 Stunden
Lohnkosten pro Jahr	750 €	0 €	750 €
Wartezeit bis zum Lieferschein	bis zum nächsten Durchgang	bis zum nächsten Lauf, in der Regel höchstens 10 Minuten	qualitativ
Fehlerquelle	Lieferung übersehen, teilweise verfügbare Lieferung mit markiert	prüft in jedem Lauf die neuen Lieferungen ab dem Stichtag, nimmt nur vollständig verfügbare, meldet Fehler per Mail	qualitativ

Für andere Mengen:

Lieferungen im Monat	100	1.000	4.000	10.000	50.000
Durchgänge im Monat	20	20	40	80	400
Von Hand: Zeit im Monat	1,6 h	1,6 h	3,3 h	6,6 h	33,3 h
Von Hand: Zeit im Jahr	20 h	20 h	40 h	80 h	400 h
Ersparnis im Jahr	375 €	375 €	750 €	1.500 €	7.500 €

So ist gerechnet (Annahmen, nicht gemessen): 20 Versandtage im Monat, je Versandtag ein Durchgang je angefangene 125 Lieferungen des Tages, mindestens einer. 5 Minuten je Durchgang, ein Schätzwert. Lohnkosten mit 18,75 € pro Stunde, das entspricht 3.000 € brutto im Monat bei 160 Arbeitsstunden, ohne Lohnnebenkosten; mit Lohnnebenkosten wäre die Ersparnis höher. Setz für deinen Betrieb deine eigenen Werte ein. Werte abgerundet. Fehlerbearbeitung, Drucken und der Betrieb von n8n sind nicht eingerechnet.

Fazit: Bei kleinen Mengen bringt der Agent vor allem Tempo, bei großen Mengen kann er im Jahr Hunderte Stunden Handarbeit ersetzen.

Wie arbeitet der Agent?

Der Agent läuft in fünf Schritten, jeder als eigener Node in n8n:

1. Start: alle 10 Minuten über den Node „Every 10 minutes“ oder von Hand über „Manual start“.
2. Einstellungen prüfen: „Check settings“ bricht ab, solange in Constants Platzhalter, ein ungültiger Stichtag oder ein dryRun ohne true/false stehen. Dann fragt der Agent weclapp gar nicht erst.
3. Lieferungen holen: „Get new shipments (fully available)“ liest neue Lieferungen mit vollständig verfügbarer Ware ab dem Stichtag, sortiert nach createdDate, die älteste zuerst. Das Lesen wiederholt er bei einem Fehler bis zu 3-mal im Abstand von 5 Sekunden.
4. Lieferschein erstellen: „Select shipments“ prüft jede Lieferung noch einmal. Im Probelauf endet der Lauf hier in „Dry run: nothing changed“ und meldet, was er täte. Sonst setzt „Create delivery note“ jede Lieferung einzeln auf DELIVERY_NOTE_PRINTED, mit einer Pause von 1 Sekunde vor jeder Lieferung (pauseSeconds).
5. Zusammenfassen: „Summary“ zählt erstellte Lieferscheine und Fehler. Gab es Fehler, geht eine Mail raus und der Lauf endet als fehlgeschlagen.

Der Agent in n8n: unten die Schleife über die Lieferungen, oben der Fehlerpfad mit Zusammenfassung und Fehlermail.

Fazit: Eine Prüfung, eine Abfrage, ein Statuswechsel je Lieferung, eine Mail bei Fehlern.

Welche Lieferungen nimmt der Agent?

Der Agent nimmt Lieferungen, die in weclapp im Status „Neu“ (NEW) stehen und deren Verfügbarkeit „vollständig verfügbar“ ist (Filter availability mit dem Wert COMPLETELY_AVAILABLE). Die anderen Werte des Filters, PARTIALLY_AVAILABLE, NOTHING_AVAILABLE, TRANSFER_REQUIRED und NOT_CHECKED, lässt er aus.

• Stichtag: nur Lieferungen, die am cutoffDate oder später angelegt wurden (Mitternacht deutscher Zeit). Setz den Stichtag auf heute, sonst nimmt der Agent auch alte Lieferungen, die noch auf „Neu“ stehen. Solange der Platzhalter drinsteht, läuft er nicht.
• Menge je Lauf: höchstens 10 Lieferungen (maxShipmentsPerRun, 1 bis 999). Liegen mehr bereit, nimmt er die ältesten und meldet in der Fehlermail, falls eine kommt, dass weitere warten. Erhöhen erst, wenn du ihn eine Weile beobachtet hast.
• Doppelte Sicherheit: Vor dem Statuswechsel prüft „Select shipments“ jeden Datensatz noch einmal auf NEW, vollständige Verfügbarkeit und Anlagedatum und nimmt jede Lieferung nur einmal.
• Bewusst nicht: Lieferungen in anderen Status, teilweise verfügbare Lieferungen, Drucken, Mailversand und Versandetiketten. Retourenetiketten übernimmt der Agent Retourenetiketten automatisch erstellen, Versandetiketten am Packtisch Fulfillment 4 weclapp.

Fazit: Was vor dem Stichtag angelegt wurde oder nicht vollständig verfügbar ist, bleibt auf „Neu“.

Was macht „Lieferschein erstellt“ in weclapp?

„Lieferschein erstellt“ ist ein Status der Lieferung, kein Druckauftrag. Laut weclapp-Doku sind Erstellen und Drucken getrennte Schritte: Gedruckt wird über „Dokumente drucken“ oder das Druckinterface. Im Tab „Versenden“ der mobilen Lager-App erscheinen Lieferungen mit „Wird erfasst“ und „Lieferschein erstellt“.

Den Lieferschein selbst legt weclapp beim Statuswechsel an: Im Test in einem weclapp-Testmandanten lagen danach an jeder Lieferung die Lieferschein-PDFs als Dokumente (Typ SHIPMENT_DELIVERY_NOTE), abrufbar auch über GET /shipment/id/{id}/downloadLatestDeliveryNotePdf. Willst du den Lieferschein automatisch verschicken, richte in weclapp eine Beleg-E-Mail-Versandregel ein: Die weclapp-API kennt dafür das Ereignis SHIPMENT_DELIVERY_NOTE_PRINTED.

Fazit: Der Agent stößt den Lieferschein an, weclapp erzeugt das PDF und druckt oder verschickt nach deinen Einstellungen.

Was passiert bei einem Fehler?

Scheitert der Statuswechsel einer Lieferung, etwa weil weclapp ihn ablehnt, geht die Lieferung über den Fehlerausgang an „Record error“. Der Agent wiederholt den Statuswechsel nicht im selben Lauf und ändert die Lieferung nicht. Steht sie noch auf „Neu“, kommt sie im nächsten Lauf wieder dran. Eine Lieferung, die zwischen Abfrage und Statuswechsel storniert wurde, lehnt weclapp ab (status update not possible); sie bleibt storniert.

• Fehlermail: oben, was zu tun ist und was danach passiert, darunter eine Tabelle mit Lieferungsnummer und Grund je Lieferung, Zeitpunkt und Link auf die Ausführung in n8n; mit HTML- und Textteil, lesbar in Outlook und Gmail, hell und dunkel. Betreff: Delivery notes: 2 shipments without delivery note. Eine Zeile sieht zum Beispiel so aus: HTTP 400: status update not possible – Generation of shipping note not possible.
• Gedrosselt: Dieselbe Meldung zur selben Lieferung kommt höchstens einmal in errorMailRepeatHours (Standard 24 Stunden), sonst bekämst du sie alle 10 Minuten. Die Drosselung liegt in den statischen Daten des Workflows; n8n speichert sie nur bei veröffentlichten Workflows, nicht bei Testläufen.
• Sichtbar: Ein Lauf mit Fehlern endet über „Stop with errors“ als fehlgeschlagen und steht in der Ausführungsliste von n8n, auch wenn die Mail gedrosselt ist.

Fazit: Eine fehlerhafte Lieferung blockiert keine andere, und du erfährst davon, ohne zugespammt zu werden.

Wie richtest du den Agent ein?

Du brauchst:

• n8n, selbst gehostet oder in der Cloud;
• einen weclapp-API-Token eines Benutzers, der Lieferungen bearbeiten darf;
• für die Fassung mit Community-Node das Paket @wals-pro/n8n-nodes-weclapp;
• ein SMTP-Konto für die Fehlermail.

So richtest du es ein:

1. Agent importieren: in n8n „Import from File“ und die JSON-Datei der passenden Fassung wählen.
2. weclapp-Zugang: mit Community-Node ein Credential Weclapp API (Base URL https://<dein-mandant>.weclapp.com/webapp/api/v2, API-Token) an beiden weclapp-Nodes; in der HTTP-Fassung weclappBaseUrl in Constants und ein Credential Header Auth mit dem Namen AuthenticationToken und deinem Token als Wert.
3. Constants füllen: cutoffDate (meist heute), maxShipmentsPerRun (Standard 10), pauseSeconds, emailFrom, emailRecipientList, errorMailRepeatHours und n8nBaseUrl.
4. SMTP-Credential an „Send error email“ hängen.
5. Probelauf: dryRun steht nach dem Import auf true. „Manual start“ ausführen und in „Select shipments“ prüfen, welche Lieferungen er nehmen würde; geändert wird nichts. Am besten zuerst gegen einen Testmandanten.
6. dryRun auf false, einmal von Hand laufen lassen, dann veröffentlichen.

Jeden Schritt, jede Konstante und jede Fehlermeldung erklärt die Anleitung im Download.

Fazit: Zwei Credentials, ein Stichtag, ein Probelauf, dann scharf.

Wie sieht der Aufruf an die weclapp-API aus?

Die HTTP-Fassung macht zwei Aufrufe gegen die weclapp REST API v2. Zum Nachvollziehen mit curl, Platzhalter in spitzen Klammern:

curl -G "https://<dein-mandant>.weclapp.com/webapp/api/v2/shipment" \
  -H "AuthenticationToken: <dein-token>" \
  --data-urlencode "status-eq=NEW" \
  --data-urlencode "availability-eq=COMPLETELY_AVAILABLE" \
  --data-urlencode "createdDate-ge=<Stichtag in Millisekunden>" \
  --data-urlencode "sort=createdDate" \
  --data-urlencode "properties=id,shipmentNumber,status,createdDate" \
  --data-urlencode "additionalProperties=availability" \
  --data-urlencode "pageSize=11"

Die Antwort steht in result, je Lieferung mit id, shipmentNumber, status und createdDate; die Verfügbarkeit liefert weclapp daneben im Block additionalProperties, damit der Agent sie noch einmal prüfen kann. pageSize ist das Limit plus 1: Kommt eine Lieferung mehr zurück, warten weitere. Dann je Lieferung der Statuswechsel:

curl -X PUT "https://<dein-mandant>.weclapp.com/webapp/api/v2/shipment/id/<id>?ignoreMissingProperties=true" \
  -H "AuthenticationToken: <dein-token>" \
  -H "Content-Type: application/json" \
  -d '{"status": "DELIVERY_NOTE_PRINTED"}'

Mit ignoreMissingProperties=true ändert weclapp nur die mitgeschickten Felder; alle anderen Felder der Lieferung bleiben, wie sie sind.

Fazit: Ein GET mit drei Filtern und ein PUT mit einem Feld – mehr braucht es nicht.

Steckbrief

Was	Lieferscheine für weclapp-Lieferungen erstellen (Status „Lieferschein erstellt“)
Auslöser	alle 10 Minuten, zusätzlich manuell
Auswahl	Status NEW, Verfügbarkeit COMPLETELY_AVAILABLE, angelegt ab Stichtag cutoffDate, älteste zuerst
Schutz	läuft erst mit gesetztem Stichtag und Mailadressen; startet im Probelauf (dryRun); prüft jede Lieferung vor dem Schreiben noch einmal
Menge je Lauf	höchstens 10 Lieferungen (maxShipmentsPerRun), der Rest im nächsten Lauf
Tempo	eine Lieferung nach der anderen, 1 Sekunde Pause dazwischen (pauseSeconds)
Ergebnis	status = DELIVERY_NOTE_PRINTED; weclapp legt dabei das Lieferschein-PDF an, sonst keine Änderung an der Lieferung
Fehler	Lieferung bleibt auf „Neu“, nächster Lauf versucht erneut, gedrosselte Fehlermail, Lauf endet als fehlgeschlagen
Grenzen	druckt nicht, verschickt nicht, keine Teillieferungen, keine Lieferungen vor dem Stichtag
Fassungen	mit Community-Node @wals-pro/n8n-nodes-weclapp und mit HTTP-Request-Nodes (weclapp REST API v2)
Version	1.1 vom 04.11.2026

Fazit: Ein kleiner Agent mit einer klaren Aufgabe und einem klaren Fehlerweg.

Was ist im Download?

• Anleitung als PDF: Einrichtung, alle Konstanten, Testen, Aktivieren und jede Fehlermeldung mit Lösung.
• Agent mit Community-Node: create-delivery-notes.weclapp-node.json für n8n mit installiertem @wals-pro/n8n-nodes-weclapp.
• Agent als HTTP-Fassung: create-delivery-notes.http.json für n8n ohne Community-Nodes, zum Beispiel n8n Cloud.

Der Agent kostet nichts: Du schließt die Bestellung zu 0 € ab und bekommst den Download-Link mit der Bestellbestätigung per Mail und auf der Bestellstatusseite.

Fazit: Beide Fassungen tun dasselbe – nimm die, die zu deiner n8n-Instanz passt.

Was passt dazu?

• Auftragsabwicklung auf Autopilot: Der kostenlose Agent geht vom Auftrag bis zur gebuchten Rechnung und legt Lieferungen gleich mit Lieferschein an. Für diese Lieferungen brauchst du den Lieferschein-Agent nicht; er ist für Lieferungen gedacht, die anders entstehen, etwa aus deinem Shop oder von Hand.
• Retourenetiketten automatisch erstellen: Der kostenlose Agent legt jeder Lieferung auf „Neu“ oder „Lieferschein erstellt“ ein Retourenetikett bei, direkt über DHL oder über deine weclapp-Integration (shipcloud, sendcloud, DHL).
• Fulfillment 4 weclapp: der nächste Schritt nach dem Lieferschein: Versand mit Scan am Packtisch und Labels von mehr als 14 Versanddienstleistern.
• Weiterlesen: Lieferschein scannen, Label drucken, papierlos packen mit weclapp und weclapp automatisieren: alle Bausteine.

Fazit: Der Lieferschein-Agent deckt einen Schritt ab; mit Autopilot und Retouren-Agent wird daraus eine durchgehende Kette.

Quellen und Grenzen

• weclapp: Wie versende ich Lieferungen mit der mobilen Lager-App?, zu „Lieferschein erstellen“, „Dokumente drucken“ und den Status „Wird erfasst“ und „Lieferschein erstellt“, abgerufen am 03.11.2026.
• weclapp REST API v2 (OpenAPI-Beschreibung): Endpunkte GET /shipment und PUT /shipment/id/{id}, Filter availability, Status DELIVERY_NOTE_PRINTED, Ereignis SHIPMENT_DELIVERY_NOTE_PRINTED, Stand 16.10.2026.
• n8n: getWorkflowStaticData, statische Daten nur bei veröffentlichten Workflows, abgerufen am 04.11.2026.
• Eigener Test beider Fassungen in einem weclapp-Testmandanten am 03.11.2026: Auswahl, Mengengrenze, Statuswechsel, Lieferschein-PDF, Fehlerfälle (stornierte und gelöschte Lieferung).
• Eigener Test der Schutzfunktionen (HTTP-Fassung) im selben Testmandanten am 04.11.2026: Abbruch bei Platzhaltern, Probelauf ohne Änderung, Mengengrenze, Stichtag; ein Probelauf über den ganzen Mandanten ließ rund 2.600 ältere Lieferungen im Status „Neu“ unberührt.

Der Agent passt nicht, wenn du Lieferscheine bewusst auch für Teillieferungen erstellen willst, wenn die Verfügbarkeit in deinem weclapp nicht gepflegt ist oder wenn der Lieferschein erst nach einer Freigabe von Hand entstehen soll. Die Verfügbarkeit berechnet weclapp; der Agent übernimmt sie, wie sie ist.

Fazit: Für Lieferungen, die komplett aus dem Lager gehen, ist der Agent gebaut, für alles andere ist er ein Ausgangspunkt.

Häufige Fragen

Druckt der Agent die Lieferscheine?

Nein. Er setzt die Lieferung auf „Lieferschein erstellt“, weclapp legt dabei das Lieferschein-PDF an der Lieferung ab. Gedruckt wird in weclapp über „Dokumente drucken“ oder das Druckinterface, verschickt über eine Beleg-E-Mail-Versandregel.

Was passiert mit Lieferungen, bei denen nur ein Teil der Ware da ist?

Nichts. Der Agent nimmt nur Lieferungen mit der Verfügbarkeit „vollständig verfügbar“. Sobald die restliche Ware da ist, erstellt er den Lieferschein im nächsten Lauf.

Wie merke ich, wenn ein Lieferschein nicht erstellt wurde?

Du bekommst eine Fehlermail mit Lieferungsnummer und Fehlermeldung, dieselbe Meldung höchstens einmal in 24 Stunden. Zusätzlich endet der Lauf in n8n als fehlgeschlagen.

Kann der Agent alle offenen Lieferungen auf einmal abarbeiten?

Er nimmt je Lauf bis zu 10 Lieferungen, die ältesten zuerst, und den Rest 10 Minuten später. Die Grenze stellst du mit maxShipmentsPerRun ein, höchstens 999. Lieferungen, die vor dem Stichtag angelegt wurden, nimmt er nie; die arbeitest du von Hand ab oder setzt den Stichtag bewusst früher.

Kann ich vorher sehen, was der Agent tun würde?

Ja. Nach dem Import steht dryRun auf true: Der Agent liest nur und listet in „Select shipments“ die Lieferungen, die er umstellen würde. Erst mit dryRun auf false ändert er etwas.

Brauche ich den Community-Node von wals.pro?

Nein. Die HTTP-Fassung ruft die weclapp REST API v2 mit Bordmitteln von n8n auf und läuft auch dort, wo keine Community-Nodes erlaubt sind. Die Fassung mit Community-Node ist in n8n leichter zu lesen und anzupassen.

Kann wals.pro die Einrichtung für mich übernehmen?

Ja, sprich uns an. Im Erstgespräch klären wir, wie dein Versandprozess aussieht und wie der Agent am besten zu deinem weclapp passt.