n8n 4 weclapp Autopilot

Zwischen Bestellung und gebuchter Rechnung steht in weclapp für jeden Standardauftrag dieselbe Klickfolge: Auftragsbestätigung, Lieferung, Lieferschein, Rechnung, Buchung. Bei ein paar Aufträgen am Tag geht das nebenbei, bei hundert bleibt es liegen oder wird vergessen. Diese Seite zeigt, wie der Agent die Klickfolge übernimmt, welche Aufträge er nimmt, was bei Fehlern passiert und wie du ihn einrichtest.

Das Wichtigste in Kürze

• Altbestand bleibt unberührt. Der Agent nimmt nur Aufträge und Rechnungen ab dem Stichtag startDate und läuft erst, wenn du ihn gesetzt hast. Nach dem Import steht er im Probelauf, nur Stufe 1 ist an, und er meldet nur, was er täte.
• Vier Stufen in einem Lauf. Der Agent arbeitet die Stufen nacheinander ab, so dass ein Auftrag im besten Fall in einem einzigen Lauf von der Bestätigung bis zur gebuchten Rechnung kommt. Läuft der Auftrag über einen Fulfillment-Dienstleister, folgt die Rechnung erst im Lauf, nachdem er versendet ist.
• Er prüft, bevor er anlegt. Vor jeder neuen Lieferung und jeder neuen Rechnung fragt er weclapp, ob es zum Auftrag schon eine gibt, und merkt sich das Ergebnis in einem Zusatzfeld am Auftrag.
• Du behältst die Kontrolle. Ein Ja/Nein-Zusatzfeld nimmt einzelne Aufträge oder Rechnungen aus, ganze Vertriebswege lassen sich von der Rechnung ausnehmen, und jede Stufe hat einen eigenen Schalter.
• Die Ersparnis wächst mit der Menge. Im Rechenbeispiel unten mit 1.000 Aufträgen im Monat fallen rund 500 Stunden Handarbeit im Jahr weg. Deine Zahlen hängen von deinem Ablauf ab.
• Fehler werden gemeldet. Ein Auftrag, der scheitert, bleibt, wo er ist, 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 kostet jeder Standardauftrag ein paar Minuten: bestätigen, Lieferung und Lieferschein anlegen, Rechnung erstellen und buchen. Der Agent ersetzt diese Klicks, wenn alle vier Stufen an sind. Ein Rechenbeispiel für einen Betrieb mit 1.000 Aufträgen im Monat, mit den Annahmen unter den Tabellen:

Kennzahl	Von Hand	Mit dem Agent	Ersparnis
Zeit je Auftrag	2,5 Minuten (Schätzwert)	0 Minuten	2,5 Minuten
Aufträge pro Monat	1.000 (Rechenbeispiel)	1.000	–
Zeit pro Monat	41,6 Stunden	0 Stunden, dazu der Blick in die Fehlermails	41,6 Stunden
Lohnkosten pro Jahr	9.375 €	0 €	9.375 €
Wartezeit bis zur Rechnung	bis jemand Zeit hat	in der Regel der nächste Lauf, alle 10 Minuten	qualitativ
Fehlerquelle	Auftrag vergessen, zweite Rechnung zum selben Auftrag, Vorkasse vor Zahlungseingang verschickt	prüft in jedem Lauf die passenden Aufträge ab dem Stichtag, sucht vorhandene Belege, nimmt Vorkasse erst mit Zahlung	qualitativ

Für andere Mengen:

Aufträge im Monat	100	500	1.000	5.000
Von Hand: Zeit im Monat	4,1 h	20,8 h	41,6 h	208,3 h
Von Hand: Zeit im Jahr	50 h	250 h	500 h	2.500 h
Ersparnis im Jahr	937 €	4.687 €	9.375 €	46.875 €

So ist gerechnet (Annahmen, nicht gemessen): 2,5 Minuten je Auftrag, aufgeteilt in 0,5 Minuten für die Bestätigung, 1 Minute für Lieferung und Lieferschein und 1 Minute für Rechnung und Buchung, 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. Nicht eingerechnet sind Fehlerbearbeitung, Drucken, Packen und der Betrieb von n8n.

Fazit: Der Agent spart nicht die Arbeit im Lager, aber mit allen vier Stufen die Klicks zwischen Bestellung und gebuchter Rechnung.

Wie arbeitet der Agent?

Der Agent startet alle 10 Minuten über den Node „Every 10 minutes“ oder von Hand über „Manual start“. „Check settings“ prüft die Konstanten und bricht ab, solange Platzhalter drinstehen; sonst baut es für jede Stufe einen Filter. Eine ausgeschaltete Stufe fragt weclapp nichts ab. Dann laufen die vier Stufen nacheinander, jede als eigene Bahn auf der Canvas:

1. Confirm orders: Aufträge mit Status ORDER_ENTRY_IN_PROGRESS und mindestens einer Position setzt „Confirm order“ auf ORDER_CONFIRMATION_PRINTED, den Status nach der Auftragsbestätigung.
2. Create shipments: Für bestätigte Aufträge, die über weclapp geliefert werden, sucht „Find shipments of order“ eine vorhandene Lieferung. Gibt es keine, legt „Create shipment“ sie an und „Create delivery note“ setzt sie auf DELIVERY_NOTE_PRINTED, in weclapp „Lieferschein erstellt“. Danach markiert „Mark shipment created“ den Auftrag.
3. Create invoices: Für bestätigte Standardaufträge, die versendet sind oder keinen Versand haben, sucht „Find invoices of order“ eine Rechnung, stornierte zählen nicht. Gibt es keine, legt „Create invoice“ sie an, dann markiert „Mark invoice created“ den Auftrag.
4. Book invoices: Standardrechnungen mit Status NEW setzt „Create invoice document“ auf DOCUMENT_CREATED, danach bucht „Book open item“ sie auf OPEN_ITEM_CREATED. Rechnungen, die schon auf DOCUMENT_CREATED stehen, bucht er direkt. Das schließt die Rechnungen aus Stufe 3 im selben Lauf ein.

Jede Stufe geht ihre Datensätze einzeln in einer Schleife durch, mit einer Pause von 1 Sekunde vor jedem Datensatz (pauseSeconds). Am Ende zählt „Summary“ Erfolge und Fehler je Stufe. Im Probelauf (dryRun) ändert keine Stufe etwas; „Summary“ listet dann je Stufe, was der Agent täte.

Der Agent in n8n: vier Bahnen von oben nach unten, je Bahn eine Schleife über die Datensätze, ganz unten der Fehlerpfad.

Fazit: Vier Stufen, eine nach der anderen, jeder Datensatz einzeln, eine Zusammenfassung am Ende.

Welche Aufträge und Rechnungen nimmt der Agent?

Für jede Stufe stellt der Agent einen Filterausdruck zusammen (Query-Parameter filter der weclapp REST API v2). Für alle Stufen gilt: nur die Vertriebswege aus salesChannels, nur Datensätze ab startDate (Auftragsdatum bzw. Anlagedatum der Rechnung), keine Datensätze mit gesetztem Zusatzfeld „Autopilot aus“. Die ältesten kommen zuerst.

Stufe	Bedingungen	Ergebnis
Confirm orders	status = "ORDER_ENTRY_IN_PROGRESS", itemCount > 0	status = ORDER_CONFIRMATION_PRINTED
Create shipments	status = "ORDER_CONFIRMATION_PRINTED", shipped = false, Zusatzfeld „Lieferung angelegt“ = Nein, fulfillmentProviderId gesetzt, Zahlungsart STANDARD oder PREPAYMENT mit advancePaymentStatus = "PAID"; mit shipOnlyWhenCompletelyAvailable zusätzlich availability = "COMPLETELY_AVAILABLE"	neue Lieferung auf DELIVERY_NOTE_PRINTED, Auftrag markiert
Create invoices	status = "ORDER_CONFIRMATION_PRINTED", Zusatzfeld „Rechnung angelegt“ = Nein, Zahlungsart STANDARD, shipped = true oder kein fulfillmentProviderId; ohne die Vertriebswege aus salesChannelsWithoutInvoices	neue Rechnung, Auftrag markiert
Book invoices	salesInvoiceType = "STANDARD_INVOICE", status NEW oder DOCUMENT_CREATED, ohne die Vertriebswege aus salesChannelsWithoutInvoices	status = OPEN_ITEM_CREATED

• Stichtag: nur Datensätze ab startDate (Mitternacht deutscher Zeit). Setz den Stichtag auf heute, sonst bestätigt, beliefert und berechnet der Agent auch alte Aufträge, die noch in Erfassung stehen. Solange der Platzhalter drinsteht, läuft er nicht.
• Menge je Lauf: höchstens 10 Datensätze je Stufe (maxPerStage, 1 bis 999). Liegen mehr bereit, nimmt der nächste Lauf den Rest, und die Fehlermail sagt, falls eine kommt, in welcher Stufe weitere warten. Erhöhen erst, wenn du ihn eine Weile beobachtet hast.
• Doppelte Sicherheit: Vor der Schleife prüft jede Stufe Status, Vertriebsweg, Stichtag und Zusatzfelder jedes Datensatzes noch einmal und nimmt ihn nur einmal.
• Bewusst nicht: Teillieferungen, Anzahlungs-, Abschlags- und Vorkasserechnungen, Gutschriften, Drucken, Mailversand und Versandetiketten.

Fazit: Der Agent nimmt nur, was eindeutig dran ist, und lässt alles andere liegen.

Welche Schalter hat der Agent?

Alle Schalter stehen im Node „Constants“. Damit passt du den Agent an deinen Ablauf an, ohne einen Node anzufassen:

Schalter	Standard	Stell ihn um, wenn …
dryRun	an	der Probelauf zeigt genau die Datensätze, die du erwartest; erst dann ändert der Agent etwas
confirmOrders	an	du Aufträge selbst prüfen und bestätigen willst
createShipments	aus	Stufe 1 sauber läuft und Lieferungen bei dir über weclapp entstehen sollen
shipOnlyWhenCompletelyAvailable	an	du Lieferungen auch anlegen willst, wenn noch nicht alle Ware da ist
createInvoices	aus	der Agent auch die Rechnungen anlegen soll; nicht, wenn sie aus einem anderen System kommen
bookInvoices	aus	der Agent Rechnungen buchen soll; nicht, wenn du jede vor dem Buchen selbst ansehen willst
salesChannelsWithoutInvoices	leer	ein Vertriebsweg, etwa ein Marktplatz, seine Rechnungen selbst schreibt

Fazit: Jede Stufe läuft auch allein; du schaltest eine nach der anderen ein, jede zuerst im Probelauf.

Was passiert bei einem Fehler?

Scheitert ein Aufruf für einen Datensatz, etwa weil weclapp einen Statuswechsel ablehnt, landet der Datensatz über den Fehlerausgang in der Fehlerzeile seiner Stufe, mit dem Namen des Nodes und der Meldung von weclapp. Schreibende Aufrufe wiederholt der Agent nicht im selben Lauf, damit kein Beleg doppelt entsteht; Lesen wiederholt er bis zu 3-mal im Abstand von 5 Sekunden.

• Neuer Versuch: Der Datensatz bleibt, wo er war. Der nächste Lauf findet ihn wieder und versucht es erneut.
• Keine doppelten Belege: Scheitert die Suche nach einer vorhandenen Lieferung oder Rechnung, legt der Agent nichts an. Legt er eine Lieferung an, aber der Lieferschein scheitert, bleibt die Lieferung bestehen; der nächste Lauf findet sie und markiert nur den Auftrag.
• Fehlermail: Stufe, Auftrags- bzw. Rechnungsnummer und Meldung je Datensatz, dazu ein Link auf die Ausführung in n8n. Betreff: [Order autopilot] … record(s) could not be processed.
• Gedrosselt: Dieselbe Meldung zum selben Datensatz kommt höchstens einmal in errorMailRepeatHours (Standard 24 Stunden). Die Drosselung liegt in den statischen Daten des Workflows; n8n speichert sie nur bei veröffentlichten (aktiven) 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: Ein Fehler beim Schreiben hält nur den einen Datensatz auf, nicht den ganzen Lauf, und du erfährst davon.

Wie richtest du den Agent ein?

Du brauchst:

• n8n, selbst gehostet oder in der Cloud;
• einen weclapp-API-Token eines Benutzers, der Aufträge, Lieferungen und Rechnungen bearbeiten darf;
• vier benutzerdefinierte Ja/Nein-Attribute in weclapp mit dem Standardwert Nein: „Autopilot aus“ für Aufträge, „Autopilot aus“ für Ausgangsrechnungen, „Lieferung angelegt“ und „Rechnung angelegt“ für Aufträge;
• 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 allen weclapp-Nodes; in der HTTP-Fassung weclappBaseUrl in Constants und ein Credential Header Auth mit dem Namen AuthenticationToken und deinem Token als Wert.
3. Die IDs der vier Attribute in Constants eintragen (wie du sie findest, steht unten im Aufruf zu customAttributeDefinition).
4. Constants füllen: salesChannels, startDate (meist heute; ältere Datensätze nimmt der Agent nicht), maxPerStage (Standard 10), Absender und Empfänger der Fehlermail, n8nBaseUrl.
5. SMTP-Credential an „Send error email“ hängen.
6. Probelauf: dryRun steht nach dem Import auf true, nur confirmOrders ist an. „Manual start“ ausführen und in „Summary“ prüfen, welche Aufträge er bestätigen würde; geändert wird nichts. Am besten zuerst gegen einen Testmandanten.
7. dryRun auf false, einmal von Hand laufen lassen, dann aktivieren. Weitere Stufen einzeln dazuschalten, jede zuerst im Probelauf.

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

Fazit: Vier Zusatzfelder, ein Token, ein Stichtag, ein Probelauf je Stufe.

Wie sehen die Aufrufe an die weclapp-API aus?

Die HTTP-Fassung ruft die weclapp REST API v2 auf. Zum Nachvollziehen mit curl, Platzhalter in spitzen Klammern. Die IDs deiner Attribute findest du so:

curl -G "https://<dein-mandant>.weclapp.com/webapp/api/v2/customAttributeDefinition" \
  -H "AuthenticationToken: <dein-token>" \
  --data-urlencode "properties=id,attributeKey,label,attributeType"

Die Aufträge für Stufe 2 holt der Agent mit einem Filterausdruck, hier mit Beispiel-IDs 1001 (Autopilot aus) und 1003 (Lieferung angelegt) und dem 1. Dezember 2026 als Stichtag:

curl -G "https://<dein-mandant>.weclapp.com/webapp/api/v2/salesOrder" \
  -H "AuthenticationToken: <dein-token>" \
  --data-urlencode 'filter=(orderDate >= 1796079600000) and (salesChannel in ["GROSS1"]) and (customAttribute1001 = false) and (status = "ORDER_CONFIRMATION_PRINTED") and (shipped = false) and (customAttribute1003 = false) and (not (fulfillmentProviderId null)) and ((salesOrderPaymentType = "STANDARD") or ((salesOrderPaymentType = "PREPAYMENT") and (advancePaymentStatus = "PAID"))) and (availability = "COMPLETELY_AVAILABLE")' \
  --data-urlencode "sort=orderDate" \
  --data-urlencode "properties=id,orderNumber,status,orderDate,salesChannel,customAttributes" \
  --data-urlencode "pageSize=11"

pageSize ist das Limit plus 1: Kommt ein Auftrag mehr zurück, warten weitere. Vertriebsweg, Auftragsdatum und Zusatzfelder liest der Agent mit, um sie nach der Abfrage noch einmal zu prüfen.

Hat ein Auftrag noch keine Lieferung, legt der Agent sie an und setzt den Lieferschein:

curl -X POST "https://<dein-mandant>.weclapp.com/webapp/api/v2/salesOrder/id/<auftrag-id>/createShipment" \
  -H "AuthenticationToken: <dein-token>" -H "Content-Type: application/json" \
  -d '{"additionalSalesOrderIds": []}'

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

Die Markierung am Auftrag ist ein PUT mit nur diesem einen Attribut. Mit ignoreMissingProperties=true übernimmt weclapp alle anderen Attribute aus dem bestehenden Auftrag:

curl -X PUT "https://<dein-mandant>.weclapp.com/webapp/api/v2/salesOrder/id/<auftrag-id>?ignoreMissingProperties=true" \
  -H "AuthenticationToken: <dein-token>" -H "Content-Type: application/json" \
  -d '{"customAttributes": [{"attributeDefinitionId": "1003", "booleanValue": true}]}'

Vorsicht, wenn du die Aufrufe selbst ausprobierst: Verlass dich bei Aktionen wie createShipment nicht auf den weclapp-Parameter dryRun=true, sondern probier sie in einem Testmandanten. Der Schalter dryRun des Agents ist davon unabhängig und ändert im Probelauf nichts.

Fazit: Ein Filter je Stufe, eine Aktion je Beleg, ein PUT mit einem Feld – mehr braucht es nicht.

Steckbrief

Was	Auftragsabwicklung in weclapp: Auftrag bestätigen, Lieferung mit Lieferschein anlegen, Rechnung anlegen, Rechnung zum offenen Posten buchen
Auslöser	alle 10 Minuten, zusätzlich manuell
Auswahl	Vertriebswege aus salesChannels, ab Stichtag startDate, ohne „Autopilot aus“, Standardaufträge und bezahlte Vorkasse-Aufträge, älteste zuerst
Schutz	läuft erst mit gesetztem Stichtag, Vertriebswegen und Mailadressen; startet im Probelauf (dryRun) mit nur Stufe 1; prüft jeden Datensatz vor dem Schreiben noch einmal
Menge je Lauf	höchstens 10 Datensätze je Stufe (maxPerStage), der Rest im nächsten Lauf
Tempo	ein Datensatz nach dem anderen, 1 Sekunde Pause dazwischen (pauseSeconds)
Wege	vier Stufen mit je eigenem Schalter; Lieferung wahlweise nur bei vollständig verfügbarer Ware
Ergebnis	Auftrag ORDER_CONFIRMATION_PRINTED, Lieferung DELIVERY_NOTE_PRINTED, Rechnung OPEN_ITEM_CREATED, Zusatzfelder am Auftrag
Fehler	Datensatz bleibt, nächster Lauf versucht erneut, keine Wiederholung beim Schreiben, gedrosselte Fehlermail, Lauf endet als fehlgeschlagen
Grenzen	keine Teillieferungen, keine Anzahlungs- oder Vorkasserechnungen, kein Drucken oder Versenden, keine Datensätze vor dem Stichtag
Fassungen	mit Community-Node @wals-pro/n8n-nodes-weclapp und mit HTTP-Request-Nodes (weclapp REST API v2)
Version	2.1 vom 04.11.2026

Fazit: Ein Agent für den ganzen Standardauftrag, mit einem klaren Fehlerweg je Stufe.

Was ist im Download?

• Anleitung als PDF: Einrichtung, alle Konstanten, die vier Zusatzfelder, Testen, Aktivieren und jede Fehlermeldung mit Lösung.
• Agent mit Community-Node: order-autopilot.weclapp-node.json für n8n mit installiertem @wals-pro/n8n-nodes-weclapp.
• Agent als HTTP-Fassung: order-autopilot.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?

• Lieferscheine automatisch erstellen: Willst du nur den Lieferschein-Schritt automatisieren, etwa weil Lieferungen aus deinem Shop oder von Hand entstehen, reicht dieser kostenlose Agent. Lieferungen, die der Autopilot anlegt, haben den Lieferschein schon.
• Retourenetiketten automatisch erstellen: Der kostenlose Agent legt den Lieferungen, die der Autopilot anlegt, ein Retourenetikett bei, direkt über DHL oder über deine weclapp-Integration (shipcloud, sendcloud, DHL).
• Fulfillment 4 weclapp: Nach dem Lieferschein kommt das Packen: Versand mit Scan am Packtisch und Labels von mehr als 14 Versanddienstleistern.
• Weiterlesen: Marktplatz-Aufträge in weclapp automatisieren, Versandstatus kommt beim Marktplatz nicht an und weclapp automatisieren: alle Bausteine.

Fazit: Der Autopilot trägt den Auftrag bis zur Rechnung; Retouren-Agent und Fulfillment 4 weclapp übernehmen den Versand drumherum.

Quellen und Grenzen

• weclapp: Welche Komplett-Workflows gibt es in weclapp?, zu den eingebauten Workflow-Aktionen für Auftrag, Lieferung und Rechnung, abgerufen am 03.11.2026.
• weclapp: Was bedeutet die Versandart „Fulfillment Dienstleister“ und wie funktioniert sie?, zu „kein Versand“, „weclapp Lieferung“ und „Fulfillment Dienstleister“, abgerufen am 03.11.2026.
• weclapp: Warum kann ich eine vorläufige Rechnung erstellen, aber die Rechnungsdokumente nicht erzeugen?, zum Lieferschein als Voraussetzung für Rechnungsdokumente, abgerufen am 03.11.2026.
• weclapp: Gibt es eine API zu weclapp und wo finde ich Informationen dazu?, zum API-Token, abgerufen am 03.11.2026.
• weclapp REST API v2 (OpenAPI-Beschreibung): GET /salesOrder, POST /salesOrder/id/{id}/createShipment, POST /salesOrder/id/{id}/createSalesInvoice, PUT /shipment/id/{id}, PUT /salesInvoice/id/{id}, Query-Parameter filter (laut Doku Beta), ignoreMissingProperties, Stand 16.10.2026.
• Eigener Test der Schutzfunktionen und von Stufe 1 (HTTP-Fassung) in einem weclapp-Testmandanten am 04.11.2026: Abbruch bei Platzhaltern, Probelauf ohne Änderung, Mengengrenze, Stichtag, fremder Vertriebsweg und „Autopilot aus“ ausgeschlossen; ein Probelauf über den ganzen Mandanten ließ 105 ältere Aufträge in Erfassung unberührt. Die Stufen 2 bis 4 sind in diesem Test nicht gelaufen.
• n8n: Loop und getWorkflowStaticData, abgerufen am 03.11.2026.

Der Agent passt nicht, wenn Aufträge vor der Bestätigung regelmäßig von Hand geprüft oder geändert werden (dann confirmOrders aus), wenn du mit Teillieferungen, Anzahlungen oder Abschlagsrechnungen arbeitest oder wenn ein Fulfillment-Dienstleister die Lieferungen außerhalb von weclapp abwickelt; diesen Fall haben wir mit dem Agent noch nicht getestet. Für eigene Regeln vor der Bestätigung, etwa die Versandart je Land, ist zwischen „Select orders to confirm“ und „Confirm order“ Platz.

Fazit: Für den Standardauftrag mit Lieferung über weclapp ist der Agent gebaut, für alles andere ist er ein Ausgangspunkt.

Häufige Fragen

Kann ich einzelne Aufträge vom Agent ausnehmen?

Ja. Setz am Auftrag das Ja/Nein-Zusatzfeld „Autopilot aus“, dann rührt der Agent ihn in keiner Stufe an. Für Rechnungen gibt es dasselbe Zusatzfeld, ganze Vertriebswege nimmst du mit salesChannelsWithoutInvoices von der Rechnung aus.

Was passiert mit Vorkasse-Aufträgen?

Der Agent bestätigt sie, legt die Lieferung aber erst an, wenn der Vorkassestatus auf bezahlt steht (advancePaymentStatus = "PAID"). Rechnungen schreibt er nur für Standardaufträge; Vorkasserechnungen bleiben bei dir.

Legt der Agent doppelte Lieferungen oder Rechnungen an?

Dagegen ist er gebaut. Vor jeder neuen Lieferung und Rechnung fragt er weclapp, ob es zum Auftrag schon eine gibt, und markiert den Auftrag danach. Scheitert diese Abfrage, legt er nichts an und meldet den Fehler. Nach einem Storno legt er eine neue Rechnung an, außer „Rechnung angelegt“ steht schon auf Ja.

Was passiert mit alten Aufträgen, die noch in Erfassung stehen?

Nichts. Der Agent nimmt nur Aufträge ab dem Stichtag startDate, den du beim Einrichten setzt, meist auf heute. Nach dem Import steht er außerdem im Probelauf: Er listet nur, was er täte, und ändert erst etwas, wenn du dryRun auf false setzt.

Druckt oder verschickt der Agent Belege?

Nein. Er setzt nur die Status in weclapp. Drucken und Mailversand von Auftragsbestätigung, Lieferschein und Rechnung richtest du in weclapp ein.

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 Auftragsprozess aussieht und wie der Agent am besten zu deinem weclapp passt.