Auftrag ändern
jtl_auftrag_aendern
Was das Tool macht
Ändert Kopfdaten eines Auftrags: internen Kommentar, Kundenkommentar, externe Nummer, Versandart, Zahlungsart und Rückhaltegrund (per Name; null hebt den Rückhalt auf), Liefertermin, Versanddatum, Versandpriorität, Zahlungsziel sowie Rechnungs- und Lieferadresse - mit Vorschau, Backup und Rückgängig-Funktion. Positionen ändert jtl_auftrag_position_aendern. Nutze dieses Tool für 'Setze bei OR-123 den Rückhaltegrund Wartet auf Zahlung', 'Ändere die Lieferadresse von Auftrag X', 'Liefertermin für Y auf 2026-10-01'. Vorschau zuerst: Ohne dryRun=false wird nichts geändert. Zeige dem Nutzer Vorher/Nachher aus der Vorschau, hole seine Zustimmung ein und rufe dann mit dryRun=false und der bestaetigung erneut auf.
Eingaben
| auftragsnummerPflicht | Auftragsnummer, z.B. OR-526202 (exakt) |
| kommentaroptional | Interner Kommentar - weglassen = unverändert, null = leeren |
| kundenkommentaroptional | Kundenkommentar - weglassen = unverändert, null = leeren |
| externeNummeroptional | Externe Auftragsnummer - weglassen = unverändert, null = leeren |
| versandartoptional | Versandart - Name wie in JTL (kein Id); weglassen = unverändert |
| zahlungsartoptional | Zahlungsart - Name wie in JTL (kein Id); weglassen = unverändert |
| rueckhaltegrundoptional | Rückhaltegrund (Name wie in JTL) - null hebt den Rückhalt auf; weglassen = unverändert |
| lieferterminoptional | Geplanter Liefertermin als Datum JJJJ-MM-TT - weglassen = unverändert, null = leeren |
| versanddatumoptional | Versanddatum als Datum JJJJ-MM-TT - weglassen = unverändert, null = leeren |
| versandprioritaetoptional | Versandpriorität - weglassen = unverändert |
| zahlungszielTageoptional | Zahlungsziel in Tagen - weglassen = unverändert |
| rechnungsadresseoptional | Ohne Beschreibung |
| lieferadresseoptional | Ohne Beschreibung |
| workflowsAuslassenoptional | true = automatische JTL-Workflows für diese Änderung nicht auslösen (Default false). |
| dryRunoptional | true (Default) = nur Vorschau, in JTL wird nichts geändert. false = wirklich schreiben - nur zusammen mit der bestaetigung aus der Vorschau und nach ausdrücklicher Zustimmung des Nutzers. |
| bestaetigungoptional | Bestätigungs-Token aus der Vorschau (Dry-Run). Pflicht bei dryRun=false. |
Die Eingaben füllt die KI aus deiner Frage. Du musst dir keine Parameternamen merken.
So wird gerechnet
Der Rechenweg in der Reihenfolge, in der das Tool arbeitet: Abruf, Filter, Berechnung, Ausgabe. Aus dem Tool-Code abgeleitet, damit nachvollziehbar ist, warum eine Zahl so ist. Dieselbe Auskunft liefert das Tool kiuser_tool_logik direkt im KI-Chat.
- 1Prüft zuerst die Rechte: Server erlaubt Schreiben, JTL-Verbindung für Schreibzugriff freigeschaltet, AVV in aktueller Fassung angenommen, Add-on „Schreiben“ aktiv. Fehlt eines, endet der Aufruf mit dem Grund.
- 2Findet den Auftrag per Nummer: GraphQL liefert das Belegdatum zur exakten Auftragsnummer (kein Treffer = nicht gefunden), dann wird die REST-v1.3-Auftragsliste seitenweise mit dem Datum als Suchhinweis durchsucht.
- 3Der vollständige Auftrag wird gelesen; Versandart, Zahlungsart und Rückhaltegrund erscheinen als Namen. Stornierte Aufträge sind gesperrt und werden nicht geändert.
- 4Verwaltet werden Kommentar, Kundenkommentar, externe Nummer, Versandart, Zahlungsart, Rückhaltegrund (null hebt ihn auf), Liefertermin, Versanddatum, Versandpriorität, Zahlungsziel sowie Rechnungs- und Lieferadresse.
- 5Namen werden exakt oder per eindeutigem Namensanfang aufgelöst, Daten als JJJJ-MM-TT geprüft, Adressen feldweise zusammengeführt. Ändert sich nichts, endet der Aufruf als „keine Änderung“.
- 6Die Vorschau warnt bei teil- oder vollgelieferten Aufträgen, beim Aufheben des Rückhalts und vor möglichen Workflow-Mails; dazu kommt der einmalige Token (15 Minuten, an Eingaben und Ist-Stand gebunden).
- 7Der scharfe Aufruf löst den Token ein, verbraucht Tageslimit und Kontingent, legt das Backup an und schreibt per PATCH: Einzelfelder bei Angabe, Versand-, Zahlungsdetails und Adressen als vollständige Blöcke.
- 8Danach wird der Auftrag erneut gelesen, der tatsächliche Stand mit dem erwarteten verglichen und das Protokoll mit Vorher/Nachher, Abweichungen und backupId abgeschlossen.
Annahmen und Grenzen
- Positionen ändern die Positions-Tools; Auftrag anlegen ist bewusst nicht gebaut, weil JTL dafür Adressen, Währung, Firma und Steuerdetails als Pflichtobjekte verlangt.
- Schlägt die GraphQL-Datumsabfrage fehl, sucht das Tool über den Zahlenteil der Auftragsnummer weiter; ohne verlässliche Sortierung endet die Suche lieber mit „nicht gefunden“ als mit dem falschen Beleg.
- Änderungen an Versand oder Adresse wirken nur auf noch offene Lieferungen; bereits erzeugte Lieferscheine bleiben unberührt.
- In der Einführungsphase gelten 3 Schreibvorgänge je Entität und Tag; der Vorgang lässt sich per jtl_aenderung_wiederherstellen zurücknehmen, das Protokoll wird 12 Monate aufbewahrt.
So sieht eine Antwort aus
Vorschau für Auftrag OR-526202 – noch nichts geändert: • Rückhaltegrund: (keiner) → „Wartet auf Zahlung“ Warnung: JTL-Workflows wie Kundenmails können ausgelöst werden; ich kann sie für diese Änderung unterdrücken. Soll ich den Rückhalt so setzen?
In wenigen Minuten die erste Antwort aus deinen JTL-Daten.
Sieben Tage kostenlos testen, ohne Kreditkarte und ohne Kündigungsfrist.