Auftragsnummer gleich lieferscheinnummer

Hallo,
mit folgendem SQL könnt ihr die Auftragsnummer und/oder die erste Lieferscheinnummer auf der Rechnung abbilden.
Das SQL ist nur für die JTL-Wawi 1.4 und die neuen Vorlagen, nicht für die alten.
Das SQL wird vermutlich auch nur so lange funktionieren, bis die Sammelrechnungen kommen.

Auftragsnummer

Code:

JTL_DirectQuery("SELECT TOP(1) cBestellNr FROM dbo.tBestellung WHERE tRechnung_kRechnung = '"+str$(Report.InternalId)+"'")

Lieferscheinnummer des ersten Lieferscheins

Code:

JTL_DirectQuery("SELECT TOP(1) cLieferscheinNr FROM dbo.tBestellung JOIN dbo.tLieferschein ON tLieferschein.kBestellung = tBestellung.kBestellung WHERE tRechnung_kRechnung = '"+str$(Report.InternalId)+"'")

...
Das SQL ist nur für die JTL-Wawi 1.4 und die neuen Vorlagen, nicht für die alten.
Das SQL wird vermutlich auch nur so lange funktionieren, bis die Sammelrechnungen kommen. ...

Moin @Happy,

im b2b-Bereich sind die Verweise auf Auftrags- und Lieferscheinnummer zwingend erforderlich und dürfen nicht wegfallen.

Leider muß ich feststellen, daß alles, was wichtig war in den Formularen von jtl ohne Kommentar ab wawi 1.4 nicht mehr funktionsdfähig ist.
z.B. Druckeinstellungen Brutto-Netto-Preise, Zahlungsartentexte, usw. In den neuen Formularen gibt es zwar Bausteine. Auf diese kann ich aber verzichten, wenn wichtige Variablen nicht mehr existent sind oder erst über sql-Abfragen dargestellt werden können. Da war selbst eine Wawi .9923 die bessere Wahl.

Leider als langjähriger jtl-Verfechter, ein bedauerlicher Rückschritt.

...
Das SQL ist nur für die JTL-Wawi 1.4 und die neuen Vorlagen, nicht für die alten.
Das SQL wird vermutlich auch nur so lange funktionieren, bis die Sammelrechnungen kommen. ...

Moin @Happy,

im b2b-Bereich sind die Verweise auf Auftrags- und Lieferscheinnummer zwingend erforderlich und dürfen nicht wegfallen.

Leider muß ich feststellen, daß alles, was wichtig war in den Formularen von jtl ohne Kommentar ab wawi 1.4 nicht mehr funktionsdfähig ist.
z.B. Druckeinstellungen Brutto-Netto-Preise, Zahlungsartentexte, usw. In den neuen Formularen gibt es zwar Bausteine. Auf diese kann ich aber verzichten, wenn wichtige Variablen nicht mehr existent sind oder erst über sql-Abfragen dargestellt werden können. Da war selbst eine Wawi .9923 die bessere Wahl.

Leider als langjähriger jtl-Verfechter, ein bedauerlicher Rückschritt.

Dein Kommentar in diesem Thread ist an dieser Stelle nicht richtig, auch ist er Inhaltlich nicht völlständig korrekt.
Erstelle bitte einen neuen Thread für deinen Unmut oder erstelle ein Ticket bei uns.
So können wir dann auf Sachlicher Ebene zu einer Lösung kommen, welche alle zufrieden stellt.

Gegen Produkte zu Flamen, dessen korrekten Umgang man nicht beherscht ist nur kontraproduktiv.

Gegen Produkte zu Flamen, dessen korrekten Umgang man nicht beherscht ist nur kontraproduktiv.

keinen Kommentar. Es gibt halt einen direkten Weg zur Lösung oder aktuell zeitaufwändige Lösungen.

keinen Kommentar. Es gibt halt einen direkten Weg zur Lösung oder aktuell zeitaufwändige Lösungen.

Wieso nimmst du dann den Zeitaufwändigen unnötigen Weg über einen unpassenden Thread hier im Forum?
Der direkte Weg wäre doch ein Ticket bei uns zu erstellen.

Danke erstmal für den Workaround.

Könnt Ihr die Auftragsnummer vielleicht als Variable, welches die erste Auftrsagnummer enthält bereitstellen? Und perspektivisch, wenn die Sammelrechnungen kommen als Array, welches alle zugehörigen Auftragsnummern enthält?

Auftragnummer auf der Rechnung ist echt im Alltag nötig. Wir bekommen hier dauernd Fragen von Kunden, auf welche Aufträge sich denn unsere Rechnungen beziehen.

Also wir können @Thomas nur zustimmen.

Es gibt Werte die nicht nur ein Standard sind, sondern absolut notwendig!
Einen fehleranfälligen Workaround per SQL herbeizuführen, statt die notwendige Funktion per Variable bereitzustellen, kann nicht die Lösung sein.

Als Hersteller hat man a) zunächst mal eine Produkthaftung und b) ein Interesse daran, das bestmögliche Produkt zu liefern.
Wenn der Standard jedoch fehlt und - wie diesbezüglich - sogar notwendige Funktionen fehlen, dann kann es unmöglich das bestmögliche Produkt für einen Nutzer sein oder werden.

Ihr könnt bei JTL also konstruktive Kritik ernst nehmen und euch weiter positiv entwickeln. Oder...
- Nein, lieber die Kritik annehmen und die Software für den Nutzer weiterentwickeln statt diese am Nutzer vorbei zu entwickeln.

Hallo @snPerranporth,

was deine absolute Notwendigkeit angeht, so ist es nicht zwingend vorgeschrieben eine Auftragsnummer auf die Rechnung zu drucken.
Auch kann in der Auftragsübersicht der JTL-Wawi nach der Rechnungsnummer gesucht werden.

Dieser Thread hier ist nur für Tutorials und Anleitungen gedacht, bitte lasst euren Unmut an einer anderen Stelle aus, das nur nebenbei erwähnt.
Dennoch habt ihr beide natürlich recht. Kritik und Feedback sind wichtig, doch bitte an einer geeigneten Stelle.

Wir haben die Variablen mit der noch kommenden JTL-Wawi Version 1.6.X erneut stark angepasst mehr dazu seht Ihr dann mit der 1.6

...ich würde mir wirklich einen JTL Wawi Entwickler wünschen, der hier das Forum quer liest und diese winzig kleinen Aufgaben schnell und formlos abarbeitet.

Diese Variable z.B. erfordert in der Umsetzung weniger Zeit, als es Euch Moderatoren gekostet hat, zu Antworten.
Das gleiche gilt für sooo viele andere Kleinigkeiten. Eine fehlende Variable hier, eine Usability generve hier.

Trotzdem danke für das SQL. Es funktioniert und leztendlich würde hinter einer bereitgestellten Variable nichts anderes passieren Insofern vielleicht mal die Keule in der Kiste lassen...

Ich habe die Keule nicht raus geholt, nur zurück gegeben
Noch dazu sind wir ein stehts wachsendes Unternehmen mit weit über 150 Mitarbeitern.
Wir können nicht einfach frei im Quellcode herum"pfuschen" wie wir wollen.
Es braucht immer eine Arbeitsanweisung im Form eines Entwicklertickets.

Sonst kann ein Zweiter keine Rückschlüsse über etwaige Änderungen ziehen oder andere Dinge nachvollziehen.

Noch dazu bin ich bei uns für die Ausgabe verantwortlich, also genau der richtige Ansprechpartner was List & Label, Dotliquid und allen Variablen und Funktionen angeht.

@Happy ...das hast Du echt falsch verstanden. Mit "Keule rausholen" warst genau Du NICHT gemeint, sondern diejenigen, denen die Lösung hier nicht genug ist und die schon den Untergang der Wawi in der fehlenden Variable sehen.

Was heißt hier "Keule" rausholen? Ich finde jetzt nicht, dass mein Beitrag oben ein Donnerwetter war.

Aber ich sehe es ein, wenn man sich die Kritik an anderer Stelle wünscht. Nun habe ich vernommen: Das hier ist ein Anleitungsthread.
Insofern ist diese Kritik an meinem Beitrag berechtigt. Und ja, Danke für das SQL. Das SQL funktioniert (noch).

Und dennoch: Es sollte nicht so sein, dass eine solche Anleitung geschrieben werden muss. Ich bleibe dabei: Das sollte Standard sein.

Und wenn du der richtige Ansprechpartner bist @Happy dann macht doch das, was für alle Nutzer am einfachsten wäre:

Alle Variablen, die grundsätzlich irgendwo in den Dokumenten verwendet werden können, global (für alle Dokumente) verfügbar machen.
Also nicht auf einzelne Abschnitte in den Dokumenten begrenzen. So gibt es weniger Nachfragen und keine Kritik, da ja verfügbar und ohne Probleme anwendbar.

Das ist sicherlich kein größerer Aufwand, als hier Anleitungen zu tippen und sich - ob berechtigt oder nicht - zu rechtfertigen.

Ich hoffe, ich habe das halbwegs emotionslos und sachlich geschrieben. Wenn nicht, entschuldige ich mich aufrichtig.
Ich wünsche doch JTL nur noch mehr Nutzbarkeit und mehr Usability. Und das ist doch im Interesse von JTL.

Hallo @snPerranporth
vielen dank für deine Nachricht.
Die aktuelle Aufteilung der Variablen ist aktuell nun einmal so und durchaus auch technisch bedingt nicht anders lösbar, wir (intern bei JTL) haben darüber lange diskutiert.

Hallo @Happy ,

vielen Dank für die Auskunft. Es würde uns trotzdem sehr freuen, wenn ihr diesen Verbesserungsvorschlag als Anlass nehmt, dass es sich vielleicht wie folgt verhält:

Ihr selbst seid zwar bereit, darüber zu diskutieren. Damit seht ihr den Punkt. Das ist gut! Aber leider seht ihr die Notwendigkeit intern nicht. Das ist schade!
Denn als Nutzer von JTL und Händler ist das wirklich etwas einschneidend gravierendes. Und extern wünschen nicht nur wir uns das, siehe:
//forum.jtl-software.de/threads/list-label-druckvorlagen-und-variablen.126555/ - Da sind immerhin 4 weitere, die das Problem sehen.

Betrachtet man nun noch, dass dies ein Forenbereich ist, bei dem es nach stichprobenartiger Recherche kaum oder keine Likes für Threads gibt, dann sind 5 Wünsche schon viel
- zumal der Thread zunehmend an Präsenz verliert. Und bitte um Entschuldigung, dass wir den Verbesserungsvorschlag natürlich weiterhin umgesetzt haben möchten.

Das ist wirklich etwas sehr essenzielles. Sprich, aus diesem Grund nutzen wir List & Label nicht so wie wir es als Unternehmen tun sollten und auch selbst den Anspruch haben!
Wir haben aber keine Ressourcen um jedes Dokument so händisch anzupassen, dass es dann passt. Das geht einfach besser und sehr viel hoch 10 effizienter mit globalen Variablen.

Wenn ihr es intern nicht braucht. Das akzeptieren wir voll und ganz. Aber wir glauben, so gut wie jeder Nutzer kann und wird sich über die Vereinfachung freuen. Und sagen:
Toll, das geht mit JTL super einfach und schnell über alle Dokumente hinweg. Mit der Möglichkeit, alles schön individuell anzupassen, ist das mit kaum einem anderen System vergleichbar.

Moin @Happy
Danke für den Snippet der Auftragsnummer. Ist es möglich unten auch wieder die Pakete anzuzeigen oder die Lieferscheine mit den Paketnummern wie früher? Das war ne super Sache. Danke schonmal und ein schönes Wochenende 🍻

LG Nils

Für alle, die gerne das Versanddatum auf der Rechnung hätten, hier der Code für die alte Vorlage:

Code:

"Lieferdatum: " + JTL_DirectQuery("select convert (nvarchar(10), dversanddatum, 104) from tversandinfo where kBestellung = (select kBestellung from tBestellung WHERE tRechnung_kRechnung = '"+str$(Vorgang.InterneRechnungsnummer)+"')")

und hier für die neue Vorlage:

Code:

"Lieferdatum: " + JTL_DirectQuery("select convert (nvarchar(10), dversanddatum, 104) from tversandinfo where kBestellung = (select kBestellung from tBestellung WHERE tRechnung_kRechnung = '"+str$(Report.InternalId)+"')")

Mit freundlichen Grüßen
Frank Hoffmeister

Für alle, die gerne das Versanddatum auf der Rechnung hätten, hier der Code für die alte Vorlage:

Code:

"Lieferdatum: " + JTL_DirectQuery("select convert (nvarchar(10), dversanddatum, 104) from tversandinfo where kBestellung = (select kBestellung from tBestellung WHERE tRechnung_kRechnung = '"+str$(Vorgang.InterneRechnungsnummer)+"')")

und hier für die neue Vorlage:

Code:

"Lieferdatum: " + JTL_DirectQuery("select convert (nvarchar(10), dversanddatum, 104) from tversandinfo where kBestellung = (select kBestellung from tBestellung WHERE tRechnung_kRechnung = '"+str$(Report.InternalId)+"')")

Mit freundlichen Grüßen
Frank Hoffmeister

Vielen Dank! Hat uns gerade gerettet!

Hallo,
ich denke das werden auch noch mehr Leute brauchen. Ausgabe des Versandgewichtes auf der Rechnung:

Code:

(JTL_DirectQuery(" SELECT (SELECT CONVERT (decimal(24,2) ,SUM(fArtGewicht*tbestellpos.nAnzahl)) FROM dbo.tLieferscheinPos JOIN dbo.tbestellpos ON tBestellpos.kBestellPos = tLieferscheinPos.kBestellPos JOIN dbo.tRechnung ON trechnung.tBestellung_kBestellung = tbestellpos.tBestellung_kBestellung JOIN dbo.tArtikel ON tArtikel.kArtikel = tBestellpos.tArtikel_kArtikel WHERE kRechnung = "+str$(Report.InternalId,0,0)+")+ (SELECT CONVERT (decimal(24,2) ,fZusatzGewicht) FROM dbo.tBestellung WHERE tRechnung_kRechnung = "+str$(Report.InternalId,0,0)+")"))

Guten Morgen,
weil es jetzt bereits mehrfach vorkam, hier noch ein Directquery für die externe Bestellnummer vom Auftrag in der Rechnung

Code:

JTL_DirectQuery("SELECT TOP(1) cInetBestellNr FROM dbo.tBestellung WHERE tRechnung_kRechnung = '"+str$(Report.InternalId)+"'")