Du verwendest einen veralteten Browser. Dieser kann eventuell diese oder andere Webseiten nicht richtig darstellen. Du solltest deinen Browser aktualisieren oder einen alternativen Browser verwenden.
Damit war irgendwann zu rechnen. Ausgabe 2.0 ist mit WAWI 1.4 gekommen, das war im Mai 2019.
Wir haben im Laufe der Jahre alle Kunden auf Ausgabe 2.0 umgestellt, auch wenn es teilweise recht mühsam war und viele Variablen fehlten. Inzwischen gibt es fast alle Variablen und einer Umstellung auf Ausgabe 2.0 steht nur noch wenig im Wege. Manche Funktionen, wie z.B. ZUGFerD gibt es nur mit Ausgabe 2.0.
Trotzdem ist es natürlich sehr blöd so spontan umstellen zu müssen.
Soweit schon klar, die Ausgabe 1.0 wurde aber nie abgekündigt und dann muss ich halt sicherstellen, dass diese auch gehen ... es ist ja nur Auftrag betroffen und dabei nur 2-4 Variablen.
Zudem kann die KI Vorlagen von 1.0 auf 2.0 konvertieren, das ist nicht das Problem ... nur macht es die 2.0 nicht einfacher, da einfach vieles fehlt, genau.
Ist die KI Konvertierung wirklich Problemlos? Ich hab immer die Erfahrung gemacht, das Codex z.B. gut klar kommt, wenn es eine Dokumentation zum nachlesen gibt. Wollte demnächst mal über Codex das ganze testen...
Reden wir hier von der Druckvorlagen Standard? Also die 2.0? Konnte die KI die .vlg Dateien lesen, oder wie kann die den Code anpassen von den alten Vorlagen 1.0?
Email, CSV Export kann ich mir ja noch vorstellen, aber die List and Label Vorlagen?
Offenbar gibt es Wind bei JTL, macht bitte alle ein Ticket auf.
Wir hatten mehrfach massiv gegen die Entscheidung geschossen und auch höher eskaliert ... man möchte nun doch intern prüfen, ob man nochmals einen Fix macht.
JTL Support hat uns eine Absage erteilt, der schwerwiegende Bug nur in Aufträgen, dass keine Gesamtsummen mehr ausgegeben werden, wird NICHT behoben!
Da werden einige auf die Nase fallen, obwohl die Ausgabe 1.0 offiziell nicht abgekündigt wurde.
Du kannst mit Folgendem beginnen:
Lege dir zum Test eine neue Standardvorlage an. Dort sind eigentlich die meisten notwendigen, neuen englischen Funktionen/Datenbanknamen enthalten (ja ich weiß, es gibt auch viele Ausnahmen 😉).
Schaue dir die Felder an (Adresse, Artikel etc.) und mache dich mit den Variablen vertraut.
Dann kannst du gerne deine alte Vorlage (z.B. Rechnung) nehmen und kopierst im List&Label Designer einfach alles raus in die Zwischenablage.
Öffne dann deine neue Standard V2 Vorlage, lösche dort alles raus und kopiere den Inhalt der Zwischenablage einfach rein.
Und dann musst du leider händisch alle alten deutschen Variablen mit den neuen englischen ersetzen.
Ich habe es damals noch ein klein wenig anders gemacht:
Ich habe mir das JTLwawi 2 x gestartet und in einer Instanz einmal das alte und in der anderen Instanz das neue Formular im L&L Designer aufgerufen.
Und dann habe ich einfach Stück für Stück mein altes Design und die alten Elemente ins neue übernommen.
Es ist ne Menge Arbeit - aber dadurch habe ich gleich das Gefühl für die neuen Variablen bekommen und konnte mich deutlich tiefer in die ganze L&L Thematik einarbeiten.
Wenn du es dann irgendwann perfektionieren willst, kannst du z.B. auch ein Standarddesign erstellen (z.B. deinen Briefkopf mit Logo, deinem Footer etc.) und dieses als Vorlage nehmen.
In einem Formular kanns du im L&L Designer oben über "Projekt" --> "Bausteine" deine fertige Vorlage hinzufügen und hast automatisch dein Design schon drin.
So brauchst du dir die Arbeit nur 1 x machen und hast dann alles gleich mit drin.
Ich habe das gleiche Problem...ich habe mir vor dem Update "nur" den Changelog angeschaut aber nicht das ganze Forum durchgesucht.
JTL hat mir keine direkte Absage erteilt, sie haben mir einen Ticket genannt in dem der Fehler aufgeführt ist. Es gibt weder eine Zielversion, noch irgendwelche Infos aber immerhin das, votet gerne alle: WAWI-91226
Die Umstellung werde ich jetzt machen müssen, da es zuvor versäumt wurde. JTL hat mir zwar einen Workaround genannt aber der funktioniert bei mir nicht: Als Übergangslösung geben Sie den betroffenen Auftrag bitte über die Vorschau aus: Auftrag markieren, Ausgabe, dann Vorschau. Die Vorschau greift nicht auf ein gespeichertes Belegbild zu und zeigt die Beträge korrekt an. In der Vorschau können Sie über Exportieren, PDF-Datei das Dokument lokal speichern und weitergeben.
Weiter oben wurde ja bereits erwähnt, dass sich die Umstellung wohl recht gut mit KI unterstützen lässt.
Ich habe das inzwischen mit mehreren unserer eigenen Vorlagen getestet und war ehrlich gesagt ziemlich überrascht, wie gut das funktioniert hat.
Bei meinen bisherigen Tests konnte ich zumindest keine offensichtlichen Fehler feststellen.
Weiter oben wurde ja bereits erwähnt, dass sich die Umstellung wohl recht gut mit KI unterstützen lässt.
Ich habe das inzwischen mit mehreren unserer eigenen Vorlagen getestet und war ehrlich gesagt ziemlich überrascht, wie gut das funktioniert hat.
Bei meinen bisherigen Tests konnte ich zumindest keine offensichtlichen Fehler feststellen.
Darf ich fragen welche KI Ihr benutzt habt und wie genau Ihr da vorgegangen seit? einfach vlg hochgeladen und konvertier mal ?
Oder die vlg umbenannt in .zip, entpackt und dann die .lst bearbeitet
Die KI entpackt die VLGs in Arbeitskopien, vergleicht zuerst Standard 1.0 mit der eigenen 1.0 und erkennt dadurch, was tatsächlich individuell geändert wurde.
Anschließend werden nur diese Anpassungen auf die Standard-2.0-Vorlage übertragen.
Die 2.0-Vorlage bleibt dabei die technische Grundlage.
Alte Variablen oder Berechnungen sollen also nicht einfach übernommen werden.
Ich hänge den verwendeten Prompt mal an.
Der ist eher für eine agentische KI gedacht, also zum Beispiel Codex oder einen anderen KI-Agenten, der die Dateien selbstständig entpacken, vergleichen, bearbeiten, prüfen und wieder zusammensetzen kann.
Für die Analyse reicht eine normale ChatGPT-Sitzung völlig aus.
Wenn die Vorlage aber wirklich komplett migriert werden soll, ist ein Agent die bessere Wahl.
# JTL-Ausgabevorlage von Ausgabe 1.0 auf Ausgabe 2.0 migrieren
Du erhältst drei JTL-Ausgabevorlagen für denselben Belegtyp:
1. eine unveränderte JTL-Standardvorlage Ausgabe 1.0
2. eine individuell angepasste Ausgabe-1.0-Vorlage
3. eine unveränderte JTL-Standardvorlage Ausgabe 2.0
## Ziel
Erstelle auf Basis der Standardvorlage 2.0 eine neue individuelle Ausgabe-2.0-Vorlage.
Die individuelle 1.0-Vorlage darf nicht einfach technisch konvertiert werden.
Stattdessen sollst du zunächst ermitteln, welche Änderungen gegenüber der ursprünglichen Standardvorlage 1.0 vorgenommen wurden, und ausschließlich diese individuellen Anpassungen fachlich korrekt auf die Standardvorlage 2.0 übertragen.
Das gewünschte Vorgehen ist:
Standard 1.0
→ Vergleich mit individueller 1.0
→ individuelle Änderungen bestimmen
anschließend:
Standard 2.0
+
individuelle Änderungen
=
neue individuelle 2.0-Vorlage
---
## 1. Umgang mit den VLG-Dateien
Arbeite ausschließlich auf Kopien der bereitgestellten Dateien.
Verändere niemals die Originaldateien.
Falls `.vlg` ein ZIP-basierter Container ist, entpacke jede Vorlage in ein separates Arbeitsverzeichnis.
Erhalte dabei die vollständige Verzeichnis- und Dateistruktur.
Analysiere nicht ausschließlich einzelne `.lst`-Dateien, sondern prüfe die gesamte entpackte Vorlage auf relevante Bestandteile, Konfigurationen, eingebettete Ressourcen und Abhängigkeiten.
Ändere nur Dateien, die für die Migration tatsächlich erforderlich sind.
Nach Abschluss der Arbeiten muss die ursprüngliche Paketstruktur wiederhergestellt werden.
---
## 2. Erste Phase: Nur analysieren
Nimm zunächst keine Änderungen vor.
Vergleiche:
- Standard 1.0
- individuelle 1.0
- Standard 2.0
Ermittle zuerst, welche Unterschiede zwischen Standard 1.0 und individueller 1.0 tatsächlich kundenspezifische Änderungen darstellen.
Wenn eine individuelle Anpassung eine alte Ausgabe-1.0-Variable verwendet, suche zunächst in der Standardvorlage 2.0 nach der fachlich entsprechenden Umsetzung.
Verwende die Standardvorlage 2.0 als primäre Referenz.
Wenn eine eindeutige Zuordnung dort nicht möglich ist, darfst du zusätzlich offizielle Dokumentation verwenden, insbesondere:
Falls auch damit keine eindeutige Zuordnung möglich ist, rate nicht.
Behalte in diesem Bereich die Standard-2.0-Logik bei und dokumentiere die offene Stelle zur manuellen Prüfung.
---
## 5. Besonders kritische Bereiche
Behandle folgende Bereiche mit besonderer Vorsicht:
- Gesamtsummen
- Nettobeträge
- Bruttobeträge
- Steuerbeträge
- Positionssummen
- Rabatte
- Versandkosten
- Skonto
- Zahlungsbedingungen
- Rundungen
- Währungen
- eigene Berechnungen
- eigene SQL-Abfragen
Übernimm hier keine alte 1.0-Berechnungslogik ungeprüft.
Wenn Ausgabe 2.0 bereits eine aktuelle Berechnung besitzt, soll diese verwendet werden.
Beispiel:
Wenn die individuelle 1.0-Vorlage eine Gesamtsumme an einer anderen Position darstellt, übernimm Position und Gestaltung.
Die eigentliche Berechnung der Gesamtsumme soll jedoch möglichst aus der Standardvorlage 2.0 stammen.
---
## 6. Analysebericht erstellen
Bevor du Dateien veränderst, erstelle einen Analysebericht mit:
1. strukturellen Unterschieden zwischen Standard 1.0 und Standard 2.0
2. erkannten individuellen Anpassungen der bisherigen 1.0-Vorlage
3. Anpassungen, die direkt übernommen werden können
4. Anpassungen, die technisch auf 2.0 umgesetzt werden müssen
5. verwendeten Ausgabe-1.0-Variablen
6. möglicher Ausgabe-2.0-Entsprechung
7. eigenen SQL-Abfragen
8. komplexen Formeln
9. komplexen Bedingungen
10. Punkten, die nicht eindeutig automatisch migriert werden können
Führe erst danach die eigentliche Migration durch.
---
## 7. Migration
Verwende die Standardvorlage 2.0 als Ausgangspunkt.
Übertrage nur die zuvor erkannten individuellen Anpassungen.
Verändere die Standard-2.0-Struktur so wenig wie möglich.
Führe keine unnötigen Optimierungen, Vereinfachungen oder Umstrukturierungen durch.
Ziel ist nicht, eine neue Vorlage zu entwickeln.
Ziel ist:
Standardvorlage Ausgabe 2.0
+
individuelle Anpassungen aus der bisherigen Ausgabe 1.0
---
## 8. Abschließende technische Prüfung
Prüfe nach der Migration:
- Sind alle verwendeten Variablen gültige Ausgabe-2.0-Variablen?
- Sind noch Ausgabe-1.0-Variablen vorhanden?
- Verwenden alle Objekte gültige Datenquellen?
- Sind Tabellen und Relationen gültig?
- Sind Formeln syntaktisch korrekt?
- Sind Bedingungen syntaktisch korrekt?
- Werden Summen korrekt berechnet?
- Werden Netto- und Bruttowerte korrekt verwendet?
- Funktioniert die Steuerberechnung?
- Entsprechen Rundungen der Ausgabe-2.0-Logik?
- Werden Rabatte korrekt behandelt?
- Werden Versandkosten korrekt behandelt?
- Funktionieren Seitenumbrüche?
- Funktionieren Druckbedingungen?
- Sind vorhandene SQL-Abfragen weiterhin sinnvoll und kompatibel?
- Ist die vollständige Dateistruktur weiterhin konsistent?
---
## 9. Änderungsprotokoll
Erstelle abschließend ein Änderungsprotokoll.
Dokumentiere für jede relevante Änderung:
- individuelle Anpassung aus Ausgabe 1.0
- ursprüngliche Stelle
- Umsetzung in Ausgabe 2.0
- verwendete neue Variable oder Datenquelle
- eventuell ersetzte alte Variable
- Hinweise zur manuellen Prüfung
---
## Prioritäten
Arbeite nach folgender Priorität:
1. technische Korrektheit der Ausgabe-2.0-Vorlage
2. Erhalt der originalen JTL-2.0-Logik
3. Übernahme der individuellen Anpassungen
4. keine erfundenen Variablen oder Datenquellen
5. möglichst geringe Änderungen an der Standardvorlage
6. Unsicherheiten dokumentieren statt raten
Die KI entpackt die VLGs in Arbeitskopien, vergleicht zuerst Standard 1.0 mit der eigenen 1.0 und erkennt dadurch, was tatsächlich individuell geändert wurde.
Anschließend werden nur diese Anpassungen auf die Standard-2.0-Vorlage übertragen.
Die 2.0-Vorlage bleibt dabei die technische Grundlage.
Alte Variablen oder Berechnungen sollen also nicht einfach übernommen werden.
Ich hänge den verwendeten Prompt mal an.
Der ist eher für eine agentische KI gedacht, also zum Beispiel Codex oder einen anderen KI-Agenten, der die Dateien selbstständig entpacken, vergleichen, bearbeiten, prüfen und wieder zusammensetzen kann.
Für die Analyse reicht eine normale ChatGPT-Sitzung völlig aus.
Wenn die Vorlage aber wirklich komplett migriert werden soll, ist ein Agent die bessere Wahl.
# JTL-Ausgabevorlage von Ausgabe 1.0 auf Ausgabe 2.0 migrieren
Du erhältst drei JTL-Ausgabevorlagen für denselben Belegtyp:
1. eine unveränderte JTL-Standardvorlage Ausgabe 1.0
2. eine individuell angepasste Ausgabe-1.0-Vorlage
3. eine unveränderte JTL-Standardvorlage Ausgabe 2.0
## Ziel
Erstelle auf Basis der Standardvorlage 2.0 eine neue individuelle Ausgabe-2.0-Vorlage.
Die individuelle 1.0-Vorlage darf nicht einfach technisch konvertiert werden.
Stattdessen sollst du zunächst ermitteln, welche Änderungen gegenüber der ursprünglichen Standardvorlage 1.0 vorgenommen wurden, und ausschließlich diese individuellen Anpassungen fachlich korrekt auf die Standardvorlage 2.0 übertragen.
Das gewünschte Vorgehen ist:
Standard 1.0
→ Vergleich mit individueller 1.0
→ individuelle Änderungen bestimmen
anschließend:
Standard 2.0
+
individuelle Änderungen
=
neue individuelle 2.0-Vorlage
---
## 1. Umgang mit den VLG-Dateien
Arbeite ausschließlich auf Kopien der bereitgestellten Dateien.
Verändere niemals die Originaldateien.
Falls `.vlg` ein ZIP-basierter Container ist, entpacke jede Vorlage in ein separates Arbeitsverzeichnis.
Erhalte dabei die vollständige Verzeichnis- und Dateistruktur.
Analysiere nicht ausschließlich einzelne `.lst`-Dateien, sondern prüfe die gesamte entpackte Vorlage auf relevante Bestandteile, Konfigurationen, eingebettete Ressourcen und Abhängigkeiten.
Ändere nur Dateien, die für die Migration tatsächlich erforderlich sind.
Nach Abschluss der Arbeiten muss die ursprüngliche Paketstruktur wiederhergestellt werden.
---
## 2. Erste Phase: Nur analysieren
Nimm zunächst keine Änderungen vor.
Vergleiche:
- Standard 1.0
- individuelle 1.0
- Standard 2.0
Ermittle zuerst, welche Unterschiede zwischen Standard 1.0 und individueller 1.0 tatsächlich kundenspezifische Änderungen darstellen.
Wenn eine individuelle Anpassung eine alte Ausgabe-1.0-Variable verwendet, suche zunächst in der Standardvorlage 2.0 nach der fachlich entsprechenden Umsetzung.
Verwende die Standardvorlage 2.0 als primäre Referenz.
Wenn eine eindeutige Zuordnung dort nicht möglich ist, darfst du zusätzlich offizielle Dokumentation verwenden, insbesondere:
Falls auch damit keine eindeutige Zuordnung möglich ist, rate nicht.
Behalte in diesem Bereich die Standard-2.0-Logik bei und dokumentiere die offene Stelle zur manuellen Prüfung.
---
## 5. Besonders kritische Bereiche
Behandle folgende Bereiche mit besonderer Vorsicht:
- Gesamtsummen
- Nettobeträge
- Bruttobeträge
- Steuerbeträge
- Positionssummen
- Rabatte
- Versandkosten
- Skonto
- Zahlungsbedingungen
- Rundungen
- Währungen
- eigene Berechnungen
- eigene SQL-Abfragen
Übernimm hier keine alte 1.0-Berechnungslogik ungeprüft.
Wenn Ausgabe 2.0 bereits eine aktuelle Berechnung besitzt, soll diese verwendet werden.
Beispiel:
Wenn die individuelle 1.0-Vorlage eine Gesamtsumme an einer anderen Position darstellt, übernimm Position und Gestaltung.
Die eigentliche Berechnung der Gesamtsumme soll jedoch möglichst aus der Standardvorlage 2.0 stammen.
---
## 6. Analysebericht erstellen
Bevor du Dateien veränderst, erstelle einen Analysebericht mit:
1. strukturellen Unterschieden zwischen Standard 1.0 und Standard 2.0
2. erkannten individuellen Anpassungen der bisherigen 1.0-Vorlage
3. Anpassungen, die direkt übernommen werden können
4. Anpassungen, die technisch auf 2.0 umgesetzt werden müssen
5. verwendeten Ausgabe-1.0-Variablen
6. möglicher Ausgabe-2.0-Entsprechung
7. eigenen SQL-Abfragen
8. komplexen Formeln
9. komplexen Bedingungen
10. Punkten, die nicht eindeutig automatisch migriert werden können
Führe erst danach die eigentliche Migration durch.
---
## 7. Migration
Verwende die Standardvorlage 2.0 als Ausgangspunkt.
Übertrage nur die zuvor erkannten individuellen Anpassungen.
Verändere die Standard-2.0-Struktur so wenig wie möglich.
Führe keine unnötigen Optimierungen, Vereinfachungen oder Umstrukturierungen durch.
Ziel ist nicht, eine neue Vorlage zu entwickeln.
Ziel ist:
Standardvorlage Ausgabe 2.0
+
individuelle Anpassungen aus der bisherigen Ausgabe 1.0
---
## 8. Abschließende technische Prüfung
Prüfe nach der Migration:
- Sind alle verwendeten Variablen gültige Ausgabe-2.0-Variablen?
- Sind noch Ausgabe-1.0-Variablen vorhanden?
- Verwenden alle Objekte gültige Datenquellen?
- Sind Tabellen und Relationen gültig?
- Sind Formeln syntaktisch korrekt?
- Sind Bedingungen syntaktisch korrekt?
- Werden Summen korrekt berechnet?
- Werden Netto- und Bruttowerte korrekt verwendet?
- Funktioniert die Steuerberechnung?
- Entsprechen Rundungen der Ausgabe-2.0-Logik?
- Werden Rabatte korrekt behandelt?
- Werden Versandkosten korrekt behandelt?
- Funktionieren Seitenumbrüche?
- Funktionieren Druckbedingungen?
- Sind vorhandene SQL-Abfragen weiterhin sinnvoll und kompatibel?
- Ist die vollständige Dateistruktur weiterhin konsistent?
---
## 9. Änderungsprotokoll
Erstelle abschließend ein Änderungsprotokoll.
Dokumentiere für jede relevante Änderung:
- individuelle Anpassung aus Ausgabe 1.0
- ursprüngliche Stelle
- Umsetzung in Ausgabe 2.0
- verwendete neue Variable oder Datenquelle
- eventuell ersetzte alte Variable
- Hinweise zur manuellen Prüfung
---
## Prioritäten
Arbeite nach folgender Priorität:
1. technische Korrektheit der Ausgabe-2.0-Vorlage
2. Erhalt der originalen JTL-2.0-Logik
3. Übernahme der individuellen Anpassungen
4. keine erfundenen Variablen oder Datenquellen
5. möglichst geringe Änderungen an der Standardvorlage
6. Unsicherheiten dokumentieren statt raten
Die ersten kleineren Änderungen habe ich einfach in einer normalen ChatGPT-Unterhaltung machen lassen.
Das hat auch schon erstaunlich gut funktioniert.
Als eigenes Projekt mit einer agentischen KI hat es den Vorteil, dass ich die Arbeitsweise einmal sauber vorgeben kann.
Dadurch bleibt auch der Kontext erhalten, wenn ich später nochmal an die Vorlagen ran muss.
