Beleg-Volldaten (Auftrag, Rechnung, Lieferschein, Retoure)
jtl_beleg_volldaten
Was das Tool macht
Liefert ALLE Details zu einem Beleg - egal welcher Art. Der Belegtyp wird an der Nummer erkannt (JTL-Standard: OR-... = Auftrag, OR-...-001 = Lieferschein, IN-... = Rechnung, Ret-... = Retoure); bei eigenen Nummernkreisen wird die Nummer in JTL nachgeschlagen. Enthält Kopfdaten, Adressen, alle Positionen (inkl. Positions-Hinweis, bei Aufträgen auch Zulauf des Artikels) bzw. Pakete mit Tracking. Nutze dieses Tool für 'Zeig mir alles zu Beleg X', 'Alle Details zu OR-123456', 'Was steht in Ret-1143?'.
Eingaben
| belegnummerPflicht | Belegnummer, so wie JTL sie anzeigt - z.B. 'OR-527176', 'IN-450613', 'OR-527187-001' oder 'Ret-1143'; eigene Nummernkreise werden automatisch zugeordnet |
| typoptional | Belegtyp erzwingen, falls die Automatik danebenliegt (Default auto) |
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.
- 1Erkennt den Belegtyp zuerst am JTL-Standardpräfix: RET- = Retoure, IN- = Rechnung, OR- mit angehängter Nummer ab drei Ziffern (z. B. -001) = Lieferschein, sonst OR- = Auftrag. Passt kein Präfix (eigener Nummernkreis des Händlers), wird die Nummer in JTL nachgeschlagen: Auftrag und Rechnung per GraphQL mit exakter Nummer, Lieferschein nach dem Standardmuster Auftragsnummer-001 (nur wenn es die Basis als Auftrag gibt), Retoure über die Retourenliste, zuletzt die Suche in der Lieferscheinliste; der erste Treffer zählt. Der Parameter typ übersteuert alles.
- 2Auftrag und Rechnung: Kopf per GraphQL über die exakte Nummer, inklusive Adressen, Kundengruppe, Storno-, Zahlungs- und Korrekturangaben; Positionen über REST v1.3 nach gezielter Suche in der sortierten Belegliste.
- 3Je Position: effektiver Preis = Nettopreis × (1 − Rabatt / 100), Positionswert = effektiver Preis × Menge; Positionssumme und Positionsanzahl zählen nur Artikelpositionen (Typ ungleich 2).
- 4Positions-Hinweis aus dem Feld Notice der REST-v1.3-Position; bei Rechnungen ohne eigenen Hinweis der Hinweis der verknüpften Auftragsposition. Beim Auftrag zusätzlich der Zulauf je Artikel (stockIncoming per GraphQL, gilt für den Artikel, nicht für den Auftrag).
- 5Lieferschein: Auftragsnummer nach dem Standardmuster durch Abschneiden der Endung (nur wenn es diesen Auftrag gibt), Auftragskopf per GraphQL für Kunde und Lieferadresse; der Lieferschein wird gezielt gesucht und einzeln nachgeladen.
- 6Gesamtgewicht = Summe der Paketgewichte; ein Versanddatum, das mit „0001“ beginnt, gilt als leer; Versandarten werden über REST v1.3 (bis 200) in Namen aufgelöst.
- 7Retoure: Bezeichnungen für Status, Grund und Zustand über REST v1.3 (je bis 200); der Kopf wird auf der ersten Listenseite (100 Einträge) gesucht, sonst auf der aus der Nummer geschätzten Seite und ihren Nachbarn.
- 8Retourenpositionen liefern SKU, Menge, Grund, Warenzustand und Gutschrift-Kennzeichen; die retournierte Menge ist die Summe der Positionsmengen.
Annahmen und Grenzen
- Das Korrekturdokument zu einer Rechnung stellt die JTL-API nicht bereit; ausgegeben werden nur Kennzeichen und Korrekturbetrag.
- Retouren führen keine Preise, Lieferscheine keine Positionen.
- Die Beleglisten ignorieren Suchparameter; ohne exakten Nummerntreffer gibt es keinen Ersatzbeleg, bei Auftrag und Rechnung dann nur den Kopf mit Hinweis.
- Die Retourensuche prüft nur die erste Seite und die geschätzte Seite plus/minus eins; bei großen Nummernlücken wird die Retoure nicht gefunden.
- Ohne JTL-Standardpräfix kostet die Zuordnung mehrere Abfragen; ein Lieferschein ohne Auftragsnummer in der Nummer bekommt keinen zugehörigen Auftrag, weil die JTL-API am Lieferschein keinen Auftragsverweis liefert.
So sieht eine Antwort aus
Retoure Ret-1043 vom 20.08. von Muster Handels GmbH, Status „Angemeldet“. Zwei Positionen mit zusammen 4 Stück: • 3× Powerbank Compact 10000mAh, schwarz – Grund „Defekt / beschädigt“, Zustand „Muss geprüft werden“, noch nicht gutgeschrieben • 1× Powerbank Travel 5000mAh mit Kabel, weiß – Grund „Falsche Bestellung“, Zustand „Verkaufsfähig“, bereits gutgeschrieben Die 3 defekten Stück sind noch offen – dort steht die Prüfung aus.
In wenigen Minuten die erste Antwort aus deinen JTL-Daten.
Sieben Tage kostenlos testen, ohne Kreditkarte und ohne Kündigungsfrist.